أكثر من نصف أفضل مليون موقع يتفاوض الآن على تبادل مفاتيح ما بعد الكم، وبالكاد شيء من ذلك من عمل المواقع نفسها؛ فقد فعّلته شبكة توصيل محتوى (CDN). هذا التمييز مهم لكل من يشغّل خوادم، لأن ما لا تستطيع الـ CDN فعله عنك، أي خوادم المنشأ (origin) والخدمات الداخلية والتواقيع، هو حيث بقي العمل. يعرض هذا الدليل الأرقام الحالية والمواعيد النهائية المكتوبة الآن في القوانين والإرشادات وخطة عملية. كل الأرقام من المصادر المرتبطة، وقد قُرئت في 7 نوفمبر 2026.
أين وصل التبني
تفيد F5 Labs بأن 54% من أفضل مليون موقع تدعم الآن تبادل مفاتيح ما بعد الكم، لكن هذا الرقم تقوده شبكات الـ CDN. فإذا أُزيلت النطاقات المستضافة لدى Cloudflare هبط التبني من 54% إلى 22% (F5 Labs، سبتمبر 2026).
قاست دراسة مقبولة في مؤتمر ACM Internet Measurement Conference 2026 أكثر من ملياري مصافحة TLS على مليون نطاق من 11 نقطة قياس على مدى ثلاث جولات بين يوليو 2025 ومارس 2026. ومن بين 684,494 نطاقاً أجابت في كل الجولات، ارتفعت حصة النطاقات التي تتفاوض على تبادل مفاتيح ما بعد الكم افتراضياً من 31.26% إلى 49.22%، وكلها استخدمت المجموعة الهجينة نفسها X25519MLKEM768. تستحوذ Cloudflare وFastly على نحو 70% من النشر، ويقع 93.92% منه خلف بنية تحتية مُدارة ولا يديره مالكوه إلا 4.58% (Communications of the ACM).
| المقياس | القيمة | المصدر |
|---|---|---|
| مواقع أفضل مليون بتبادل مفاتيح ما بعد الكم | 54%، أو 22% دون نطاقات Cloudflare | F5 Labs |
| نطاقات تتفاوض عليه افتراضياً، يوليو 2025 إلى مارس 2026 | 31.26% إلى 49.22% | دراسة IMC 2026 |
| النشر خلف Cloudflare وFastly | نحو 70% | دراسة IMC 2026 |
| حصة النشر الذي يديره المالك | 4.58% | دراسة IMC 2026 |
| خوادم origin لعملاء Cloudflare، أغسطس 2026 | نحو 11%، ارتفاعاً من 6% قبل عام | Cloudflare، نقلاً عن CACM |
| الخدمات الحكومية | 38% | دراسة IMC 2026 |
المواعيد النهائية صارت ثابتة
- الولايات المتحدة: يحدد الأمر التنفيذي 14412 الموقّع في 22 يونيو 2026 تاريخ 31 ديسمبر 2030 لنقل الوكالات الاتحادية أكثر أنظمتها حساسية إلى التشفير ما بعد الكمي، و31 ديسمبر 2031 للمصادقة ما بعد الكمية. كما يوجّه المتعاقدين الاتحاديين إلى الامتثال لمعايير FIPS ما بعد الكمية بنهاية 2030 (ملخص Cloudflare).
- إرشاد NIST لعام 2024: إيقاف RSA والتشفير بالمنحنيات الإهليلجية بحلول 2030 ومنعهما بحلول 2035.
- NSA CNSA 2.0: أن تستخدم المتصفحات والخوادم والخدمات السحابية خوارزميات ما بعد الكم حصراً بحلول 2033. وBSI الألمانية تتوقع ألا تُستخدم التواقيع التقليدية وحدها بنهاية 2035 (CACM).
- الاتحاد الأوروبي: تطلب خريطة طريق مجموعة التعاون NIS في 23 يونيو 2025 من الدول الأعضاء بدء استراتيجيات وطنية للانتقال بنهاية 2026 ونقل الاستخدامات عالية الخطورة بنهاية 2030.
- هدف Cloudflare نفسها: أن تكون ما بعد كمية بالكامل، بما في ذلك المصادقة، بحلول 2029، وقد قُدِّم في أبريل 2026 بعد اختراقات بحثية (مدونة Cloudflare).
توصي Gartner ببناء جرد وبرنامج معالجة لما بعد الكم في 2026، وقوائم مواد تشفير آلية في 2027، وTLS 1.3 بحلول 2028، ونقل كل الأنظمة عالية القيمة إلى التشفير ما بعد الكمي بحلول 2030. وتقدّر أن أقل من 10% من المؤسسات تدعمه اليوم للبيانات عالية القيمة، وتحذّر من أن الفرق التي لم تبدأ التجريب بحلول 2027 قد تدفع 200% أكثر على الأقل مقابل الترحيل الكامل (Network World).
تبادل المفاتيح أولاً ثم التواقيع
الترحيلان مختلفان. يحمي تبادل المفاتيح حركة اليوم من «harvest now, decrypt later»، أي أن يسجّل المهاجم الحركة المشفرة ثم يفك تشفيرها حين يوجد حاسوب كمي. والمجموعة الهجينة X25519MLKEM768 تفعل ذلك وهي افتراضية في المتصفحات وشبكات الـ CDN الكبرى. أما التواقيع والشهادات فتحمي من انتحال الهوية بعد وجود مثل هذا الحاسوب، ومنظومتها أقل جاهزية بكثير: فالتواقيع ما بعد الكمية أكبر من الإهليلجية، وتدرج Cloudflare التواقيع لاتصالات الزائر على أنها «مخطط لها» عبر Merkle Tree Certificates. وتضع جداول الاتحاد الأوروبي والولايات المتحدة وGartner تبادل المفاتيح أولاً للسبب نفسه.
ما الذي عليك فعله
- جرد أماكن استخدام التشفير. اسرد نقاط TLS وشبكات VPN والروابط الداخلية بين الخدمات والشهادات وتوقيع الشيفرة والأجهزة المدمجة. تغطي الـ CDN مقطع الزائر إلى الحافة فقط.
- اختبر نقاطك أنت لا الـ CDN. أضافت OpenSSL 3.5 تبادل ML-KEM الهجين إلى TLS 1.3 وتفضّله افتراضياً (OpenSSL Foundation، وثائق OpenSSL). مع OpenSSL 3.5 أو أحدث، يطبع
openssl s_client -connect host:443 -tls1_3سطراً باسمServer Temp Key: القيمةX25519MLKEM768تعني هجيناً ما بعد كمي، وX25519تعني تقليدياً. - افحص إصدار أدواتك. على خادمنا نفسه، لا يستطيع عميل مبني على OpenSSL 3.0.13 حتى طلب هذه المجموعة: يفشل
openssl s_client -groups X25519MLKEM768برسالة «group cannot be set»، وتفاوض curl المبني عليه على X25519 العادي مع نقطة Cloudflare. أما OpenSSL التوزيعي الأقدم من 3.5 فيبقى تقليدياً بصمت، في العملاء والخوادم. - رقِّ خوادم المنشأ والخدمات الداخلية إلى TLS 1.3 على OpenSSL 3.5 أو أحدث. تقول Cloudflare إن تبني origin ارتفع من 6% إلى نحو 11% في عام، بمساعدة OpenSSL الأحدث في Debian Trixie.
- اطلب مواعيد من الموردين. اجعل دعم ما بعد الكم لتبادل المفاتيح وخريطة طريق للتواقيع جزءاً من تقييم كل منتج أمني.
- خطط لمرونة التشفير. أبقِ اختيار الخوارزمية في الإعدادات لا في الشيفرة حتى لا يحتاج التغيير إلى إعادة كتابة.
كلفة المصافحة صغيرة. ارتفع قياس أداء OpenSSL على فرع التطوير من 13 إلى 15.5 ميلي ثانية بعد أن صار ML-KEM الهجين افتراضياً، وتُدفع هذه الكلفة مرة واحدة لكل اتصال (OpenSSL Foundation). وإن كنت تشغّل خادم بريد أو ويب بنفسك فالمنطق نفسه ينطبق: اطّلع على إبقاء خادم البريد المستضاف ذاتياً موثوقاً لحالة أخرى يتحول فيها افتراض قديم إلى مشكلة بصمت.
الأسئلة الشائعة
هل يستطيع حاسوب كمي كسر TLS اليوم؟ لا توجد آلة معروفة تستطيع. سبب التحرك الآن هو harvest-now-decrypt-later والمواعيد التنظيمية الثابتة 2030 و2031.
ما X25519MLKEM768؟ تبادل مفاتيح هجين يجمع X25519 التقليدي مع ML-KEM-768. على المهاجم كسر الاثنين، فلا ينخفض الأمان عن المستوى التقليدي.
إن استخدمت Cloudflare فهل انتهيت؟ بالنسبة لمقطع الزائر إلى الحافة، في الغالب نعم. أما خادم المنشأ والحركة الداخلية والتواقيع فمنفصلة، ونحو 11% فقط من خوادم origin خلف Cloudflare تستخدمه.
هل أحتاج شهادات ما بعد كمية الآن؟ ليس بعد لمعظم الفرق. قدّم تبادل المفاتيح ووثّق خطة التواقيع.
