SSL (پروتکل لایه اتصال امن) و پروتکل جانشین آن TLS (پروتکل امنیت لایه‌ي انتقال) پروتکل‌هایی برای برقراری اتصال تاییدشده و رمزگذاری‌شده بین کامپیوترهای شبکه هستند. اگرچه استفاده از پروتکل SSL پس از ارائه پروتکل TLS 1.0 در سال ۱۹۹۹ منسوخ شد ولی همچنان به این دسته تکنولوژی‌های مرتبط SSL یا SSL/TLS می‌گویند. جدیدترین نسخه موجود TLS نسخه‌ی 1.3 است که در آگوست ۲۰۱۸ به بازار عرضه شده است و با نام RFC 8446 شناخته می‌شود.
کلیدها، گواهینامه‌ها و فرآیندهای Handshaking (دست‌دهی)
پروتکل‌های SSL/TLS، از طریق مدارک دیجیتالی موسوم به گواهینامه‌های x.509، هویت نهادهای مختلف مانند وبسایت‌ها و شرکت‌ها را به جفت‌کلیدهای رمزنگاری‌شده پیوند می‌زنند. هریک از این جفت کلیدها شامل یک کلید خصوصی و یک کلید عمومی است. کلید خصوصی همواره ایمن نگه داشته می‌شود ولی کلید عمومی به طور گسترده از طریق یک گواهینامه در اختیار همه قرار می‌گیرد.
رابطه ریاضی خاص بین کلیدهای خصوصی و عمومی در یک جفت بدین صورت است که شما می‌توانید با استفاده از کلید عمومی یک پیام را رمزنگاری کنید، به‌گونه‌ای که تنها با استفاده از کلید خصوصی رمزگشایی شود. علاوه بر این، مالک کلید خصوصی می‌تواند با استفاده از آن، مدارک دیجیتالی دیگر (مانند صفحات وب) را امضا کند و هر شخصی که به کلید عمومی دسترسی داشته باشد می‌تواند این امضا را تایید کند.
اگر گواهینامه SSL/TLS، خود توسط یک مرکز معتبر صدور گواهینامه (CA) مانند CERTUM امضا شده باشد، این گواهینامه توسط نرم‌افزارهای سرویس‌گیرنده مانند جستجوگرهای وب و سیستم عامل‌ها هم معتبر شناخته می‌شود. گواهینامه‌های عمومی معتبر CA، توسط بزرگترین نهادها و شرکت‌های تولید نرم‌افزار تایید شده‌اند تا بتوان با استفاده از آن‌ها هویت‌های مورد اعتماد را روی پلتفرم‌‌های مربوطه تایید کرد. گواهینامه‌های عمومی CA برای این که همچنان مورد اعتماد باقی بمانند، باید در روند تایید و صدور، ممیزی‌های منظم و سختگیرانه‌ای را بگذرانند.
با فرآیند Handshake (دست‌دهی) پروتکل‌های SSL/TLS، کلیدهای شخصی و عمومی را می‌توان برای یک گواهینامه موردتایید استفاده کرد و به‌وسیله‌ی آن یک اتصال رمزگذاری‌شده و تاییدشده بر روی اینترنت برقرار کرد؛ حتی اگر این اتصال بین دو طرفی باشد که تا به حال هیچ تعاملی نداشته‌اند. این حقیقت ساده، بنیان جستجوی ایمن وب و تجارت الکترونیک به معنای امروزی آن است.
مرور ایمن وب با SSL/TLS
رایج‌ترین و معروف‌ترین نحوه‌ی استفاده از SSL/TLS، مرور ایمن وب از طریق پروتکل HTTPS است. یک وبسایت عمومی HTTPS که به‌درستی پیکربندی شده باشد، شامل یک گواهینامه‌ی SSL/TLS است که به‌وسیله‌ی یک CA عمومی قابل اعتماد امضا شده باشد. کاربرانی که از یک وبسایت HTTPS بازدید می‌کنند می‌توانند از این موارد اطمینان داشته باشند:
- اصالت (Authenticity): سروری که گواهینامه را ارائه می‌کند مالک کلید خصوصی است که با کلید عمومی در گواهینامه منطبق است.
- سلامت محتوا (Integrity) : اسنادی که توسط گواهینامه امضا شده‌اند (مثلا صفحه‌های وبسایت) حین انتقال توسط یک مرد میانی (man in the middle) دستکاری نشده‌اند.
- رمزگذاری (Encryption): ارتباطات میان کلاینت و سرور رمزگذاری شده‌اند.
این ویژگی‌ها باعث می‌شود که کاربران بتوانند با استفاده از پروتکل‌های SSL/TLS و HTTPS اطلاعات محرمانه مانند اطلاعات کارت، اطلاعات شخصی و نام کاربری و رمز عبور خود را به‌صورت ایمن از طریق اینترنت مخابره کنند، و مطمئن باشند که وبسایتی که اطلاعات به آن ارسال می‌شود وبسایت اصلی است. روی یک وبسایت ناامن که از پروتکل HTTP استفاده می‌کنند، تمام این داده‌ها به صورت متن خام ارسال می‌شوند و در هر نقطه از مسیر ارتباطی، هرکس که جریان داده را شنود کند، به آن‌ها دسترسی خواهد داشت. علاوه بر این، کاربرانی که از این وبسایت‌های حفاظت‌نشده بازدید می‌کنند، هیچ تضمینی از سوی یک نهاد ثالث معتبر ندارند که وبسایت بازدیدشده، وبسایت اصلی مورد نظر آن‌ها باشد.
با توجه به این قسمت در نوار آدرس مرورگر، مطمئن شوید وبسایتی که به آن مراجعه کرده‌اید توسط یک گواهینامه قابل اعتماد SSL/TLS محافظت شده است:
- علامت قفل بسته در سمت چپ آدرس URL. بسته به جستجوگر شما و نوع گواهینامه نصب شده بر روی وبسایت، رنگ این قفل می‌تواند سبز باشد یا اطلاعات هویتی درباره شرکت اجراکننده‌ی آن نیز در کنار آن آمده باشد.
- اگر پروتکل در ابتدای آدرس نمایش داده شده باشد، باید ابتدای آدرس URL به صورت //:https باشد نه //:http. توجه داشته باشید که تمام جستجوگرها پروتکل را نشان نمی‌دهند.
هم‌چنین، مرورگرهای امروزی به بازدیدکنندگان درباره سایت‌های ناایمن و بدون گواهینامه SSL/TLS هشدار می‌دهند. اسکرین‌شات زیر یک وبسایت ناامن را در مرورگر فایرفاکس نشان می‌دهد و تصویر یک قفل خط‌خورده در سمت چپ آدرس URL دیده می‌شود:
نحوه اخذ گواهینامه SSL/TLS
آماده ایمن‌سازی وبسایت خود هستید؟ روند اصلی درخواست یک گواهینامه معتبر SSL/TLS به شرح زیر است:
- فرد یا سازمان درخواست‌کننده‌ی گواهینامه، یک جفت کلید عمومی و شخصی تولید می‌کند. این کلیدها ترجیحا باید روی سروری قرار داشته باشند که نیازمند محافظت است.
- با استفده از کلید عمومی به همراه نام دامنه‌ی نیازمند محافظت و -برای مدارک OV و EV- اطلاعات سازمانی شرکت متقاضی گواهینامه، درخواست امضای گواهینامه (CSR) تولید می‌شود.
- درخواست امضای گواهینامه (CSR)، به یک مرکز معتبر (CA) فرستاده می‌شود. این مرکز اطلاعات موجود در CSR را تایید کرده و یک گواهینامه امضا‌شده تولید می‌کند که می‌تواند بر روی وب‌سرور درخواست‌کننده نصب شود.
گواهینامه‌های SSL/TLS بسته به نحوه اعتبارسنجی مورد استفاده و سطح اعتماد اعطاشده به آن‌ها (که بالاترین سطح آن EV است) متفاوت هستند.
سوالات متداول
آیا برای استفاده از پروتکل‌های SSL/TLS به یک آی پی اختصاصی نیاز داریم؟
در گذشته داشتن آی پی اختصاصی برای هر گواهینامه SSL بر روی وب‌سرور الزامی بود ولی با گذشت زمان و پیدایش تکنولوژی SNI، دیگر به IP اختصاصی نیاز نیست؛ توجه داشته باشید که پلتفرم میزبان شما باید حتما از قابلیت SNI پشتیبانی کند.
استفاده از پروتکل SSL/TLS روی کدام پورت‌ها پیشنهاد می‌شود؟
پورت 443 پورت استاندارد برای ارتباطات ایمن SSL/TLS بوده و بیشترین سازگاری را با این پروتکل دارد؛ لذا استفاده از پروتکل SSL/TLS روی همین پورت پیشنهاد می‌شود. با این وجود، هر پورتی را می‌توان برای این کار استفاده کرد.
مشکلات امنیتی نسخه‌های قدیمی‌تر پروتکل TLS چیست؟
آسیب‌پذیری‌های متعدد درخود پروتکل و فرایند پیاده‌سازی که توسط پژوهشگران امنیتی در دو دهه اخیر منتشر شده‌اند، پروتکل TLS نسخه ۱.۰ و ۱.۱ را تحت تاثیر قرار داده‌اند. حملاتی مانند ROBOT روی الگوریتم مبادله کلید RSA تاثیر داشته‌اند، و هم‌چنین آسیب‌پذیری‌های Logjam و WeakDH نشان داده‌اند که بسیاری از سرورهای TLS ممکن است فریب خورده و برای شیوه‌های دیگر مبادله کلید، از پارامترهای نادرست استفاده کنند. به خطر افتادن مبادله کلید، به هکرها این امکان را می‌هد که امنیت شبکه را به طور کامل به خطر انداخته و مکالمات را رمزگشایی کنند.
حملات صورت‌گرفته بر روی رمزهای متقارن مانند BEAST یا Lucky13 نشان می‌دهند که رمزهای متعددی که در نسخه TLS 1.2 و قبل‌تر پشتیبانی می‌شوند (مانند RC4 یا رمزهای CBC-mode) ایمن نیستند.
با استفاده از حملات جعل امضای RSA با نام Bleichenbacher و دیگر حملات مشابه از نوع Padding، حتی امضاها هم تحت تاثیر قرار می‌گیرند.
بسیاری از این حملات در نسخه TLS 1.2 کاهش یافته‌اند (به شرطی که پروتکل‌های TLS به درستی پیکربندی شده باشند)، ولی نسخه TLS 1.2 همچنان در برابر حملات از نوع downgrade مانند POODLE، FREAK یا CurveSwap آسیب‌پذیر است. این مسئله به این دلیل است که تمامی نسخه‌های پروتکل TLS قبل از نسخه ۱.۳ از تبادل اطلاعات Handshake (که نسخه پروتکل مورداستفاده در تبادل اطلاعات را تعیین می‌کند) محافظت نمی‌کنند.
