CORE · مفاهیم رمزنگاری

TLS — امنیت لایه‌ی انتقال

Transport Layer Security

TLS پروتکلِ رمزنگاریِ ارتباط بین مرورگر و سرور است، و وضعیت استانداردهایش در سال ۲۰۲۶ به‌طور معناداری تغییر کرده: RFC 9846 اکنون مشخصاتِ جاریِ TLS 1.3 است و مجموعه‌ای از سوئیت‌های رمزِ قدیمیِ TLS 1.2 منسوخ شده‌اند.

تیم فنی پی‌هانتر

TLS چیست و چه می‌کند؟

TLS (Transport Layer Security) پروتکلی است که سه تضمین را برای ارتباطِ شبکه فراهم می‌کند: محرمانگی (رمزنگاریِ داده)، یکپارچگی (تشخیصِ دستکاری) و احراز هویتِ سرور (و اختیاراً کلاینت) از راه گواهی دیجیتال. همان چیزی که HTTPS را از HTTP جدا می‌کند. توجه کنید که «SSL» به‌عنوان نامِ پروتکل از ۱۹۹۹ منسوخ است، هرچند در نام‌های تجاری («گواهی SSL») باقی مانده.

نسخه‌ی جاری TLS 1.3 است که دست‌دادن (handshake) سریع‌تر و امن‌تری دارد و پیش‌روبه‌جلو (Forward Secrecy) را به‌صورت ذاتی اجبار می‌کند.

استانداردهای جاری در ۲۰۲۶ — دقیق باشید

باور غلط رایج

«TLS 1.3 یعنی RFC 8446.» این دیگر مشخصاتِ جاری نیست. از ژوئیه‌ی ۲۰۲۶، RFC 9846 مشخصاتِ جاریِ TLS 1.3 است و RFC 8446 را منسوخ می‌کند (و همچنین RFC 5246 مربوط به TLS 1.2 را). RFC 9846 یک به‌روزرسانیِ جزئیِ TLS 1.3 با همان شماره‌ی نسخه است که الزامات را سخت‌تر و ابهام‌ها را رفع می‌کند. برای یک مرجعِ ۲۰۲۶، RFC 9846 را به‌عنوان مشخصاتِ جاری ارجاع دهید، نه RFC 8446.

نسخه‌های قدیمی: TLS 1.0 و 1.1 و DTLS 1.0 با RFC 8996 (مارس ۲۰۲۱) رسماً منسوخ و به وضعیتِ Historic منتقل شده‌اند و نباید مذاکره شوند. SSL 2.0 و 3.0 پیش‌تر منسوخ شده بودند.

TLS 1.2 دیگر «همین‌طور که هست» قابل قبول نیست

مهم‌ترین تغییرِ تازه اینجاست. RFC 10015 (ژوئیه‌ی ۲۰۲۶) با عنوان «منسوخ‌کردن روش‌های قدیمیِ تبادل کلید در TLS 1.2 و DTLS 1.2» الزام می‌کند که کلاینت‌ها نباید پیشنهاد دهند و سرورها نباید انتخاب کنند:

  • سوئیت‌های رمزِ RSA (انتقالِ کلیدِ ایستا، یعنی TLS_RSA_WITH_*)
  • سوئیت‌های FFDH (دیفی‌هلمنِ میدانِ متناهیِ غیرگذرا)
  • سوئیت‌های FFDHE (یعنی DHE_* کلاسیک)

رویِ‌هم بیش از ۱۳۰ سوئیتِ رمز منسوخ می‌شوند. نتیجه‌ی عملی: TLS 1.2 فقط با ECDHE + AEAD قابل قبول است — یعنی ECDHE_ECDSA یا ECDHE_RSA همراه با AES-GCM یا ChaCha20-Poly1305. ECDHِ غیرگذرا صرفاً «توصیه‌نشده» است، نه ممنوع.

BCP 195 و پایه‌ی توصیه‌شده

مجموعه‌ی BCP 195 («توصیه‌هایی برای استفاده‌ی امن از TLS/DTLS») اکنون از سه RFC تشکیل شده: RFC 8996 (منسوخ‌کردن TLS 1.0/1.1)، RFC 9325 (توصیه‌های استفاده‌ی امن)، و افزوده‌ی تازه RFC 9852 با عنوان «پروتکل‌های جدیدِ متکی بر TLS باید TLS 1.3 را الزام کنند». پایه‌ی عملی برای یک یافته‌ی تست نفوذ:

  • TLS 1.3 را فعال کنید.
  • TLS 1.2 را فقط برای سازگاری و تنها با ECDHE + AEAD نگه دارید.
  • TLS 1.0/1.1 و همه‌ی SSL را غیرفعال کنید.
  • HSTS با max-age بلند، includeSubDomains و در صورت امکان preload.
  • ثبتِ Certificate Transparency و رکوردهای CAA.

چطور در تست نفوذ بررسی می‌شود

