چگونه دست‌دهی TLS 1.3 یک کلید نشست متقارن را تنها در یک رفت‌وبرگشت ایجاد می‌کند

نتیجه یک اتصال امن وب دیگر پس از یک مذاکره چندمرحله‌ای و رفت‌وبرگشتی مشخص نمی‌شود؛ بلکه درست در همان لحظه‌ای که کلاینت اولین بسته داده خود را در شبکه ارسال می‌کند، تکلیف کار روشن است. در پروتکل امنیت لایه انتقال (TLS) نسخه ۱.۳، دستگاه کلاینت منتظر نمی‌ماند تا ببیند سرور واقعاً از چه پارامترهای رمزنگاری پشتیبانی می‌کند تا بعد محاسبات را شروع کند. در عوض، یک حدس هوشمندانه می‌زند. کلاینت با تولید و ارسال پیش‌دستانه سهم کلید دیفی-هلمن (Diffie-Hellman) در همان پیام سلام اولیه، دست‌دهی رمزنگاری را مجبور می‌کند تا تنها در یک رفت‌وبرگشت (Round Trip) انجام شود و به این ترتیب، محدودیت سرعت فیزیکی ترافیک رمزنگاری‌شده اینترنت را اساساً تغییر می‌دهد.[1]

این اجرای پیش‌دستانه، تغییر مکانیکی اصلی در RFC 8446 است؛ استانداردی که توسط کارگروه مهندسی اینترنت (IETF) در آگوست ۲۰۱۸ منتشر شد. از نظر تاریخی، صنعت فناوری همیشه ارتقای رمزنگاری را با وعده‌های مبهم و مشتری‌پسندی مثل «امنیت در سطح نظامی» یا «معماری اعتماد صفر» بازاریابی کرده است. اما قابلیت واقعی ارائه‌شده در TLS 1.3 کاملاً ریاضی و ساختاری است: این پروتکل با تغییر ترتیب عملیات‌های رمزنگاری، زمان انتقال در شبکه را به شکل فیزیکی حذف می‌کند. در واقع، این پروتکل نوع جدیدی از رمزنگاری را اختراع نمی‌کند؛ بلکه صرفاً از منتظر ماندن برای دریافت اجازه شروع فرآیند رمزنگاری سر باز می‌زند.[1][6]

برای درک عظمت این تغییر، باید به محدودیت‌های مکانیکی نسخه قبلی آن نگاه کرد. در TLS 1.2 که در سال ۲۰۰۸ استانداردسازی شد و یک دهه امنیت اینترنت را تامین کرد، فرآیند دست‌دهی به دو رفت‌وبرگشت کامل (2-RTT) در شبکه نیاز داشت. کلاینت پیام «ClientHello» را می‌فرستاد و مجموعه‌های رمزنگاری پشتیبانی‌شده خود را لیست می‌کرد. سرور با انتخاب خود پاسخ می‌داد. تنها پس از دریافت این انتخاب بود که کلاینت پارامترهای تبادل کلید خود را تولید و ارسال می‌کرد و سرور را مجبور می‌ساخت تا برای بار دوم پاسخ دهد، پیش از آنکه حتی یک بایت داده کاربردی جریان یابد. در یک اتصال استاندارد فراآتلانتیک با ۱۵۰ میلی‌ثانیه تاخیر، این مذاکره ۳۰۰ میلی‌ثانیه زمان می‌برد تا حتی یک پیکسل از یک صفحه وب منتقل شود.[2][5]

پروتکل TLS 1.3 این تاخیر را با الزام کلاینت به گنجاندن سهم کلید خود — یعنی نیمه مربوط به خود در تبادل ریاضی و موقت دیفی-هلمن — در همان پیام اول از بین می‌برد. مستندات فنی SecureW2 درباره این پروتکل اشاره می‌کند: «برخلاف TLS 1.2، کلاینت به جای اینکه منتظر بماند تا سرور پارامترها را انتخاب کند، سهم کلید خود را در همان پیام اول می‌فرستد.» اگر کلاینت پارامترهای ترجیحی سرور را درست حدس بزند، سرور بلافاصله با سهم کلید خود، گواهی دیجیتالش و یک پیام «Finished» پاسخ می‌دهد. کلید نشست متقارن فوراً و بدون نیاز به درخواست دوم ایجاد می‌شود.[4]

