بررسی تفاوت SSL و TLS؛ سیر تحول و کالبدشکافی پروتکل‌های امنیتی وب

امنیت ارتباطات وب چیزی نیست که از ابتدا با استانداردهای امروزی وجود داشته باشد. پروتکل‌هایی که امروز برای محافظت از اطلاعات میان مرورگر و سرور استفاده می‌شوند، حاصل چند دهه توسعه و اصلاح ضعف‌هایی هستند که در نسخه‌های قدیمی‌تر شناسایی شده‌اند. قفل کنار آدرس وب‌سایت و استفاده از HTTPS برای بیشتر کاربران نشانه یک اتصال امن است، اما پشت این ظاهر ساده، مجموعه‌ای از سازوکارهای رمزنگاری و احراز هویت قرار دارد.

در همین نقطه معمولا یک ابهام رایج شکل می‌گیرد: اگر همه درباره «SSL» صحبت می‌کنند، چرا در ارتباطات مدرن وب از TLS استفاده می‌شود؟ پاسخ ساده است؛ SSL نام خانواده قدیمی‌تری از این پروتکل‌هاست و تمام نسخه‌های آن منسوخ شده‌اند. TLS جایگزین SSL شد و در طول چند نسل، معماری و سازوکارهای امنیتی آن به‌طور اساسی تغییر کرد. در ادامه، مسیر این تغییرات و تفاوت‌های مهم SSL و TLS را بررسی می‌کنیم.

سیر تحول تاریخی از SSL 1.0 تا TLS 1.3

داستان SSL به دهه ۱۹۹۰ و روزهای ابتدایی گسترش تجارت الکترونیک برمی‌گردد. با افزایش استفاده از وب برای انتقال اطلاعات حساس، نیاز به روشی برای رمزنگاری ارتباط میان مرورگر و سرور بیش از گذشته احساس شد. شرکت Netscape در همین دوره توسعه پروتکل SSL را آغاز کرد.

عصر Secure Sockets Layer (SSL)

نسخه SSL 1.0 در سال ۱۹۹۴ طراحی شد، اما به دلیل وجود مشکلات اساسی در طراحی امنیتی، هرگز به‌صورت عمومی منتشر نشد.

در سال ۱۹۹۵، SSL 2.0 به‌عنوان نخستین نسخه عمومی این پروتکل عرضه شد و در مرورگرها مورد استفاده قرار گرفت. بااین‌حال، ضعف‌های متعددی در طراحی آن وجود داشت؛ از جمله مشکلات مربوط به احراز هویت پیام، مذاکره الگوریتم‌های رمزنگاری و امکان اجرای برخی حملات روی ارتباط. همین مشکلات باعث شد عمر SSL 2.0 چندان طولانی نباشد.

Netscape در سال ۱۹۹۶ نسخه SSL 3.0 را معرفی کرد. این نسخه نسبت به نسل قبلی پیشرفت قابل‌توجهی داشت و طراحی آن بعدها مبنایی برای توسعه TLS قرار گرفت. با وجود این، SSL 3.0 نیز در نهایت به دلیل ضعف‌های امنیتی کنار گذاشته شد.

در ادامه، استانداردسازی این فناوری از کنترل Netscape خارج شد و IETF توسعه یک استاندارد مستقل را آغاز کرد. نتیجه این فرایند، تولد TLS بود.

عصر Transport Layer Security (TLS)

در سال ۱۹۹۹، IETF مشخصات TLS 1.0 را در RFC 2246 منتشر کرد. TLS 1.0 بر پایه SSL 3.0 توسعه یافته بود و تغییرات آن بیشتر با هدف استانداردسازی و اصلاح برخی جزئیات امنیتی انجام شد. از این مرحله به بعد، نام رسمی پروتکل به TLS تغییر کرد.

TLS 1.1 در سال ۲۰۰۶ و در قالب RFC 4346 منتشر شد. این نسخه تغییراتی برای افزایش مقاومت پروتکل در برابر برخی حملات مرتبط با رمزنگاری بلوکی، به‌ویژه در حالت CBC، ارائه کرد. یکی از تغییرات مهم آن استفاده از بردار مقداردهی اولیه تصادفی و صریح برای هر رکورد بود.