ارزیابیِ TLS بخشِ استانداردی از هر بررسی امنیتی سایت است. ابزارها: testssl.sh، sslyze، اسکریپتِ ssl-enum-ciphers در Nmap و SSL Labs. تستر بررسی می‌کند که نسخه‌های منسوخ مذاکره نشوند، سوئیت‌های RSA/FFDHE در TLS 1.2 بسته باشند، گواهی معتبر و زنجیره کامل باشد، و هدرهای HSTS درست تنظیم شده باشند. خطاهای رایجِ گواهی در راهنمای خطای گواهی SSL پوشش داده شده‌اند.

نکته‌ای که در عمل زیاد دیده می‌شود: بسیاری از سرورها TLS 1.3 را درست پیکربندی کرده‌اند اما هم‌زمان TLS 1.0/1.1 یا سوئیت‌های ضعیفِ TLS 1.2 را هم برای «سازگاری» باز نگه داشته‌اند. مهاجم همیشه ضعیف‌ترین گزینه‌ی مذاکره‌شدنی را هدف می‌گیرد، پس صرفِ فعال‌بودنِ TLS 1.3 کافی نیست؛ باید گزینه‌های ضعیف بسته شوند. برای درکِ جایگاهِ TLS در تصویرِ بزرگ‌تر، تست نفوذ وب این بررسی را در کنارِ دیگر لایه‌ها انجام می‌دهد.

پینینگ، پساکوانتوم و ارتباط با OWASP

باور غلط رایج

«برای امنیت بیشتر HPKP را فعال کنید.» HPKP (پینینگِ کلیدِ عمومیِ HTTP) مرده است و سال‌ها پیش از مرورگرها حذف شد؛ آن را توصیه نکنید. جایگزینِ آن ترکیبِ Certificate Transparency + رکوردهای CAA است.

درباره‌ی پساکوانتوم: تبادلِ کلیدِ ترکیبی (hybrid) در مرورگرها و CDNهای بزرگ در حال گسترش است؛ جهت‌گیری روشن است اما از ذکرِ آمارِ دقیقِ استقرار پرهیز کنید. در OWASP، ضعف‌های TLS زیر A04:2025 خطاهای رمزنگاری قرار می‌گیرند (CWE-327 استفاده از الگوریتم رمزِ شکسته یا پرخطر).

پرسش‌های متداول

نسخه‌ی جاری مشخصاتِ TLS 1.3 کدام RFC است؟

از ژوئیه‌ی ۲۰۲۶، RFC 9846 مشخصاتِ جاریِ TLS 1.3 است و RFC 8446 را منسوخ می‌کند. برای یک مرجعِ به‌روز باید RFC 9846 ارجاع داده شود.

آیا TLS 1.2 هنوز قابل قبول است؟

بله، اما فقط با ECDHE + AEAD. طبق RFC 10015 (ژوئیه‌ی ۲۰۲۶) سوئیت‌های RSA، FFDH و FFDHE در TLS 1.2 نباید پیشنهاد یا انتخاب شوند — بیش از ۱۳۰ سوئیت منسوخ شده‌اند.

آیا باید HPKP را برای امنیت بیشتر فعال کنم؟

خیر. HPKP از مرورگرها حذف شده و منسوخ است. به‌جای آن از Certificate Transparency و رکوردهای CAA استفاده کنید.

درباره‌ی رمزنگاری پساکوانتومی چه باید بدانم؟

تبادلِ کلیدِ ترکیبیِ پساکوانتوم در مرورگرها و CDNهای بزرگ در حال گسترش است و جهت‌گیریِ صنعت روشن است. توصیه می‌شود سازمان‌ها برای این گذار آماده شوند، اما از استناد به آمارِ دقیقِ استقرار پرهیز کنید.

پیشگیری / رفع

پیکربندی امنِ TLS در ۲۰۲۶:

  • TLS 1.3 را فعال کنید و آن را به‌عنوان نسخه‌ی ترجیحی قرار دهید (مشخصاتِ جاری: RFC 9846).
  • TLS 1.2 را تنها با ECDHE + AEAD نگه دارید؛ طبق RFC 10015 همه‌ی سوئیت‌های RSA و FFDHE/DHE را ببندید.
  • TLS 1.0/1.1، DTLS 1.0 و همه‌ی نسخه‌های SSL را غیرفعال کنید (RFC 8996).
  • HSTS با عمر بلند، includeSubDomains و preload.
  • HPKP را به کار نبرید؛ به‌جای آن Certificate Transparency و رکوردهای CAA.
  • گواهی را از CA معتبر بگیرید، زنجیره را کامل کنید و پیش از انقضا تمدید کنید.
  • پیکربندی را با testssl.sh یا SSL Labs راستی‌آزمایی کنید.
→ بازگشت به دانشنامه
PUT IT TO THE TEST

امنیت سامانه‌ی شما را
به مهاجمان واگذار نکنید

تیم پی‌هانتر با دیدِ یک مهاجم واقعی، این آسیب‌پذیری‌ها و ده‌ها مورد دیگر را روی دارایی‌های شما می‌سنجد.