این دست‌دهی 1-RTT تاخیر راه‌اندازی اتصال را در مقایسه با استاندارد قبلی دقیقاً ۵۰ درصد کاهش می‌دهد. برای دستگاه‌های موبایلی که در شبکه‌های سلولی با تاخیر بالا کار می‌کنند، یا حسگرهای اینترنت اشیا (IoT) که بسته‌های کوچک داده را از مکان‌های دورافتاده ارسال می‌کنند، این کاهش صرفاً یک بهینه‌سازی جزئی در عملکرد نیست. این امر پروفایل مصرف باتری و پاسخگویی تعاملی دستگاه را اساساً تغییر می‌دهد، زیرا آنتن رادیویی نیمی از زمان قبلی را صرف انتظار برای دریافت تاییدیه‌های رمزنگاری از سرورهای دوردست می‌کند تا بتواند خاموش شود یا محموله داده خود را ارسال کند.[2][4]

با این حال، بهبود سرعت مسلماً در درجه دوم اهمیت نسبت به دستورالعمل امنیتی تهاجمی این پروتکل قرار دارد. پروتکل TLS 1.3 عمداً سازگاری با نسخه‌های قبلی را می‌شکند تا از شر بار اضافی رمزنگاری‌های قدیمی که طی بیست سال انباشته شده بودند، خلاص شود. مهم‌تر از همه، این نسخه پشتیبانی از الگوریتم تبادل کلید RSA را که در نسخه‌های پیش از ۱.۳ بسیار رایج بود، کاملاً حذف می‌کند. در یک تبادل سنتی RSA، کلاینت راز پیش‌مستر را با کلید عمومی ثابت سرور رمزنگاری می‌کند. اگر یک مهاجم امروز ترافیک رمزنگاری‌شده را ضبط کند و سال‌ها بعد موفق به سرقت کلید خصوصی سرور شود، می‌تواند کل نشست تاریخی را به صورت عطف به ماسبق رمزگشایی کند.[2][5]

با حذف کامل تبادل کلید RSA، پروتکل TLS 1.3 پنهان‌سازی کامل پیش‌رو (PFS) را برای تک‌تک اتصالات الزامی می‌کند. ویژگی PFS بر تبادل کلید منحنی بیضوی موقت دیفی-هلمن (ECDHE) متکی است، جایی که کلیدهای نشست در همان لحظه برای آن اتصال خاص تولید شده و بلافاصله پس از بسته شدن نشست به لحاظ ریاضی نابود می‌شوند. تحلیل SecureW2 تایید می‌کند: «این پروتکل تمام مجموعه‌های رمزنگاری قدیمی را حذف کرده و رمزنگاری AEAD با پنهان‌سازی پیش‌رو را در هر نشست الزامی می‌کند.» حتی اگر کلید خصوصی بلندمدت یک سرور در سال ۲۰۲۶ لو برود، ارتباطات گذشته به لحاظ ریاضی قفل مانده و برای مهاجم کاملاً غیرقابل دسترس خواهند بود.[4]

این پروتکل همچنین یک ویژگی به شدت بازاریابی‌شده اما به دقت بررسی‌شده به نام ازسرگیری نشست 0-RTT را معرفی می‌کند. اگر کلاینتی قبلاً به یک سرور خاص متصل شده باشد، می‌تواند از یک «راز اصلی ازسرگیری» مشترک که از اتصال قبلی به دست آمده، استفاده کند تا داده‌های کاربردی رمزنگاری‌شده را در همان پیام اول خود ارسال کند. تحلیل معماری کلادفلر (Cloudflare) توضیح می‌دهد که «کلاینت می‌تواند از این راز مشترک استفاده کند تا داده‌های رمزنگاری‌شده را در اولین پیام از نشست بعدی، همراه با بلیت آن نشست، به سرور بفرستد» و عملاً تاخیر دست‌دهی را به صفر میلی‌ثانیه کاهش دهد.[2]

