دست‌دهی TLS: چگونه رمزنگاری نامتقارن و متقارن برای امن‌سازی ترافیک وب ترکیب می‌شوند

هنگامی که یک مرورگر درخواست یک صفحه وب امن را می‌دهد، در عرض ۳۰۰ میلی‌ثانیه پس از باز شدن اتصال TCP، یک مذاکره رمزنگاری تعیین می‌کند که آیا ترافیک از رهگیری در امان خواهد بود یا خیر. این فرآیند، یعنی دست‌دهی (Handshake) امنیت لایه انتقال (TLS)، امنیت رمزنگاری نامتقارن را با سرعت رمزنگاری متقارن ترکیب می‌کند تا یک نشست امن برقرار شود. Cloudflare اشاره می‌کند که «دست‌دهی TLS هر زمان که کاربر از طریق HTTPS به وب‌سایتی می‌رود و مرورگر برای اولین بار شروع به پرس‌وجو از سرور مبدأ وب‌سایت می‌کند، رخ می‌دهد.»[4]

چالش اصلی مهندسی ارتباطات امن، توزیع کلید است: هر دو طرف برای رمزگذاری داده‌ها به یک راز مشترک نیاز دارند، اما باید بر سر آن راز در شبکه‌ای که فعالانه تحت نظارت است، توافق کنند. رمزنگاری نامتقارن، که از یک کلید عمومی برای رمزگذاری و یک کلید خصوصی برای رمزگشایی استفاده می‌کند، مشکل توزیع را حل می‌کند اما یک جریمه عملکردی شدید به همراه دارد. انجمن اینترنت (The Internet Society) اشاره می‌کند که «یک کلید نامتقارن ۲۰۴۸ بیتی تقریباً معادل یک کلید متقارن ۱۱۲ بیتی» از نظر قدرت رمزنگاری است، که محاسبات نامتقارن را تا هزار برابر از نظر محاسباتی فشرده‌تر می‌کند.[3]

برای جلوگیری از فلج شدن سرعت شبکه، دست‌دهی TLS از رمزنگاری نامتقارن سنگین صرفاً برای احراز هویت اولیه و تبادل کلید استفاده می‌کند. هنگامی که یک کانال امن برقرار شد، پروتکل برای انتقال واقعی داده‌های انبوه به رمزنگاری متقارن – معمولاً استاندارد رمزگذاری پیشرفته (AES) با استفاده از کلیدهای ۱۲۸ بیتی یا ۲۵۶ بیتی – تغییر وضعیت می‌دهد.[3][6]

دست‌دهی بلافاصله پس از برقراری اتصال زیربنایی TCP آغاز می‌شود. کلاینت با ارسال پیام «سلام کلاینت» (Client Hello) توالی را شروع می‌کند. این بسته شامل بالاترین نسخه TLS پشتیبانی شده توسط کلاینت، فهرستی از مجموعه‌های رمز قابل قبول، و یک مقدار تصادفی ۳۲ بایتی تولید شده که به عنوان تصادفی کلاینت (client random) شناخته می‌شود، است.[1][4]

سرور با پیام «سلام سرور» (Server Hello) پاسخ می‌دهد و قوی‌ترین مجموعه رمز مورد حمایت متقابل را انتخاب می‌کند. همچنین تصادفی سرور ۳۲ بایتی خود و گواهی دیجیتال X.۵۰۹ خود را ارسال می‌کند. کلاینت این گواهی را در برابر مخزن محلی مراجع صدور گواهی (Certificate Authorities) مورد اعتماد خود تأیید می‌کند، مالکیت قانونی سرور بر دامنه درخواستی را تأیید کرده و از رهگیری حمله مرد میانی جلوگیری می‌کند.[4]

با تأیید هویت سرور، دو طرف باید راز مشترک را تولید کنند. در دست‌دهی‌های قدیمی‌تر مبتنی بر RSA، کلاینت یک رشته تصادفی از بایت‌ها به نام راز پیشا-مستر (premaster secret) تولید می‌کند، آن را با کلید عمومی سرور رمزگذاری کرده و ارسال می‌کند. از آنجایی که فقط سرور کلید خصوصی مربوطه را در اختیار دارد، تنها سرور می‌تواند راز پیشا-مستر را رمزگشایی کند.[4]

