پروتکل امنیت لایه انتقال (TLS) ستون فقرات حریم خصوصی داده‌ها در وب نوین، ارتباطات سازمانی و تونل‌های رمزنگاری‌شده نرم‌افزاری به شمار می‌رود. در زمان توسعه نسخه TLS 1.2 (استاندارد RFC 5246) و نگارش‌های پیشین، طراحان بر این باور بودند که ترکیب اعداد تصادفی دو سمت ارتباط با یک راز مقدماتی مشترک (premaster secret)، برای تفکیک کامل و ایمن میان اتصالات شبکه کافی خواهد بود. با این حال، تجارب بعدی نشان داد که این فرض بنیادین دارای نقصی امنیتی است.

در سال ۲۰۱۴، پژوهشگران عرصه رمزنگاری از حمله موسوم به «دست‌دادن سه‌باره» (Triple Handshake Attack) پرده برداشتند؛ خطایی ساختاری در پروتکل‌های TLS 1.0 تا 1.2 که به مهاجم میانی (MiTM) امکان می‌داد کلید اصلی (Master Secret) دو ارتباط کاملاً مجزا را یکسان‌سازی کند. مهاجم با دستکاری فرآیندهای مذاکره مجدد (renegotiation) و بازیابی نشست (session resumption)، می‌توانست دو کانال مجزا را به یکدیگر پیوند زده، هویت کلاینت احرازشده را جعل کند یا ترافیک رمزشده را شنود نماید. استاندارد RFC 7627 با معرفی افزونه کلید اصلی گسترش‌یافته (Extended Master Secret یا EMS)، با گره زدن مستقیم کلیدهای نهایی به خلاصه رمزنگاری‌شده کل پیام‌های دست‌دادن، این چالش را به صورت ریشه‌ای برطرف نمود.

کلید اصلی سنتی در TLS 1.2 (فاقد پیوند با پیام‌های پیشین دست‌دادن):
pre_master_secret + ClientHello.random + ServerHello.random ──> PRF ──> master_secret
                └──> حاوی هیچ نشانه‌ای از گواهی‌های دیجیتال سرور یا پارامترهای توافق نیست!

معماری Extended Master Secret در RFC 7627 (پیوند مستقیم با Session Hash):
pre_master_secret + "extended master secret" + session_hash ──> PRF ──> extended_master_secret
                                                     │
               ┌─────────────────────────────────────┴─────────────────────────────────────┐
               ▼                                                                           ▼
[ClientHello, ServerHello, ServerCertificate, ServerKeyExchange, ClientKeyExchange] ──> خلاصه درهم‌سازی
               └──> پیوند ریاضی استوار مانع از سرقت هویت و الصاق ناخواسته نشست‌ها می‌شود.

آسیب‌پذیری سنتی در پروتکل TLS: فقدان پیوند با پیشینه دست‌دادن

برای پی بردن به چرایی ضرورت افزونه Extended Master Secret، باید شیوه تولید کلید در نسخه‌های پیشین و چگونگی همگام‌سازی ناخواسته نشست‌ها را بررسی نمود.

چرایی نادیده گرفتن پیشینه ارتباط در اشتقاق سنتی کلید اصلی

در استاندارد پایه TLS 1.2 (بخش ۸.۱ سند RFC 5246)، پس از پایان دادوستد کلید، طرفین به کمک تابع شبه‌تصادفی (PRF) یک کلید ۴۸ بایتی موسوم به master_secret تولید می‌کردند:

$$\text{master_secret} = \text{PRF}(\text{pre_master_secret}, \text{"master secret"}, \text{ClientHello.random} ,|, \text{ServerHello.random})$$

این فرمول محاسباتی تنها به سه ورودی متکی بود: ۱. مقدار راز اولیه pre_master_secret (به دست آمده از روش رمزنگاری RSA یا الگوریتم زودگذر دیفی-هلمن). ۲. بردار تصادفی ۳۲ بایتی ارسال‌شده توسط کلاینت (ClientHello.random). ۳. بردار تصادفی ۳۲ بایتی پاسخ سرور (ServerHello.random).

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

کالبدشکافی ساختار حمله دست‌دادن سه‌باره Triple Handshake

نبود پیوند با پیشینه گفتگو، زمینه را برای رخ دادن حمله دست‌دادن سه‌باره فراهم کرد:

مراحل الصاق نشست در حمله دست‌دادن سه‌باره:
کلاینت کاربر              مهاجم میانی (MiTM)                   سرور اصلی مقصد
  │                               │                                 │
  ├── ClientHello (Random_C) ────►├── ClientHello (Random_C) ──────►│
  │                               │   (انتقال عدد تصادفی کلاینت)    │
  │◄── ServerHello (Random_S) ────┼◄── ServerHello (Random_S) ──────┤
  │    گواهی مهاجم                │    گواهی سرور اصلی              │
  │                               │                                 │
  │  [ارتباط اول: کلاینت ──► مهاجم]       [ارتباط دوم: مهاجم ──► سرور اصلی]
  │  هر دو نشست مقادیر کاملاً یکسان Random_C، Random_S و راز اولیه دارند!
  │                               │
  ▼                               ▼
تولید کلید اصلی یکسان در هر دو نشست فرعی (MS_1 == MS_2)
  │
  ├── بازیابی نشست / مذاکره دوباره با گواهی اعتبارسنجی کلاینت ──────►
  │   (مهاجم امضای هویتی کلاینت را روی نشست سرور الصاق می‌کند)
  ▼
مهاجم بدون داشتن کلید خصوصی کلاینت احراز هویت می‌شود؛ نفوذ کامل به کانال

این حمله در سه گام متصل رخ می‌داد: ۱. همگام‌سازی دست‌دادن اولیه: کاربر به سروری متصل می‌شود که در کنترل مهاجم است. همزمان، مهاجم ارتباطی با سرور مقصد اصلی می‌سازد. با بازتاب دادن اعداد تصادفی و انتخاب پارامترهای یکسان دیفی-هلمن، هر دو کانال به تولید کلید master_secret یکسانی می‌رسند. ۲. بازیابی نشست: مهاجم با کمک سازوکار بازیابی جلسه، ارتباط خود با سرور اصلی را فعال می‌کند. ۳. الصاق در مذاکره دوباره: زمانی که سرور اصلی احراز هویت متقابل (mTLS) را طلب می‌کند، کاربر پیام تأیید را روی ارتباط خود امضا می‌نماید. از آنجا که کلیدهای دو سمت یکسان است، مهاجم امضا را به سرور اصلی فرستاده و با هویت کاربر احراز می‌شود.

معماری استاندارد RFC 7627: پیوند رمزنگاری از طریق Session Hash

سند RFC 7627 با تغییر بنیادین فرمول تولید کلید، امکان چنین حملاتی را از میان برداشت. این استاندارد به جای اکتفا به متغیرهای تصادفی، کلید را به چکیده رمزنگاری‌شده تمام پیشینه دست‌دادن متصل می‌کند.

محاسبه درهم‌سازی نشست در مراحل گوناگون تبادل کلید

بخش مرکزی استاندارد RFC 7627 متغیر session_hash است؛ مقداری که از درهم‌سازی کلیه پیام‌های مبادله‌شده از ClientHello تا ClientKeyExchange حاصل می‌آید:

$$\text{session_hash} = \text{Hash}(\text{ClientHello} ,|, \text{ServerHello} ,|, \text{Certificate}^* ,|, \text{ServerKeyExchange}^* ,|, \text{ClientKeyExchange})$$

  • در نسخه TLS 1.2، الگوریتم درهم‌سازی توسط تابع PRF برگزیده (مانند SHA-256 یا SHA-384) تعیین می‌گردد.
  • تمام بایت‌های گواهی‌های دیجیتال سرور در این محاسبه وارد می‌شوند.
  • پارامترهای منحنی بیضوی ECDHE و امضاهای دیجیتال متناظر نیز درون این چکیده قفل می‌گردند.

چنانچه مهاجمی قصد تعویض گواهی یا تغییر پارامترها را داشته باشد، مقدار session_hash در دو سمت به کلی دگرگون خواهد شد.

سازوکار بنیادین اشتقاق کلید Extended Master Secret

با توافق دو طرف روی افزونه extended_master_secret (با شناسه 0x0017 یا عدد ۲۳)، تابع تولید کلید به شکل زیر بازنویسی می‌شود:

$$\text{extended_master_secret} = \text{PRF}(\text{pre_master_secret}, \text{"extended master secret"}, \text{session_hash})$$

استفاده از session_hash دستاوردهای زیر را محقق می‌سازد:

  • مقاومت در برابر تداخل: از آنجا که کلیه مشخصات تبادل در درهم‌سازی لحاظ شده، دو اتصال تنها در شرایطی می‌توانند کلید یکسانی تولید کنند که سراسر مکالمات آنها کاملاً همتا باشد.
  • تفکیک کامل بستر: حتی اگر مهاجمی راز اولیه یک ارتباط را به دست آورد، هرگز قادر به بهره‌گیری از آن روی کانالی با گواهی یا آدرس دیگر نخواهد بود.