در سال ۲۰۰۸، TLS 1.2 با انتشار RFC 5246 معرفی شد. این نسخه انعطاف بیشتری در انتخاب الگوریتم‌های رمزنگاری و هش ایجاد کرد و زمینه استفاده از الگوریتم‌های مدرن‌تر را فراهم ساخت. مجموعه‌هایی مانند AES-GCM بعدها به انتخاب‌های مهم برای ارتباطات امن تبدیل شدند.

نقطه عطف بعدی در سال ۲۰۱۸ رقم خورد؛ زمانی که TLS 1.3 در RFC 8446 استاندارد شد. در این نسخه بسیاری از الگوریتم‌ها و سازوکارهای قدیمی حذف شدند، فرآیند برقراری ارتباط کوتاه‌تر شد و طراحی Handshake نیز تغییرات اساسی پیدا کرد. نتیجه، پروتکلی ساده‌تر، سریع‌تر و مقاوم‌تر در برابر طیف وسیعی از حملات شناخته‌شده بود.

معماری و نحوه عملکرد SSL و TLS

SSL و TLS را نمی‌توان به‌سادگی در یکی از لایه‌های مدل OSI قرار داد. این پروتکل‌ها در عمل بین پروتکل‌های لایه انتقال مانند TCP و پروتکل‌های لایه کاربرد مانند HTTP قرار می‌گیرند و امنیت ارتباط را برای پروتکل بالاتر فراهم می‌کنند.

برای درک عملکرد TLS، بهتر است ارتباط را در دو بخش اصلی بررسی کنیم: Handshake و Record.

• Handshake Protocol: وظیفه اصلی این بخش، مذاکره درباره پارامترهای امنیتی، احراز هویت سرور و در صورت نیاز کلاینت، و ایجاد کلیدهای مورد استفاده برای نشست است.
• Record Protocol: داده‌های لایه کاربرد را دریافت می‌کند، آن‌ها را به رکوردهای قابل انتقال تبدیل می‌کند و در نسخه‌های مدرن TLS، با استفاده از سازوکارهای AEAD آن‌ها را رمزنگاری و احراز اصالت می‌کند.

ارتباط با پیام‌هایی مانند ClientHello و ServerHello آغاز می‌شود. کلاینت اطلاعاتی مانند نسخه‌های قابل پشتیبانی و مجموعه‌های رمزنگاری مورد نظر خود را ارسال می‌کند و سرور پارامترهای مورد استفاده در نشست را انتخاب می‌کند.

در TLS 1.3، تبادل کلید بر پایه سازوکارهای Diffie-Hellman انجام می‌شود. پس از ایجاد کلیدهای نشست، داده‌های اصلی ارتباط با الگوریتم‌های رمزنگاری متقارن محافظت می‌شوند. این معماری باعث می‌شود عملیات رمزنگاری داده‌های حجیم با سرعت بسیار بیشتری نسبت به استفاده مستقیم از الگوریتم‌های نامتقارن انجام شود.

تفاوت‌های بنیادی SSL و TLS

SSL و TLS هر دو با هدف ایجاد ارتباط امن طراحی شده‌اند، اما TLS در طول زمان بسیاری از اجزای قدیمی SSL را کنار گذاشته و سازوکارهای امنیتی جدیدتری را جایگزین کرده است.

• فرآیند Handshake: در نسخه‌های قدیمی‌تر، برقراری ارتباط به رفت‌وبرگشت‌های بیشتری نیاز داشت. TLS 1.3 این فرآیند را به یک رفت‌وبرگشت کاهش داده و در شرایط خاص، قابلیت 0-RTT را نیز ارائه می‌کند.
• الگوریتم‌های رمزنگاری: SSL و TLSهای قدیمی امکان استفاده از الگوریتم‌هایی مانند RC4، DES و MD5 را فراهم می‌کردند که امروزه ناامن محسوب می‌شوند. TLS 1.3 مجموعه الگوریتم‌های مجاز را به شکل محسوسی محدود کرده و روی گزینه‌های مدرن مانند AES-GCM و ChaCha20-Poly1305 تمرکز دارد.
• احراز اصالت و تمامیت داده: سازوکارهای قدیمی SSL برای محافظت از تمامیت پیام‌ها محدودیت‌هایی داشتند. در TLS مدرن، استفاده از الگوریتم‌های AEAD امکان رمزنگاری و احراز اصالت داده را در یک سازوکار یکپارچه فراهم می‌کند.
• مدیریت خطا و پیام‌های Alert: ساختار پیام‌های Alert در TLS در طول نسخه‌های مختلف تغییر کرده و در TLS 1.3 ساده‌تر شده است.
• SNI: قابلیت Server Name Indication این امکان را فراهم می‌کند که  کلاینت نام دامنه مقصد را در ابتدای ارتباط اعلام کند. این قابلیت برای میزبانی چندین دامنه روی یک IP بسیار مهم است و در اکوسیستم TLS به‌طور گسترده استفاده می‌شود.