پیاده‌سازی‌های مدرن TLS به شدت تبادل کلید دیفی-هلمن زودگذر (ECDHE) را به RSA ترجیح می‌دهند. به جای اینکه کلاینت یک راز رمزگذاری شده ارسال کند، هم کلاینت و هم سرور پارامترهای ریاضیاتی را مبادله می‌کنند که به آن‌ها اجازه می‌دهد به طور مستقل یک راز پیشا-مستر منطبق را محاسبه کنند. این روش محرمانگی پیشرو (forward secrecy) را فراهم می‌کند: از آنجایی که کلیدهای نشست مستقیماً از کلید خصوصی استاتیک سرور استخراج نمی‌شوند، مهاجمی که ترافیک رمزگذاری شده را ضبط می‌کند و بعداً کلید خصوصی را به سرقت می‌برد، همچنان نمی‌تواند داده‌های تاریخی را رمزگشایی کند.[3][4]

هنگامی که هر دو طرف راز پیشا-مستر را در اختیار دارند، از یک تابع شبه تصادفی (PRF) برای ترکیب آن با تصادفی کلاینت ۳۲ بایتی و تصادفی سرور ۳۲ بایتی استفاده می‌کنند. طبق مشخصات RFC ۵۲۴۶ کارگروه مهندسی اینترنت، این عملیات ورودی‌ها را به یک راز مستر ۴۸ بایتی گسترش می‌دهد.[1]

سپس راز مستر ۴۸ بایتی دوباره از طریق PRF تغذیه می‌شود تا کلیدهای نهایی نشست متقارن تولید شوند. این کلیدها شامل کلید رمزگذاری نوشتن کلاینت، کلید رمزگذاری نوشتن سرور و کلیدهای کد احراز هویت پیام (MAC) هستند که برای تأیید یکپارچگی داده‌ها استفاده می‌شوند. هم کلاینت و هم سرور یک پیام نهایی «تمام شد» (Finished) ارسال می‌کنند که با کلیدهای نشست تازه تولید شده رمزگذاری شده است. اگر هر دو طرف با موفقیت پیام‌های «تمام شد» را رمزگشایی و MAC آن‌ها را تأیید کنند، دست‌دهی کامل می‌شود.[1][4]

پس از دست‌دهی، پروتکل رکورد TLS انتقال داده‌های برنامه را بر عهده می‌گیرد. لایه رکورد داده‌ها را به بلوک‌های قابل مدیریت ۲^۱۴ بایتی یا کمتر تکه‌تکه می‌کند. هر تکه فشرده شده، با استفاده از کلیدهای نشست متقارن رمزگذاری شده و با یک MAC که شامل یک شماره توالی است، ضمیمه می‌شود. این شماره توالی تضمین می‌کند که هر پیام گمشده، اضافی یا تکراری بلافاصله توسط طرف گیرنده شناسایی شود.[1]

این پروتکل دستخوش نوسازی تهاجمی شده است تا آسیب‌پذیری‌های قدیمی را حذف کند. MDN Web Docs گزارش می‌دهد که «همه مرورگرهای اصلی در اوایل سال ۲۰۲۰ شروع به حذف پشتیبانی از TLS ۱.۰ و ۱.۱ کردند»، به طوری که مرورگرهایی مانند فایرفاکس از نسخه ۷۴ به بعد خطای سخت «اتصال امن ناموفق» (Secure Connection Failed) را برمی‌گردانند.[2]

استقرار TLS ۱.۳ این نوسازی را با حذف کامل پشتیبانی از تبادل کلید RSA و کاهش شدید تعداد مجموعه‌های رمز پشتیبانی شده، تسریع می‌کند. با فرض روش تبادل کلید ترجیحی سرور، TLS ۱.۳ مذاکره رمزنگاری را به یک رفت و برگشت کاهش می‌دهد. برای بازدیدکنندگان بازگشتی، حالت ۰-RTT (زمان رفت و برگشت صفر) را معرفی می‌کند که به کلاینت اجازه می‌دهد داده‌های رمزگذاری شده برنامه را در همان اولین پیام خود ارسال کند.[4]

اتکای پروتکل به مراجع صدور گواهی شخص ثالث (Certificate Authorities) همچنان آسیب‌پذیری ساختاری اصلی آن است. اگر یک CA مورد اعتماد به خطر بیفتد یا مجبور شود، مهاجمان می‌توانند گواهی‌های جعلی صادر کنند که فاز احراز هویت دست‌دهی را به طور کامل دور می‌زنند. تا زمانی که مدل‌های احراز هویت مبتنی بر DNS به پذیرش گسترده دست یابند، قطعیت ریاضیاتی دست‌دهی TLS همچنان به امنیت عملیاتی سازمان‌هایی که گواهی‌ها را صادر می‌کنند، وابسته خواهد بود.[3][5][7]