يشكل بروتوكول أمان طبقة النقل (TLS) الركيزة الأساسية لحماية خصوصية البيانات عبر شبكة الإنترنت المعاصرة والروابط المؤسسية والأنفاق البرمجية المشفرة. وعند صياغة معايير TLS 1.2 (الموثقة في RFC 5246) والإصدارات السابقة لها، افترض مهندسو التشفير أن دمج القيم العشوائية الصادرة عن طرفي الاتصال مع سر أولي مشترك (premaster secret) يكفي لضمان عزل تشفيري كامل ومستقل بين الاتصالات المختلفة. غير أن هذا الافتراض النظري واجه ثغرة تشغيلية كبرى.

ففي عام 2014، كشف باحثو التشفير عن هجوم "المصافحة الثلاثية" (Triple Handshake Attack)، وهو خلل هيكلي في معايير TLS من الإصدار 1.0 حتى 1.2 يتيح لوسيط نشط في المسار (Man-in-the-Middle - MiTM) توحيد المفتاح الرئيسي (Master Secret) عبر جلستين منفصلتين تماماً. وعبر التلاعب بمجريات إعادة التفاوض واستئناف الجلسات، يتمكن المهاجم من دمج اتصالين مستقلين، منتحلاً صفة عميل موثوق أو معترضاً حركة البيانات المشفرة. وقد حسمت مواصفات RFC 7627 هذه المعضلة عبر تقديم ملحق المفتاح الرئيسي الممتد (Extended Master Secret أو EMS)، الذي يربط المفاتيح المشتقة ارتباطاً لا ينفصم بسجل التجزئة الشامل للمصافحة.

المفتاح الرئيسي التقليدي في TLS 1.2 (غير مرتبط بسجل الحوار):
pre_master_secret + ClientHello.random + ServerHello.random ──> PRF ──> master_secret
                └──> لا يتضمن شهادات الخادم أو معاملات تفاوض تبادل المفاتيح!

بنية المفتاح الممتد وفق RFC 7627 (مرتبط عبر تجزئة الجلسة Session Hash):
pre_master_secret + "extended master secret" + session_hash ──> PRF ──> extended_master_secret
                                                     │
               ┌─────────────────────────────────────┴─────────────────────────────────────┐
               ▼                                                                           ▼
[ClientHello, ServerHello, ServerCertificate, ServerKeyExchange, ClientKeyExchange] ──> ناتج التجزئة
               └──> إغلاق رياضي يحول دون دمج الجلسات أو انتحال الهوية عبر هجمات الوسيط.

ثغرة بروتوكول TLS التقليدي: غياب الارتباط بسجل المصافحة

لاستيعاب الأهمية المحورية لمفتاح EMS، يتعين دراسة الكيفية التي أتاح بها نظام توليد المفاتيح التقليدي حدوث هذا التزامن غير المرغوب فيه بين الجلسات.

أسباب تجاهل الاشتقاق القديم للمفتاح الرئيسي لمجريات الحوار

وفق المبادئ المعيارية لبروتوكول TLS 1.2 (القسم 8.1 من وثيقة RFC 5246)، يعتمد الطرفان بعد إنهاء تبادل المفاتيح على دالة شبه عشوائية (PRF) لحساب مفتاح رئيسي بطول 48 بايت:

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

تستند هذه العملية الحسابية إلى ثلاثة مدخلات فقط: ١. القيمة السرية الأولية المشتركة pre_master_secret (المتفق عليها عبر تشفير RSA أو تبادل ديفي-هيلمان المؤقت). ٢. متجه عشوائي بطول 32 بايت من العميل (ClientHello.random). ٣. متجه عشوائي بطول 32 بايت من الخادم (ServerHello.random).

وتكمن الثغرة الخطيرة هنا في خلو هذه الصيغة من أي مدخلات مستمدة من رسائل المصافحة المتبادلة فعلياً. فهي تتجاهل شهادة الخادم الرقمية وشهادة العميل ونوع خوارزمية التشفير المتفق عليها ومعاملات المنحنيات التشفيرية. ومع أن رسائل Finished في ختام المصافحة تفحص سلامة الرسائل، إلا أن هذا الإجراء يأتي متأخراً بعد تثبيت قيمة المفتاح الرئيسي بالفعل.

