أعلنت Cloudflare توسيع خدمة Automatic SSL/TLS بميزة Automatic Key Exchange، التي تتعلم قدرات خوادم الأصل لدى العملاء قبل الاتصالات الفعلية، ثم تختار خوارزمية تبادل المفاتيح المناسبة من أول محاولة. وتفضّل الميزة الخوارزمية الهجينة المقاومة للحوسبة الكمّية X25519MLKEM768 عندما يكون خادم الأصل والمسار الشبكي قادرين على استخدامها.
تستهدف الميزة الاتصال الثاني الذي ينشئه Cloudflare بين بنيتها التحتية وخادم الأصل، وليس اتصال المستخدم بالمنصة. وبما أن TLS 1.3 يفرض على العميل إرسال خوارزمية تبادل مفاتيح في أول رسالة، كان على Cloudflare استخدام تخمين ثابت هو X25519. وإذا كان الخادم يفضّل خوارزمية أخرى، يرسل HelloRetryRequest فتبدأ المصافحة من جديد، ما يضيف دورة كاملة من زمن الشبكة.
من التخمين إلى القياس
تجري Cloudflare سلسلة من مصافحات TLS الخفيفة خارج مسار حركة الإنتاج، بحيث تعرض في كل اختبار خوارزمية واحدة من X25519 أو P-256 أو P-384 أو P-521 أو X25519MLKEM768. وتستخدم النتائج لتحديد ما يدعمه كل أصل، مع تقييم النطاقات الفرعية بصورة مستقلة وترجيح النتائج وفق حجم حركة المرور الفعلي لكل منها.
بعد ذلك تختار المنصة أعلى خيار متاح وفق ترتيب يبدأ بالخوارزمية الهجينة ما بعد الكمّية، ثم يعود إلى الخوارزمية الكلاسيكية الأسرع التي يقبلها الأصل. وتطرح Cloudflare التغيير تدريجياً على جزء صغير من حركة الأصل، وتراقب معدل الفشل وطلبات HelloRetryRequest، ثم تتراجع عن الإعداد إذا تجاوز الأداء خط الأساس. كما تعيد فحص الأصول يومياً لمواكبة تغييرات موازنات التحميل أو مكتبات TLS أو إعدادات الخوادم.
الأثر المعلن على الأداء والأمان
تقول Cloudflare إن معدل طلبات HelloRetryRequest في الأصول التي شملها القياس انخفض من نحو 52% إلى 3.7%، مع خفض يتجاوز 150 ميلي ثانية في زمن المصافحة عند المئين التسعين. ويظهر الأثر خصوصاً في الطلبات التي تحتاج إلى اتصال جديد مع الأصل، مثل الطلبات الديناميكية أو حالات غياب المحتوى من ذاكرة CDN؛ أما الاتصالات القائمة عبر keep-alive فلا تحتاج إلى مصافحة جديدة.
وبحسب الشركة، أصبحت 99.2% من اتصالات TLS 1.3 ما بعد الكمّية في المجموعة المفحوصة تكتمل في دورة واحدة. كما ارتفع حجم حركة الأصول ذات تبادل المفاتيح ما بعد الكمّي من نحو 25 مليار اتصال إلى 45 مليار اتصال يومياً، فيما حصلت مئات الآلاف من النطاقات على هذه الحماية دون تدخل يدوي. وتذكر Cloudflare أن 33% من أكثر من مليون نطاق في الدفعة الأولية اختيرت لها X25519MLKEM768، بينما بقي 64% على X25519 واستخدمت 3% خوارزميات كلاسيكية أخرى.
ما الذي يتغير عملياً للعملاء؟
الميزة مفعّلة افتراضياً للنطاقات الجديدة والقائمة التي تستخدم أصولاً تدعم TLS 1.3، ويمكن التحكم بها من لوحة Cloudflare ضمن SSL/TLS ثم Origin connection & post-quantum encryption. وإذا لم يدعم الأصل X25519MLKEM768، فلن تضيف الميزة هذه القدرة من تلقاء نفسها، لكنها تستطيع اختيار خوارزمية كلاسيكية متوافقة وتجنب إعادة المصافحة غير الضرورية.
تتيح Cloudflare أيضاً إعدادين للامتثال: قصر التفاوض على التبادل الهجين ما بعد الكمّي، أو قصره على الخوارزميات المتوافقة مع FIPS. لكن تفعيل التبادل ما بعد الكمّي على أصل لا يدعمه قد يؤدي إلى فشل جميع اتصالات TLS 1.3، لذلك تحذر الشركة من استخدام هذا الخيار دون تحقق مسبق. وتوفر Cloudflare Radar فحصاً لقدرة الخادم والمسار الشبكي على التعامل مع هذه الاتصالات، بما في ذلك مشكلات جدران الحماية والأنظمة الوسيطة والرسائل المجزأة.
لماذا يهم هذا الإعلان؟
التغيير يجمع بين تحسين أداء مباشر ومحاولة لتوسيع تبني التشفير ما بعد الكمّي دون مطالبة مشغلي المواقع بتحديد الخوارزمية يدوياً. لكنه لا يحل محل ترقية خادم الأصل أو موازن التحميل؛ فالمنصة لا تستطيع التفاوض على خوارزمية غير مدعومة. كما أن تبادل المفاتيح ما بعد الكمّي يحمي من سيناريو تسجيل البيانات المشفرة وفكها لاحقاً، لكنه لا يعالج وحده انتحال هوية الأصل أو مخاطر خفض مستوى المصادقة. وتقول Cloudflare إن الخطوات التالية تشمل فحص دعم شهادات ML-DSA ومنع العودة إلى الشهادات الكلاسيكية عند توافر حماية ما بعد كمّية صارمة.
كيف أعددنا هذا الخبر؟
اعتمد الخبر على المصدر الأصلي الموضح أعلاه. قد نستخدم أدوات آلية للمساعدة في الاستخراج والتصنيف والصياغة،
لكن النشر يخضع لقواعد تمنع المحتوى المكرر والقصير أو الروتيني منخفض القيمة.
اقرأ سياستنا التحريرية.