چرا SSL و TLS 1.0 و 1.1 منسوخ شدند؟

منسوخ شدن نسخه‌های قدیمی نتیجه یک عامل واحد نبود. مجموعه‌ای از ضعف‌های طراحی، الگوریتم‌های قدیمی و حملات جدید باعث شد استفاده از این نسخه‌ها به‌تدریج کنار گذاشته شود.

یکی از شناخته‌شده‌ترین نمونه‌ها، حمله POODLE بود که در سال ۲۰۱۴ منتشر شد و یکی از ضعف‌های SSL 3.0 در استفاده از رمزنگاری CBC را هدف قرار می‌داد. این حمله نشان داد که حتی پس از سال‌ها استفاده، یک پروتکل قدیمی می‌تواند همچنان مسیرهایی برای حمله را در اختیار مهاجم قرار دهد.

حمله BEAST نیز یکی از حملات مهم علیه نحوه استفاده TLS 1.0 از رمزنگاری CBC بود. در کنار آن، حملاتی مانند CRIME نشان دادند که فشرده‌سازی در لایه TLS می‌تواند در شرایط خاص اطلاعاتی درباره داده‌های محرمانه در اختیار مهاجم قرار دهد.

TLS 1.3 بسیاری از این پیچیدگی‌های قدیمی را حذف کرد. برای مثال، فشرده‌سازی در TLS Record Layer دیگر بخشی از پروتکل نیست؛ البته این موضوع به این معنا نیست که فشرده‌سازی HTTP نیز حذف شده است.

در حال حاضر SSL 2.0، SSL 3.0، TLS 1.0 و TLS 1.1 منسوخ محسوب می‌شوند و استفاده از آن‌ها توصیه نمی‌شود. برای ارتباطات مدرن، TLS 1.2 با پیکربندی مناسب و به‌ویژه TLS 1.3 گزینه‌های استاندارد هستند.

چرا هنوز همه از عبارت «گواهینامه SSL» استفاده می‌کنند؟

اگر SSL سال‌هاست منسوخ شده، چرا هنوز عباراتی مانند «خرید گواهینامه SSL» را در وب‌سایت شرکت‌های هاستینگ و فروشندگان گواهینامه می‌بینیم؟

دلیل اصلی، جاافتادن این اصطلاح در بازار است. «SSL» برای سال‌ها نام رایج فناوری امنیت ارتباطات وب بوده و به همین دلیل در ذهن کاربران با مفهوم گواهینامه امنیتی گره خورده است. تغییر ناگهانی این اصطلاح به «گواهینامه TLS» نیز ممکن است برای کاربران ابهام ایجاد کند.

اما از نظر فنی، گواهینامه دیجیتال به خودی خود تعیین نمی‌کند که ارتباط با SSL یا TLS برقرار شود. گواهینامه شامل اطلاعاتی مانند کلید عمومی و مشخصات هویتی دامنه است، در حالی که نسخه و تنظیمات پروتکل در سمت سرور و کلاینت تعیین می‌شوند.

به همین دلیل، وقتی امروز گواهینامه‌ای با عنوان «SSL Certificate» خریداری می‌کنید، این نام تجاری به معنای استفاده از SSL 2.0 یا SSL 3.0 نیست. گواهینامه SSL می‌تواند در یک اتصال مدرن مبتنی بر TLS 1.2 یا TLS 1.3 استفاده شود.

چه تغییراتی در TLS 1.3 ایجاد شد؟

TLS 1.3 فقط یک به‌روزرسانی معمولی نبود؛ بسیاری از تصمیم‌های طراحی نسخه‌های قبلی در آن بازنگری شد.