التشريح التقني لهجوم المصافحة الثلاثية Triple Handshake

أتاح هذا الانفصال بين المفتاح وسجل المصافحة تنفيذ هجوم المصافحة الثلاثية:

آلية دمج الجلسات في هجوم المصافحة الثلاثية:
العميل                     المهاجم الوسيط (MiTM)               الخادم الشرعي
  │                               │                                 │
  ├── ClientHello (Random_C) ────►├── ClientHello (Random_C) ──────►│
  │                               │   (تمرير القيمة العشوائية)      │
  │◄── ServerHello (Random_S) ────┼◄── ServerHello (Random_S) ──────┤
  │    شهادة المهاجم              │    شهادة الخادم الشرعي          │
  │                               │                                 │
  │  [المسار الأول: العميل ──► المهاجم]   [المسار الثاني: المهاجم ──► الخادم]
  │  يتطابق المساران في قيم Random_C و Random_S والقيمة السرية الأولية!
  │                               │
  ▼                               ▼
توليد مفتاح رئيسي متطابق تماماً في كلا المسارين (MS_1 == MS_2)
  │
  ├── استئناف الجلسة / إعادة التفاوض مع شهادة العميل mTLS ─────────►
  │   (يدمج المهاجم إثبات هوية العميل في اتصاله المباشر مع الخادم)
  ▼
ينتحل المهاجم هوية العميل أمام الخادم بالكامل؛ اختراق القناة الآمنة

يتدرج الهجوم عبر ثلاث محطات متناسقة: ١. تزامن المصافحة الأولية: يتصل العميل بخادم خبيث يشغله المهاجم. وفي اللحظة ذاتها، ينشئ المهاجم اتصالاً مع الخادم الشرعي، ويعيد توجيه القيم العشوائية ومعاملات ديفي-هيلمان لضمان توليد قيمة master_secret موحدة في كلا الاتصالين. ٢. استئناف الجلسة: يعيد المهاجم فتح الجلسة مع الخادم الشرعي مستنداً إلى بيانات الجلسة المخزنة سابقاً. ٣. دمج إعادة التفاوض: حين يطلب الخادم الشرعي إثبات هوية العميل المتبادلة (mTLS)، يوقع العميل بيانات الفحص ظناً منه أنه يتعامل مع خادمه المعتاد. وبما أن المفاتيح متطابقة، يمرر المهاجم التوقيع إلى الخادم الشرعي محققاً التوثيق بنجاح تحت ستار هوية العميل.

بنية RFC 7627: الإلزام التشفيري عبر تجزئة الجلسة Session Hash

قضت وثيقة 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 المحسوبة لدى العميل فوراً عن نظيرتها لدى الخادم.

دالة الاشتقاق الأساسية للمفتاح الرئيسي الممتد EMS

عندما يتفق الطرفان على تفعيل ملحق extended_master_secret (المعرف بالرمز 0x0017 أو بالقيمة العشرية 23)، تستبدل دالة الاشتقاق الصيغة القديمة لتصبح:

$$\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 اشتقاق كافة المفاتيح المصدرة من المفتاح الرئيسي الممتد حصراً لضمان الحصانة ذاتها.

التطور المعماري في 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(تجزئة-السجل-1) ──> مفاتيح رسائل المصافحة
                       │
                       ▼
              السر الرئيسي ────────> HKDF-Expand(تجزئة-السجل-2) ──> مفاتيح بيانات التطبيقات

وبخلاف الإصدار السابق الذي كان يستلزم التفاوض على ملحق إضافي، يقوم TLS 1.3 باشتقاق كافة المفاتيح مباشرة من التجزئة التراكمية للرسائل، مما يجعله محصناً ذاتياً ضد هجمات المصافحة الثلاثية دون الحاجة لإعدادات خاصة.

كفاءة الأداء ومتطلبات معالجات التشفير المادية المسرعة

يطرح مهندسو البنية التحتية تساؤلات مستمرة حول الأثر المحتمل لاحتساب نواتج التجزئة المستمرة على سرعة معالجة الخوادم ذات الكثافة العالية.