لایه‌های حفاظتی در چرخه‌های بازیابی نشست و مذاکره دوباره

استاندارد RFC 7627 قواعد سخت‌گیرانه‌ای برای جلوگیری از حملات بازگشت به نگارش‌های ضعیف‌تر وضع نموده است.

جدول وضعیت نشست‌ها بر اساس استاندارد RFC 7627:
وضعیت پیشین نشست       | وضعیت در درخواست بازیابی | تصمیم سامانه         | برآیند امنیتی
-----------------------+--------------------------+----------------------+-----------------------------------------
کلید سنتی Master Secret| همراه با نشانگر EMS      | رد بازیابی / دست‌دادن| جلوگیری از کاهش امنیت؛ آغاز اتصال نوین
Extended Master Secret | فاقد نشانگر EMS          | رد فوری و قطع اتصال  | شناسایی دستکاری؛ خنثی‌سازی نفوذ
Extended Master Secret | دارای نشانگر معتبر EMS   | تأیید بازیابی امن    | ادامه ارتباط پایدار با پیوند کامل

۱. انسداد پیوند متقاطع میان نشست‌ها و جعل هویت کاربر: اگر اتصالی با کلید اصلی گسترش‌یافته آغاز شده باشد، درخواست‌های بازیابی آن نیز حتماً باید شناسه EMS را داشته باشند. در صورت حذف این شناسه توسط مهاجم، مقصد دستکاری را تشخیص داده و با خطای handshake_failure اتصال را می‌بندد. ۲. الزام خروجی‌های استخراج کلید (RFC 5705): پروتکل‌های نوین مانند WebRTC و سازوکارهای تونل‌سازی از استاندارد RFC 5705 برای ساخت کلیدهای فرعی بهره می‌برند. RFC 7627 مقرر می‌کند که تمامی این خروجی‌ها باید الزاماً از کلید EMS مشتق شوند تا سلامت لایه‌های بعدی تضمین گردد.

فرآیند تکامل در پروتکل TLS 1.3: زمان‌بندی کلیدهای HKDF بر پایه پیشینه کامل

مبانی ارائه شده در RFC 7627 آن‌چنان کارآمد بودند که کارگروه IETF آن‌ها را مستقیماً در تاروپود نگارش TLS 1.3 (سند RFC 8446) جای داد.

در TLS 1.3، شیوه قدیمی منسوخ گردید و چارچوب چندمرحله‌ای HKDF جای آن را گرفت:

سلسله‌مراتب تولید کلید در TLS 1.3 بر پایه پیشینه کامل:
               راز اولیه (Early Secret / PSK)
                       │
                       ▼
             راز دست‌دادن (ECDHE) ──> HKDF-Expand(چکیده پیشینه ۱) ──> کلیدهای پیام‌های دست‌دادن
                       │
                       ▼
              راز اصلی ──────────────> HKDF-Expand(چکیده پیشینه ۲) ──> کلیدهای داده‌های برنامه

برخلاف نسخه پیشین، در TLS 1.3 نیازی به فعال‌سازی جداگانه افزونه نیست و تمام کلیدها ذرات پیشینه گفتگو را در خود دارند که سامانه را ذاتاً در برابر حملات دست‌دادن سه‌باره ایمن می‌سازد.

هزینه‌های پردازشی و ملاحظات هماهنگی با تراشه‌های سخت‌افزاری

یکی از دغدغه‌های کارشناسان زیرساخت، بررسی میزان افت احتمالی توان پردازش سرورها هنگام محاسبه مداوم چکیده‌ها است.

آزمایش‌های میدانی نشان می‌دهد که این بار پردازشی کاملاً ناچیز است:

  • هزینه اندک درهم‌سازی: حجم کل پیام‌های پیش از تبادل کلید معمولاً کمتر از ۴ کیلوبایت است. پردازش ۴ کیلوبایت با دستورات سخت‌افزاری تراشه‌های امروزی به زمانی کمتر از ۱۵ میکروثانیه نیاز دارد.
  • تسلط محاسبات نامتقارن بر مصرف توان: بیش از ۹۸ درصد توان پردازنده در یک اتصال به محاسبات پیچیده ریاضی (مانند ضرب نقاط منحنی‌های بیضوی و اعتبارسنجی امضاها) اختصاص دارد و سهم محاسبات EMS کمتر از ۰.۱ درصد از تأخیر کلی است.
  • سازگاری با شتاب‌دهنده‌های سخت‌افزاری: واحدهای امنیتی فیزیکی (HSM) و رابط‌های هسته لینوکس از این جریان پردازشی به راحتی و بدون تأخیر پشتیبانی می‌کنند.