• حذف الگوریتم‌های قدیمی: الگوریتم‌هایی مانند RC4 و DES و برخی سازوکارهای قدیمی تبادل کلید از TLS 1.3 حذف شدند. RSA نیز دیگر برای تبادل کلید در TLS 1.3 استفاده نمی‌شود.
• استفاده اجباری از Forward Secrecy: تبادل کلید در TLS 1.3 بر پایه Diffie-Hellman انجام می‌شود. در نتیجه، افشای بعدی کلید خصوصی بلندمدت سرور نباید امکان رمزگشایی نشست‌های قبلی را فراهم کند؛ البته این موضوع به پیاده‌سازی صحیح پروتکل و مدیریت درست کلیدها وابسته است.
• کاهش تعداد رفت‌وبرگشت‌ها: TLS 1.3 برقراری ارتباط را سریع‌تر کرده و در حالت معمول به یک RTT برای Handshake نیاز دارد. قابلیت 0-RTT نیز برای برخی ارتباطات قبلی امکان ارسال داده همراه با اولین پیام را فراهم می‌کند، هرچند استفاده از آن ملاحظات امنیتی خاص خود را دارد و برای همه درخواست‌ها مناسب نیست.
• رمزنگاری بیشتر پیام‌های Handshake: پس از پیام‌های اولیه، بخش بیشتری از فرآیند Handshake در TLS 1.3 رمزنگاری می‌شود. برای مثال، گواهینامه سرور و بسیاری از پیام‌های بعدی پس از ایجاد کلیدهای اولیه، به‌صورت رمزنگاری‌شده منتقل می‌شوند.

SSL یا TLS؛ کدام را باید استفاده کنیم؟

برای یک وب‌سایت یا سرویس مدرن، انتخاب میان SSL و TLS عملا موضوعیتی ندارد؛ تمام نسخه‌های SSL منسوخ شده‌اند و نباید فعال باشند. انتخاب واقعی میان نسخه‌های TLS است.

در اغلب زیرساخت‌های امروزی، TLS 1.3 انتخاب اصلی و TLS 1.2 گزینه سازگارتر برای کلاینت‌ها و سامانه‌هایی است که هنوز از TLS 1.3 پشتیبانی نمی‌کنند. در مقابل، TLS 1.0 و TLS 1.1 و تمام نسخه‌های SSL باید غیرفعال باشند.

همچنین صرف فعال بودن TLS 1.3 به معنای امنیت کامل نیست. انتخاب Cipher Suiteهای مناسب، استفاده از گواهینامه معتبر، مدیریت صحیح کلید خصوصی، تنظیم درست سرور و به‌روزرسانی نرم‌افزارهای مرتبط همگی در امنیت نهایی ارتباط نقش دارند.

ارزیابی و جمع‌بندی پروتکل‌های امنیت شبکه

تفاوت SSL و TLS را می‌توان در یک جمله خلاصه کرد: SSL نسل قدیمی پروتکل‌های امنیت ارتباطات وب است و TLS نسخه استاندارد و تکامل‌یافته همان ایده محسوب می‌شود. SSL 2.0 و SSL 3.0 به دلیل ضعف‌های امنیتی کنار گذاشته شدند و TLS نیز در نسخه‌های 1.0 و 1.1 به پایان عمر خود رسید.

TLS 1.2 همچنان در صورت پیکربندی صحیح قابل استفاده است، اما TLS 1.3 معماری ساده‌تر، Handshake سریع‌تر و مجموعه الگوریتم‌های محدودتر و مدرن‌تری ارائه می‌کند. بنابراین هنگام پیکربندی یک وب‌سرور، بهتر است تمرکز روی فعال‌سازی TLS 1.2 و 1.3، ترجیح TLS 1.3 و غیرفعال کردن تمام نسخه‌های منسوخ باشد.

در نهایت، اصطلاح «گواهینامه SSL» بیشتر یک عبارت جاافتاده تجاری است تا نام دقیق فناوری مورد استفاده در ارتباطات امروز. آنچه امنیت اتصال HTTPS را تامین می‌کند، مجموعه‌ای از گواهینامه دیجیتال، TLS، الگوریتم‌های رمزنگاری و تنظیمات صحیح سرور است.