وتثبت الاختبارات الواقعية أن العبء الإضافي يكاد يكون منعدماً:

  • تكلفة التجزئة: لا يتجاوز الحجم الكلي للرسائل السابقة لتبادل المفاتيح 4 كيلوبايت. وتستغرق معالجة هذا الحجم باستخدام تعليمات المعالجات الحديثة (مثل Intel SHA أو تسريع ARM التشفيري) أقل من 15 ميكروثانية.
  • هيمنة العمليات اللامتماثلة: تستهلك الحسابات الرياضية المتقدمة (كالضرب القياسي على المنحنيات الإهليلجية والتحقق من التواقيع الرقمية) ما يزيد عن 98% من طاقة المعالج أثناء المصافحة، بينما لا تتعدى حصة تجزئة EMS نسبة 0.1% من إجمالي زمن التأخير.
  • توافق العتاد المسرع: تدعم وحدات الأمان المادية (HSM) وبرمجيات التشفير المدمجة في النواة تحديث نواتج التجزئة بصورة متدفقة ودون تأخير في خطوط المعالجة.

تحصين الأنفاق المؤسسية: منظومة الحماية في طبقة النقل عبر RiceGuard

تطبق منصة RiceGuard ضمن بيئة VPNRice متطلبات معيار RFC 7627 بصرامة على كافة مسارات TLS البديلة وواجهات الإدارة وقنوات التوجيه البرمجي.

معمارية حماية TLS القائمة على انعدام الثقة في RiceGuard:
محطة العميل / التطبيق المتصل
  │  بدء جلسة TLS 1.2/1.3 مع بوابات حافة RiceGuard
  ▼
التدقيق الصارم لسياسات التشفير
  │  - الإلزام التام بملحق Extended Master Secret (المعرف 0x0017)
  │  - تفعيل السرية التوجيهية التامة (PFS عبر Curve25519)
  │  - الرفض القاطع للجلسات القديمة الخالية من ربط السجل
  ▼
الاحتساب المستمر لتجزئة الجلسة Session Hash
  │  - تثبيت بيانات الشهادات ومعاملات تفاوض ECDHE
  │  - ربط مفاتيح التصدير RFC 5705 بناتج تجزئة الجلسة
  ▼
بوابات RiceGuard فائقة الاعتمادية
  │  - الإحباط الكامل لمحاولات دمج الجلسات وانتحال الهوية
  │  - حماية مسارات التحقق الثنائي mTLS في بيئات انعدام الثقة
  ▼
الشبكة المؤسسية المحمية / العمود الفقري المشفر دولياً

١. سياسة إلزامية لملحق EMS: تطبق RiceGuard معايير أمنية صارمة، حيث تقوم بحظر أي جلسة تتجاهل ملحق المفتاح الممتد في البيئات التي تتطلب دعم TLS 1.2 للتوافقية، قاطعة الطريق أمام محاولات استغلال الهوية. ٢. رموز توثيق مقترنة بالقناة: لتعزيز معايير انعدام الثقة، توظف RiceGuard مفاتيح مشتقة عبر معيار RFC 5705 تستند إلى مفتاح EMS، مما يمنع إعادة تمرير الرموز عبر قنوات موازية. ٣. إدارة مرنة للجلسات: عند تنقل الأجهزة بين شبكات Wi-Fi والاتصالات الخلوية، تفحص RiceGuard تذاكر استئناف الجلسات بمقارنتها مع خلاصات التجزئة المعتمدة، محافظة على استقرار الاتصال مع صيانة العزل التشفيري الكامل.

الفحص والتدقيق: اختبار ملحق EMS في حزم OpenSSL ونواة التشغيل

يستطيع مسؤولو الأنظمة التحقق من جاهزية الخوادم وتوافقها مع RFC 7627 عبر حزمة أدوات OpenSSL القياسية.

فحص وجود ملحق Extended Master Secret في رسائل ClientHello

باستخدام أداة openssl s_client، يمكن اختبار البوابة والتأكد من دعمها للملحق:

# إنشاء اتصال اختباري عبر TLS 1.2 واستعراض تفاصيل الملحقات
openssl s_client -connect vpn.example.com:443 -tls1_2 -tlsextdebug -status

ابحث في المخرجات عن السطر الدال على تفعيل الملحق:

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

يؤكد الطول المساوي للصفر نجاح الخادم في تمييز وتفعيل الملحق طبقاً لمتطلبات وثيقة RFC 7627.

التحقق من مؤشرات التفاوض في 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.