امن‌سازی تونل‌های سازمانی: لایه دفاعی ترافیک در RiceGuard

در ساختار VPNRice، موتور محافظتی RiceGuard استاندارد RFC 7627 را به طور جامع بر تمامی مسیرهای پشتیبان TLS، بخش‌های مدیریتی و ترافیک کاربری اعمال می‌نماید.

ساختار امنیت مبتنی بر اعتماد صفر در RiceGuard:
پایانه کاربر / نرم‌افزار متصل
  │  آغاز ارتباط امن TLS 1.2/1.3 با سرورهای لبه RiceGuard
  ▼
بررسی دقیق و سخت‌گیرانه خط‌مشی‌های رمزنگاری
  │  - الزام استفاده از افزونه EMS (کد 0x0017)
  │  - اجرای پنهان‌سازی پیشرو (PFS با Curve25519)
  │  - مسدود کردن ارتباطات فاقد پیوند تاریخچه
  ▼
محاسبه و تثبیت درهم‌سازی Session Hash
  │  - قفل کردن زنجیره گواهی‌ها و متغیرهای ECDHE
  │  - اتصال خروجی‌های RFC 5705 به خلاصه نشست
  ▼
سرورهای پایدار و پرظرفیت RiceGuard
  │  - دفع کامل خطرات الصاق متقاطع نشست و نفوذ MiTM
  │  - حفظ اصالت اعتبارسنجی متقابل mTLS
  ▼
شبکه حفاظت‌شده داخلی / زیرساخت رمزنگاری سازمانی

۱. خط‌مشی الزامی EMS: سامانه RiceGuard استانداردهای محکمی دارد؛ در محیط‌هایی که برای سازگاری نیازمند ارائه TLS 1.2 هستند، هر ارتباطی که فاقد افزونه EMS باشد فوراً قطع می‌گردد. ۲. نشان‌های متصل به کانال: برای سازوکارهای اعتبارسنجی نوین، سیستم از شناسه‌های حاصل از EMS بهره می‌برد تا امکان استفاده مجدد از داده‌های هویتی در بسترهای دیگر وجود نداشته باشد. ۳. بازیابی مطمئن نشست‌ها: هنگام تغییر وضعیت دستگاه‌ها میان شبکه‌های بیسیم و ارتباطات تلفن همراه، داده‌های بازیابی با خلاصه‌های پیشین مطابقت داده شده تا پیوستگی ارتباط بدون ریسک‌های امنیتی حفظ گردد.

آزمون و ارزیابی سیستمی: بررسی وضعیت EMS در بسته OpenSSL و هسته لینوکس

مدیران شبکه می‌توانند با ابزارهای متعارف وضعیت فعال بودن RFC 7627 را در سرورها محک بزنند.

بررسی حضور افزونه Extended Master Secret در پیام‌های ClientHello

با استفاده از دستور openssl s_client می‌توان پشتیبانی سرور از این افزونه را بررسی نمود:

# برقراری اتصال با نمایش جزییات افزونه‌های مذاکره‌شده
openssl s_client -connect vpn.example.com:443 -tls1_2 -tlsextdebug -status

در گزارش خروجی عبارتی مشابه خط زیر را جستجو کنید:

TLS server extension "extended master secret" (id=23), len=0

طول صفر نشان‌دهنده هماهنگی صحیح سرور با مشخصات این استاندارد است.

اعتبارسنجی پرچم‌های مذاکره در OpenSSL و سوکت‌های سیستمی هسته

در ساختارهای نرم‌افزاری می‌توان وضعیت ارتباط را به صورت برنامه‌نویسی بررسی کرد:

/* قطعه کد زبان C برای بررسی وضعیت EMS در کتابخانه OpenSSL */
#include <openssl/ssl.h>

void audit_connection_security(SSL *ssl) {
    if (SSL_get_extms_support(ssl)) {
        printf("RFC 7627 Extended Master Secret: فعال (پیوند تاریخچه دست‌دادن)\n");
    } else {
        printf("هشدار: استفاده از کلید سنتی! خطر الصاق نشست وجود دارد.\n");
    }
}

در نگارش‌های OpenSSL 1.1.1 به بعد این قابلیت به شکل پیش‌فرض فعال است و می‌توان در فایل /etc/ssl/openssl.cnf آن را اجباری نمود:

[system_default_sect]
Options = ExtendedMasterSecret

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

برای برپایی تونل‌های پایدار مبتنی بر اعتماد صفر و مجهز به پیوند رمزنگاری دقیق نشست‌ها، دریافت VPNRice.