في بداية العام ، في التقرير المتعلق بالمشكلات وإمكانية الوصول إلى الإنترنت للفترة 2018-2019 ، كتبنا بالفعل أن انتشار TLS 1.3 أمر لا مفر منه. منذ بعض الوقت ، نشرنا نحن أنفسنا الإصدار 1.3 من بروتوكول أمان طبقة النقل ، وبعد جمع البيانات وتحليلها ، أصبحنا مستعدين أخيرًا للتحدث عن ميزات هذا الانتقال.يكتب رؤساء مجموعة عمل IETF TLS:
"باختصار ، يجب أن يوفر TLS 1.3 الأساس لإنترنت أكثر أمانًا وفعالية خلال العشرين عامًا القادمة."
استغرق تطوير
TLS 1.3 10 سنوات طويلة. نحن في Qrator Labs ، إلى جانب بقية الصناعة ، نتابع عن كثب عملية إنشاء البروتوكول من المشروع الأولي. خلال هذا الوقت ، كان من الضروري كتابة 28 إصدارًا متتاليًا من المسودة ، بحيث شهد العالم في نهاية عام 2019 بروتوكولًا متوازنًا وسهل النشر. الدعم النشط لـ TLS 1.3 من السوق واضح بالفعل: تنفيذ بروتوكول أمان موثوق وموثوق يفي بمتطلبات العصر.
وفقًا لإريك ريسكورلا (CTO of Firefox والمؤلف الوحيد لـ TLS 1.3)
في مقابلة مع The Register :
وقال "هذا بديل كامل عن TLS 1.2 باستخدام نفس المفاتيح والشهادات ، بحيث يمكن للعميل والخادم الاتصال تلقائيًا عبر TLS 1.3 إذا كان كلاهما يدعمها". "يوجد بالفعل دعم جيد للمكتبات ، ويتضمن Chrome و Firefox TLS 1.3 افتراضيًا."
بالتوازي مع ذلك ، تقوم مجموعة عمل IETF TLS بوضع اللمسات الأخيرة على
إعداد RFC الذي يعلن أن الإصدارات الأقدم من TLS (باستثناء TLS 1.2 فقط) قديمة وغير صالحة للاستخدام. على الأرجح ، سيتم إصدار RFC النهائي قبل نهاية الصيف. هذه إشارة أخرى لصناعة تكنولوجيا المعلومات: لا ينبغي تأجيل تحديث بروتوكولات التشفير.
تتوفر قائمة بالتطبيقات الحالية لـ TLS 1.3 على Github لأي شخص يبحث عن المكتبة الأكثر ملاءمة:
https://github.com/tlswg/tls13-spec/wiki/Implementations . من الواضح أن اعتماد البروتوكول المحدّث ودعمه سيكون - وهو قيد التنفيذ بالفعل - خطوات سريعة. إن فهم كيف أصبح التشفير الأساسي في العالم الحديث قد انتشر على نطاق واسع.
ما الذي تغير مقارنةً بـ TLS 1.2؟
من
مجتمع الإنترنت ملاحظة :
"كيف تجعل TLS 1.3 العالم مكانًا أفضل؟"
يتضمن TLS 1.3 بعض المزايا التقنية - مثل عملية المصافحة المبسطة لإقامة اتصال آمن - كما يتيح للعملاء استئناف الجلسات مع الخوادم بشكل أسرع. تم تصميم هذه التدابير لتقليل تأخير إعداد الاتصال وعدد الاتصالات الفاشلة على القنوات الضعيفة ، والتي غالباً ما تستخدم كذريعة لتوفير اتصالات HTTP غير المشفرة فقط.
بنفس القدر من الأهمية ، يتم إلغاء دعم العديد من خوارزميات التجزئة والتشفير غير الآمنة والتي لا يزال مسموحًا بها (على الرغم من أنه غير مستحسن) لاستخدامه مع الإصدارات السابقة من TLS ، بما في ذلك SHA-1 و MD5 و DES و 3DES و AES-CBC. مع إضافة دعم لأجنحة التشفير الجديدة. تشتمل التحسينات الأخرى على المزيد من عناصر المصافحة المشفرة (على سبيل المثال ، يتم الآن تشفير تبادل معلومات الشهادة) لتقليل مقدار التلميحات إلى أداة اعتراض محتملة لحركة المرور ، بالإضافة إلى تحسينات في السرية الأمامية عند استخدام أوضاع تبادل مفاتيح معينة ، لذلك يجب أن يبقى التواصل في جميع الأوقات "آمن ، حتى لو كانت الخوارزميات المستخدمة في تشفيرها ستتعرض للخطر في المستقبل."
تطوير البروتوكولات الحديثة و DDoS
كما قد تكون قرأت بالفعل ، أثناء تطوير البروتوكول
وحتى بعده ،
ظهرت تناقضات خطيرة في مجموعة عمل IETF TLS. أصبح من الواضح الآن أنه يتعين على المؤسسات الفردية (بما في ذلك المؤسسات المالية) تغيير الطريقة التي تؤمن بها لشبكتها الخاصة من أجل التكيف مع بروتوكول
السرية المتقدمة للأمام والذي تم دمجه الآن في البروتوكول.
تم توضيح أسباب الحاجة إلى ذلك في ورقة
كتبها ستيف فينتر . تشير الورقة المكونة من 20 صفحة إلى العديد من الأمثلة التي قد ترغب فيها مؤسسة ما في فك تشفير حركة المرور خارج النطاق (التي لا تسمح بها PFS) من أجل مراقبة المتطلبات التنظيمية أو الامتثال لها أو توفير الحماية ضد هجمات DDoS على مستوى التطبيق (L7).
على الرغم من أننا لسنا بالتأكيد مستعدين للحديث عن المتطلبات التنظيمية ، فقد تم إنشاء منتجنا الخاص لتحييد هجمات DDoS المطبقة (بما في ذلك الحل الذي
لا يتطلب الكشف عن المعلومات الحساسة و / أو السرية) في عام 2012 مع وضع PFS في الاعتبار ، لذلك لا توجد تغييرات على عملائنا وشركائنا في بعد ترقية الإصدار من جانب الخادم من TLS ، لم تكن البنية التحتية الخاصة بهم مطلوبة.
أيضًا ، منذ وقت التنفيذ ، لم يتم تحديد أي مشاكل مرتبطة بتشفير النقل. رسميا: TLS 1.3 جاهز للاستخدام في الإنتاج.
ومع ذلك ، لا تزال هناك مشكلة مرتبطة بتطوير بروتوكولات الجيل التالي. يتكون ذلك في حقيقة أن التقدم في تطوير البروتوكولات في IETF يعتمد بشكل كبير على نتائج البحث العلمي ، وحالة البحث الأكاديمي في صناعة تحييد هجمات رفض الخدمة الموزعة أمر محزن للغاية.
مثال جيد على ذلك هو
القسم 4.4 من مسودة IETF "الإدارة السريعة" ، والتي تعد جزءًا من مجموعة بروتوكولات QUIC المستقبلية: تنص على أن "الأساليب الحديثة لاكتشاف وتحييد [هجمات DDoS] تتضمن عادةً قياسًا سلبيًا باستخدام البيانات على تدفقات الشبكة. "
هذا الأخير ، في الواقع ، نادر جدًا في بيئات الشركات الحقيقية (وهو قابل للتطبيق جزئيًا على مزودي الإنترنت فقط) ، وعلى أي حال لا يمثل "حالة شائعة" في العالم الواقعي - لكنه يظهر دائمًا في المنشورات العلمية ، وعادة ما لا يدعمه الاختبار مجموعة كاملة من هجمات DDoS المحتملة ، بما في ذلك الهجمات على مستوى التطبيق. الأخيرة ، بحكم النشر العالمي على الأقل لبروتوكول TLS ، من الواضح أنه لا يمكن اكتشافها عن طريق القياس السلبي لحزم الشبكة وتدفقاتها.
وبالمثل ، لا نعرف حتى الآن كيف سيتكيف مصنعو المعدات اللازمة لتحييد DDoS مع واقع TLS 1.3. بسبب التعقيد التقني لدعم بروتوكول خارج النطاق ، قد يستغرق الأمر بعض الوقت للترقية.
يعد تحديد الأهداف الصحيحة للبحث تحديًا كبيرًا لموفري خدمات تحييد DDoS. أحد المجالات التي يمكن أن تبدأ التطوير فيها هو
فريق البحث SMART في IRTF ، حيث يمكن للباحثين العمل مع الصناعة لتحسين معرفتهم بصناعة المشكلات والعثور على اتجاهات بحثية جديدة. نحن على استعداد أيضًا للترحيب بحرارة بجميع الباحثين ، إن وجد ، يمكنك الاتصال بنا لطرح الأسئلة أو الاقتراحات المتعلقة بدراسات DDoS أو مع مجموعة SMART للأبحاث على
العنوان rnd@qrator.net