در حالی که 0-RTT تاخیر دست‌دهی را کاملاً از بین می‌برد، یک آسیب‌پذیری جدی در برابر حملات تکرار (Replay Attacks) ایجاد می‌کند. از آنجا که داده‌های اولیه 0-RTT توسط یک دست‌دهی تعاملی و تازه که زنده بودن کلاینت را ثابت کند محافظت نمی‌شوند، مهاجمی که بسته را رهگیری می‌کند می‌تواند به سادگی آن را دوباره به سرور بفرستد. اگر آن بسته حاوی دستوری برای تغییر وضعیت باشد — مانند نوشتن در پایگاه داده، یک تراکنش مالی یا حذف حساب کاربری — سرور ممکن است آن عمل را دو بار اجرا کند. در نتیجه، مهندسان پروتکل پیاده‌سازی‌های 0-RTT را به شدت به درخواست‌های بی‌اثر مانند دستورات استاندارد HTTP GET که فقط داده‌ها را بازیابی می‌کنند، محدود می‌سازند.[1][6]

استقرار جهانی TLS 1.3 بدون اصطکاک نبوده است، به ویژه در محیط‌های سازمانی که به شدت تحت نظارت هستند. شبکه‌های شرکتی اغلب به «میدل‌باکس‌ها» — فایروال‌های تخصصی و سیستم‌های تشخیص نفوذ که ترافیک کارمندان را برای یافتن بدافزار و نشت داده رهگیری و بازرسی می‌کنند — متکی هستند. از آنجا که TLS 1.3 بخش عمده‌ای از پیام‌های دست‌دهی، از جمله گواهی سرور که مقصد را مشخص می‌کند، رمزنگاری می‌کند، این میدل‌باکس‌ها دیگر نمی‌توانند به صورت منفعلانه راه‌اندازی اتصال را برای اعمال سیاست‌های امنیتی شرکت یا فیلتر کردن دامنه‌های مخرب نظارت کنند.[3][6]

این تغییر ساختاری، مدیران شبکه را مجبور به یک مصالحه دشوار می‌کند. از آنجا که پروتکل دست‌دهی را رمزنگاری می‌کند، ذاتاً مانع از آن می‌شود که ابزارهای امنیتی قدیمی شبکه بتوانند بدافزارها یا سایر تهدیدات را در طول راه‌اندازی اتصال شناسایی کنند. برای حفظ دید در شبکه، بخش‌های فناوری اطلاعات سازمان‌ها اکنون مجبورند پروکسی‌های رمزگشایی فعال مستقر کنند. این پروکسی‌ها به عنوان رهگیرهای مجاز مرد میانی عمل می‌کنند، اتصال TLS 1.3 را در فایروال می‌شکنند، محموله داده را بازرسی کرده و پیش از ارسال به کلاینت دوباره آن را رمزنگاری می‌کنند؛ فرآیندی که معماری شبکه را پیچیده کرده و نگرانی‌های داخلی درباره حریم خصوصی را افزایش می‌دهد.[3][6]

با وجود این موانع در استقرار سازمانی، این پروتکل تقریباً در سراسر اینترنت عمومی به پذیرش همه‌گیر دست یافته است. IETF با کدگذاری سخت پارامترهای رمزنگاری در پیام سلام اولیه و سوزاندن پل‌های پشت سر به سمت رمزنگاری‌های قدیمی، استانداردی را مهندسی کرد که در آن سریع‌ترین مسیر، همزمان تنها مسیر امن است. مرز بعدی برای این پروتکل که در حال حاضر در قالب به‌روزرسانی‌هایی مانند RFC 9846 در دست تدوین است، شامل ادغام پارامترهای رمزنگاری پسا-کوانتومی می‌شود — تا اطمینان حاصل شود که دست‌دهی تک‌مرحله‌ای در برابر قابلیت‌های نظری رمزگشایی کامپیوترهای کوانتومی آینده نیز به لحاظ ریاضی امن باقی می‌ماند.[1][5]