Cloudflare تطلق أدوات جديدة لرؤية التشفير ما بعد الكمي

أعلنت Cloudflare في 29 سبتمبر عن أدوات جديدة لرؤية التشفير ما بعد الكمي. ويمكن للمستخدمين الآن رؤية انتشار تشفير TLS 1.3 ما بعد الكمي لحركة المرور الحية في Logpush وLog Explorer ولوحة HTTP Traffic Analytics.

تعرض المنصة لكل طلب وارد خوارزمية تبادل المفاتيح المتفق عليها. على مستوى النطاق، هذه قدرة جديدة: حتى الآن كانت Cloudflare تكشف فقط عن إصدار TLS وليس عن الخوارزميات التشفيرية المستخدمة معه، لذلك لم تكن توجد إجابة حسب النطاق عن السؤال: ما نسبة حركة المرور المحمية بالتشفير ما بعد الكمي؟

لماذا هذا مطلوب الآن

تخطط Cloudflare لتحقيق أمن ما بعد كمي كامل بحلول 2029، بينما يقترب بعض عملائها من مواعيد الجاهزية الكمومية بحلول 2030. وفق بيانات Radar، نحو 70% من حركة المرور القادمة من المتصفحات محمية بالفعل بخوارزمية ML-KEM الهجينة، في حين أن نحو 15% فقط من الخوادم الأصلية المتصلة بـ Cloudflare تستخدمها.

التشفير ما بعد الكمي ضروري لتجنب ما يسمى هجوم harvest-now-decrypt-later: يجمع المهاجم البيانات اليوم ليفك تشفيرها لاحقًا عند ظهور حاسوب كمومي قوي. ووفق توصية NIST لعام 2024، يجب استبدال RSA وتشفير المنحنيات الإهليلجية بحلول 2030.

ماذا تعرض البطاقة الجديدة

في TLS 1.3، الخوارزمية الوحيدة الموصى بها للتشفير ما بعد الكمي هي X25519MLKEM768، وتختارها غالبية المتصفحات. يجمع النهج الهجين بين ECDHE القائم على منحنى X25519 و ML-KEM ما بعد الكمي، لذلك يبقى الاتصال محميًا ما دام أحدها موثوقًا.

أضيفت إلى لوحة HTTP Traffic Analytics بطاقة منفصلة TLS Key Exchange، تقسم حركة المرور حسب مجموعات تبادل المفاتيح. على النطاق التجريبي للشركة، تستخدم غالبية حركة المرور X25519MLKEM768، ويستخدم جزء منها ECDHE الكلاسيكي على منحنى X25519 أو P-256، بينما تشمل فئة „None“ تبادل المفاتيح القائم على RSA أو اتصالًا بدون TLS إطلاقًا.

السجلات والخوادم الأصلية

أضيف إلى Logpush حقل ClientTLSKeyExchangeGroup، الذي يعرض الخوارزمية المتفق عليها أيضًا في سجلات فردية. ويغطي OriginTLSKeyExchangeGroup الاتصال من Cloudflare إلى الخادم الأصلي. إذا كان الخادم الأصلي قديمًا ولا يدعم التشفير ما بعد الكمي، فيكفي وضعه خلف Cloudflare Tunnel: تنتقل حركة المرور عبر النفق باستخدام TLS 1.3 و X25519MLKEM768، دون تحديث الخادم نفسه.

تعمل الشركة أيضًا على المصادقة ما بعد الكمية: يمكن للخوادم الأصلية بالفعل الاتصال بشهادات ML-DSA-44، بينما قدمت Cloudflare مركز شهادات يدعم Merkle Tree Certificates. حاليًا، التشفير أكثر انتشارًا من المصادقة. إذا لم يظهر X25519MLKEM768 إطلاقًا في حركة مرور النطاق، فالسبب على الأرجح هو تعطيل TLS 1.3: لا يوجد معامل ما بعد كمي منفصل، وتتفاوض Cloudflare تلقائيًا على الخوارزمية الهجينة.