أوشك العمل على الإصدار الجديد من بروتوكول TLS 1.3 على الانتهاء. بعد أربع سنوات من المناقشة في مارس 2018 ، وافقت IETF على
النسخة 28 من المسودة كمعيار مقترح ، لذلك يجب أن تكون الأخيرة قبل اعتماد المواصفات النهائية.
تعمل TLS 1.3 على تسريع عملية إنشاء اتصال آمن بمقدار النصف تقريبًا من خلال الجمع بين عدة خطوات في هذه المرحلة. بالإضافة إلى ذلك ، تنفذ نظامًا من السرية المباشرة الكاملة من خلال المفاتيح المؤقتة (EC) DH. يضمن هذا الوضع حماية مفاتيح الجلسات حتى في حالة اختراق المفاتيح طويلة المدى.
تم تنفيذ العديد من التحسينات الأخرى ، بما في ذلك دعم تشفير دفق ChaCha20 ، وخوارزميات التوقيع الرقمي Ed25519 و Ed448 ، وبروتوكولات تبادل المفاتيح x25519 و x448 ، وما إلى ذلك. إزالة الدعم لوظائف التجزئة القديمة MD5 و SHA-224 ، والمنحنيات الإهليلجية الضعيفة ونادرًا ما تستخدم
ولكن الأكثر إثارة للاهتمام هو الفكرة الجديدة التي تجري
مناقشتها في IETF . يقترح خبراء Google بشكل دوري إنشاء إصدار جديد من بروتوكول TLS بشكل عشوائي مع تغييرات طفيفة. الفكرة هي أن التحديثات المتكررة ستكون ترياقًا للتحجر الخطير.
ما هذه المشكلة؟
ما يسمى بـ "التعظم" هو موقف يدرك فيه مطورو البروتوكول فجأة أنه من الصعب إدخال أي تحسينات بسبب التوزيع الواسع النطاق للإصدار القديم ، والذي يناسب المستخدمين لسبب ما. في الواقع ، لم يعد الإصدار القديم يلبي متطلبات الأمان الحديثة والمواصفات الجديدة ، ولكن لا يمكن تنفيذه على أرض الواقع.
ويعتقد أن ما يسمى العقد المتوسطة ، أي بائعي الحلول في مجال "الأمن" ، أصبحت "الفرامل" الرئيسية على وجه التحديد مع تنفيذ TLS 1.3. إنهم ينصحون عملائهم لوصف
قواعد جدار الحماية المحددة مع مسح الشهادة عند مصافحة TLS. في الإصدار الجديد من المعيار ، يتم تشفير
شهادات SSL ، بحيث لن يتمكن الوسطاء من مسحها.
كيف سيعمل التحديث المستمر على حل مشكلة تعظم البروتوكول؟
يعد التحديث المستمر كل ستة أسابيع نمطًا مألوفًا من متصفح Chrome. في هذه الحالة ،
يضطر "المؤدون"
إلى الامتثال للمواصفات ، لأن التنفيذ غير المتوافق لن يعمل مع نسبة كبيرة من المستخدمين.
في القائمة البريدية لفريق عمل هندسة الإنترنت (IETF) ،
اقترح هذه الفكرة ديفيد بنجامين من مشروع Chromium. يكتب أن TLS 1.3 هو بروتوكول قابل للتوسيع متوافق مع الإصدارات السابقة مع TLS 1.2. يمكن تدحرجه تدريجيًا ، وتحديث التطبيقات الحالية لـ TLS 1.2. وهنا توجد مشاكل. لن تتمكن العديد من الخوادم غير المتوافقة من إنشاء اتصال في مرحلة TLS 1.3 ClientHello ، لذا سيتعين عليك التراجع لإنشاء اتصال باستخدام إصدار البروتوكول المدعوم.
يطرح ديفيد بنيامين فكرة كيفية تجنب هذه المشكلة في المستقبل. في مناقشة التدابير الوقائية ، يذكر
ثوابت البروتوكول المدرجة في البند 9.3 من المواصفات.
يجب أن تتوافق جميع نقاط النهاية والعقد المتوسطة مع الثوابت الموصوفة. على وجه الخصوص ، لا يمتلك العملاء الجدد والخوادم الجديدة الحق في تقليل مستوى المعلمات إلى الإصدار القديم. وبنفس الطريقة ، ليس للعقد المتوسطة الحق في القيام بذلك عند نقل الاتصال بين العميل والخادم المحدّث ولا يمكنها التأثير على المصافحة. ومع ذلك ، نظرًا لسرعة التحديث غير المتساوية ، يمكن للعملاء والخوادم المحدثة دعم إنشاء الاتصال باستخدام البروتوكول القديم ، ولكن فقط بالطريقة الصحيحة الموضحة في البند 9.3.
لكن الممارسة تبين أنه لا يكفي وصف السلوك المطلوب في المواصفات. كيفية
فرض العقد الوسيطة للوفاء بالقاعدة الرئيسية لمعالجة ClientHello - لتجاهل المعلمات غير المعروفة؟ لهذا ، تم
اقتراح طريقة
GREASE .
شحوم: ترياق ضد التعظم
GREASE (إنشاء ملحقات عشوائية واستدامة القابلية للتوسعة) هي طريقة لتوليد امتدادات
عشوائية لـ TLS والإصدار المستمر للإصدارات الجديدة من البروتوكول. يقترح ديفيد بنيامين إنشاء دورة إصدار قياسية مدتها ستة أسابيع ، والتي ستتزامن مع إصدار إصدارات جديدة من Chrome.
سيؤدي إصدار مثل هذه "البيانات المهملة" بأعداد كبيرة إلى إجبار الخوادم على الامتثال للقاعدة الرئيسية لمعالجة ClientHello لتجاهل المعلمات غير المعروفة. وسوف تنتشر أيضًا إلى العقد المتوسطة. حتى لا يتدخلوا في الاتصال بين العميل والخادم ، فإن القاعدة الأساسية بالنسبة لهم هي: إذا لم ترسل طلب ClientHello ، فليس لديك الحق في معالجة الاستجابة. وبالمثل ، ينبغي إغراق النظام البيئي بعدد كبير من هذه الاستجابات.
"باختصار ، نخطط لختم الإصدارات الجديدة بانتظام من TLS (وربما معلمات حساسة أخرى مثل الإضافات)" ، يقول بنيامين ، معربًا عن وجهة نظر Google على ما يبدو. - كل ستة أسابيع تقريبًا ، وفقًا لجدول إصدار Chrome. بعد ذلك ، سيدعم Chrome وخوادم Google وكل من يريد المشاركة إصدارين (أو أكثر) من TLS 1.3: المستقر القياسي القياسي 0x0304 والإصدار البديل المؤقت. كل ستة أسابيع ، نختار عشوائيًا نقطة رمز جديدة. في جميع النواحي الأخرى ، تتطابق هذه الإصدارات مع 1.3 ، مع استثناء محتمل للتفاصيل الثانوية لفصل المفاتيح وإجراء تغييرات نحوية مسموح بها. الهدف هو تمهيد الطريق للإصدارات المستقبلية من TLS من خلال تقليدها (مسودة النسخة السلبية). "
مثل هذا المخطط له مخاطر معينة ، بما في ذلك تصادم نقاط الرمز. بالإضافة إلى ذلك ، يجب تطوير الاحتياطات ، لأن المهمة هي الحفاظ على تمدد TLS والحفاظ عليه ، وعدم التدخل في تطوير البروتوكول. من التدابير الاحترازية:
- توثيق مفصل لجميع نقاط الرمز (عند العمل على نقطة واحدة في شهر ونصف ، ستكون كافية لأكثر من 7000 سنة).
- تجنب الاصطدام الاستباقي: رفض الأرقام التي قد تختارها IETF.
- لن يقوم BoringSSL بتمكين هذا الخيار بشكل افتراضي. سيتم تمكينه فقط حيث يمكن تعطيله: على الخوادم وفي المتصفح. في الواقع ، على الأرجح ، في كل لحظة من الزمن ، سيتم استخدام نقاط الرمز القليلة الأخيرة فقط. نظرًا لأنها تتغير بسرعة ، لا ينبغي ربط النظام البيئي بأي توسع مؤقت من هذا القبيل ، وستظل عمليات التنفيذ متوافقة مع بعضها البعض.
- إذا لم تعمل الطريقة لسبب ما ، يمكن إيقاف التجربة في أي وقت.
الفكرة مثيرة للاهتمام ، وإذا بدأت Google في التصرف بهذه الطريقة ، يمكنها بالفعل إنقاذ النظام البيئي من "التعظم" الخطير بسبب موردي الحلول في مجال "الأمان" وأنظمة الشركات الأخرى المحددة.
أيد ممثل Cloudflare هذا الاقتراح. على أي حال ، قال ، على الأقل يجب القيام بشيء ما لتجنب المشكلة التي واجهناها عند محاولة تنفيذ TLS 1.3.
ووصفها عضو آخر في مجموعة عمل IETF بأنها "فكرة رائعة" واقترح أن تنشئ Google صفحة wiki تصف نقاط الشفرة التي تستخدمها أو تخطط لاستخدامها في المستقبل.
