اختراق مفاتيح CA في eMudhra بيوضح ليه أمان الدومين محتاج أكتر من HTTPS

الموقع ممكن يشفّر اتصال مع جهة منتحلة. التشفير لوحده ما بيحددش مين بيتحكم في الطرف التاني من الاتصال.

حادثة eMudhra بتخلي التفرقة دي ضرورية لأصحاب الدومينات والمؤسسين وفرق Web3. يوم 20 أكتوبر 2026، أعلنت Google وMozilla إجراءات طوارئ بعد اختراق مفاتيح جهات إصدار شهادات وسيطة. ضعف توليد المفاتيح فتح طريق لتزوير شهادات المواقع. البرامج العميلة اللي فضلت واثقة في المفاتيح دي واجهت خطر انتحال الهوية. Google بتشرح الخلل وإجراءات الحظر.

راجعنا الحالة يوم 22 أكتوبر 2026. التحقيق لسه مستمر. تأكيد اختراق المفاتيح ما يثبتش إن مهاجمين اعترضوا حركة بيانات العملاء.

الحادثة كشفت خطر صلاحية توقيع أعلى من شهادات المواقع الفردية

جهة إصدار الشهادات، أو CA، بتصدر شهادات رقمية بتربط الهويات بمفاتيح عامة. في HTTPS، الشهادة بتحدد أسماء الدومينات اللي الخادم يقدر يثبت هويته باسمها. جهة إصدار الشهادات بتراجع متطلبات إثبات الهوية المطلوبة قبل توقيع الشهادة. المتصفح بيراجع سلسلة الشهادات وإثبات الخادم لحيازة المفتاح الخاص المقابل. RFC 5280 بيشرح نموذج الشهادات.

جهة إصدار الشهادات الجذرية بتوفر مرجع ثقة. جهة إصدار شهادات وسيطة معاها صلاحية توقيع مفوّضة تحت الجذر. شهادات المواقع غالبًا بتكون تحت جهة إصدار شهادات وسيطة. اختراق مفتاح موقع بيهدد الهويات الموجودة في شهادة الموقع. اختراق مفتاح وسيط ممكن يهدد دومينات كتير مالهاش علاقة ببعض، حسب قيود الشهادة وفحوصات البرنامج العميل.

سجل الحادثة عند Mozilla بيحدد تمان شهادات وسيطة متأثرة: ستة لشهادات TLS واتنين لتوقيع البرامج. Mozilla استرجعت المفاتيح الخاصة الضعيفة بشكل مستقل. eMudhra علّمت الشهادات كملغاة يوم 18 أكتوبر. الوقائع دي بتوصف خلل في توليد المفاتيح، ومش دليل إن حد سرق المفتاح الخاص لكل عميل.

في بيان يوم 21 أكتوبر، نسبت eMudhra ضعف المفاتيح لخطوة تغليف وفك تغليف أثناء مراسم توليد المفاتيح يوم 30 أبريل 2025. eMudhra قالت إن الجهات الوسيطة المتأثرة ما أصدرتش أي شهادات لكيانات نهائية، وإن الشركة ما لقتش دليل على استغلال قبل الإعلان. الشركة قالت كمان إن التحقيق لتحديد السبب الجذري بدقة لسه ما اكتملش. التصريحات دي بتوصف نتائج eMudhra، ومش ضمان مستقل بخصوص كل حركة البيانات السابقة.

حماية المتصفحات غيّرت نطاق التعرض الفعلي

Google بتقول إن Chrome حظر المفاتيح المتأثرة يوم 17 أكتوبر من خلال تحديث CRLSet. Google بتقول كمان إن ما ظهرش في CT أي شهادات TLS تحت الجهات الوسيطة الستة المتأثرة الخاصة بـTLS قبل الحظر. بالتالي، الشهادات المزورة الصادرة من الجهات الوسيطة دي ما كانش ممكن تشتغل مع البرامج العميلة اللي بتفرض شرط CT المعني. تنبيه Google بيشمل Chrome ضمن البرامج دي.

Mozilla وزعت حظر OneCRL مساء نفس اليوم. Mozilla أصدرت كمان تحديثات Firefox للإعدادات اللي ممكن ما توصلهاش حماية OneCRL. تحديث متصفح ما يثبتش إن كل تطبيق على نفس الجهاز عنده نفس الحماية. Cloudflare بتحذر تحديدًا إن التطبيقات المختلفة ممكن تستخدم أدوات مختلفة للتحقق من الشهادات.

تنبيه Google الصادر يوم 20 أكتوبر بيحدد إزالة emSign ECC Root CA - G3 من البرامج اللي بتستخدم Chrome Root Store يوم 27 أكتوبر 2026 بتوقيت PDT. Google بتطلب من مشغلي المواقع المتأثرة ينقلوا الشهادات لتسلسل شهادات موثوق تاني. المشغلين لازم يفرقوا بين الحظر الأمني الفوري وبين انقطاع خدمة لاحق بسبب سحب الثقة من الجذر.

مهاجم الوسيط محتاج يوصل لحركة البيانات ويقدم هوية مقبولة

هجوم الوسيط، أو MITM، بيحط المهاجم بين طرفين بيتواصلوا. المثال الجاي هجوم افتراضي، ومش استغلال مرصود لحادثة eMudhra:

1. المهاجم بيعيد توجيه زائر باستخدام إجابات DNS خبيثة أو وسيلة تانية لاعتراض الشبكة.
2. المهاجم بيقدم شهادة مزورة للدومين المقصود.
3. برنامج عميل من غير الحماية المطلوبة بيقبل الشهادة وبيفتح اتصال TLS مع المهاجم.
4. المهاجم يقدر يمرر حركة البيانات للخدمة الحقيقية، وفي نفس الوقت يقرأ بيانات التطبيق أو يغيّرها.

حيازة مفتاح CA ما بتعيدش توجيه حركة البيانات تلقائيًا. الشهادة لوحدها كمان ما بتفكش تشفير كل الجلسات اللي اتسجلت قبل كده. خاصية السرية الأمامية في TLS 1.3 بتحمي الجلسات السابقة من اختراق مفاتيح المصادقة طويلة الأجل لاحقًا، في حدود الافتراضات المحددة في البروتوكول. RFC 8446 بيشرح الفرق.

دراسة حالة Fox-IT عندنا بتفحص طريق مختلف لنتيجة مشابهة: اختراق شركة تسجيل الدومين سمح بالحصول على شهادة احتيالية. دراسة حالة MyEtherWallet عندنا بتفحص التلاعب بالتوجيه وDNS. أمان الدومين لازم يعالج اتجاه حركة البيانات ومصادقة طرف الاتصال مع بعض.

DNSSEC بيثبت صحة إجابات DNS من غير ما يصلّح مفاتيح CA

DNSSEC (امتدادات أمان نظام أسماء النطاقات) بيضيف توقيعات رقمية لبيانات DNS. محلل أسماء بيجري التحقق بيراجع التوقيعات من خلال سلسلة ثقة. مع منطقة موقعة بشكل صحيح وسلسلة تحقق سليمة، المهاجم ما يقدرش يستبدل إجابة عنوان بإجابة مزورة من غير اكتشاف التزوير. RFC 4033 بيحدد الحماية وحدودها.

البرنامج العميل لازم يتحقق محليًا، أو يثق في محلل الأسماء اللي بيجري التحقق وفي اتصال مُوثَّق الهوية بمحلل الأسماء ده. RFC 4033 بيشرح شرط آخر جزء من مسار الاتصال.

مع استيفاء الشروط دي، DNSSEC يقدر يمنع خطوة تزوير DNS في الهجوم الافتراضي. DNSSEC ما بيلغيش جهة إصدار شهادات وسيطة، وما بيتحققش من شهادة HTTPS، وما بيشفرش حركة الويب. المهاجم اللي بيعترض حركة البيانات من طريق تاني لسه يقدر يقدم شهادة مزورة لبرنامج عميل معرض للخطر.

التوقيع لوحده كمان ما بيحميش حساب شركة تسجيل الدومين أو لوحة تحكم DNS الموثوق. المهاجم اللي بيتحكم في تغييرات DNS المصرح بيها يقدر ينشر سجلات ضارة ومقدم الخدمة يوقّع السجلات. المشغلين محتاجين حماية الحسابات ومراقبة التغييرات وسجل DS صحيح في المنطقة الأم، جنب التحقق باستخدام DNSSEC.

DANE يقدر يربط مفتاح الخدمة ببيانات DNS موقعة لما البرنامج العميل يفرض الربط

DANE بيربط DNSSEC بمصادقة TLS من خلال سجلات TLSA. مشغل الدومين بينشر الشهادة المتوقعة أو المفتاح المتوقع أو مرجع الثقة في DNS موقّع. البرنامج العميل الداعم بيتحقق من DNSSEC وبيفرض ارتباط TLSA. RFC 6698 بيحدد الارتباط.

مثلًا، نمط DANE-EE يقدر يربط الخدمة مباشرة بمفتاحها العام. الشهادة المزورة بمفتاح CA مالوش علاقة بالخدمة مش هتطابق الربط. الفايدة دي محتاجة تحقق آمن من DNSSEC وبيانات TLSA صحيحة وفرض فعلي من البرنامج العميل. تغيير المفاتيح محتاج كمان تنسيق تحديثات TLSA. RFC 7671 بيقدم إرشادات التشغيل.

نشر سجلات TLSA ما بيحميش زوار المتصفحات العادية تلقائيًا. طلب إضافة DANE إلى Firefox لسه مرفوض. المشغلين لازم يتأكدوا إن البرنامج العميل المحدد بيدعم DANE. DANE ليه تطبيق موحّد في أمان نقل SMTP.

CAA وCT بيوفروا وسائل مختلفة للتحكم في الشهادات

CAA بينشر جهات الإصدار المصرح لها في DNS. RFC 8659 بيفرق بين التصريح بالإصدار وبين تحقق البرنامج العميل من الشهادة. مفتاح توقيع مسروق أو ممكن استرجاعه بيسمح للمزوّر يتجاهل فحوصات CAA.

شفافية الشهادات، أو CT، بتخلي إصدار الشهادات متاح للمراجعة العامة. المراقبة ممكن تنبّه لشهادات غير متوقعة، وفرض القواعد في البرنامج العميل ممكن يرفض شهادات من غير إثبات التسجيل المطلوب. RFC 9162 بيشرح آلية التسجيل. نتائج Google المذكورة بتوضح ليه فرض القواعد مهم وقت حادثة تخص جهة إصدار شهادات.

مشغلو الدومينات محتاجين يراجعوا ثقة البرامج العميلة واعتماد الخدمات على الشهادات دلوقتي

• ثبّت آخر تحديثات الأمان للمتصفح ونظام التشغيل وبيئة التشغيل وحزم CA.
• احصر سلاسل شهادات المواقع وواجهات API وتطبيقات الموبايل والحاويات وبوابات فحص TLS.
• اتبع إرشادات الموردين للجهات الوسيطة المتأثرة وإزالة الجذر، بما فيها مسارات الشهادات البديلة.
• استبدل الشهادات اللي سلسلتها بتنتهي بالتسلسل المسحوبة منه الثقة قبل موعد البرنامج العميل المعني.
• اختبر أداة التحقق الفعلية من TLS في كل تطبيق بعد المعالجة.
• حافظ على تفعيل التحقق من الشهادات، وتوقف عند ظهور أخطاء الشهادات.
• فعّل DNSSEC مع تفويض DS صحيح، واستخدم تحليل أسماء بيجري التحقق.
• قيّد جهات الإصدار المصرح لها باستخدام CAA، وراقب CT، واحمِ حسابات تسجيل الدومين وDNS.

VPN يقدر يغيّر مسار حركة البيانات. VPN ما بيصلّحش قرارات ثقة البرنامج العميل في الشهادات. HSTS بيفرض HTTPS، لكن قبول هوية HTTPS مزورة لسه بيتجاوز الحماية دي. RFC 6797 بيشرح حدود أمان HSTS.

بالنسبة لقارئ Namefi، ملكية الدومين وإدارة DNS ومصادقة TLS والتفويض في المحفظة محتاجين وسائل تحكم منفصلة. تحويل الدومين لرمز ما بيستبدلش ثقة المتصفح في CA تلقائيًا وما بيفعّلش DNSSEC. دليل DNS للدومينات المحولة لرموز عندنا بيشرح العلاقة التشغيلية. دراسة حالة Curve Finance عندنا بتوضح ليه فريق Web3 لازم يحمي الدومين اللي بيقدم واجهة الخدمة.

المصادر الأولية دي بتوثّق الحادثة ووسائل الدفاع

راجعنا كل المصادر الجاية يوم 22 أكتوبر 2026. بيانات الحادثة ممكن تتغير مع استمرار التحقيقات.

• Google: استجابة Chrome وAndroid، 20 أكتوبر 2026. أقسام العشوائية وCT والحظر وإزالة الجذر.
• Mozilla: استجابة Firefox، 20 أكتوبر 2026. توزيع OneCRL والتحديثات الإضافية.
• بلاغ Mozilla رقم 2083449، الوصف والتعليق 1. نطاق الشهادات واسترجاع المفاتيح بشكل مستقل والإلغاء.
• بيان eMudhra عن الحادثة، التحديثات 2–4. نتائج الشركة وخيارات انتقال العملاء.
• إرشادات Cloudflare للحادثة، إرشادات التحقق الخاصة بكل تطبيق.
• RFC 5280، نموذج الشهادات ومسار الثقة.
• RFC 8446، السرية الأمامية في TLS 1.3.
• RFC 4033، خدمات DNSSEC وحدوده والتحقق.
• RFC 6698 وRFC 7671، ارتباطات DANE وتشغيلها.
• بلاغ Mozilla رقم 1994924، حالة إضافة DANE إلى Firefox.
• RFC 7672، DANE لنقل SMTP.
• RFC 8659، الفرق بين تفويض CAA والتحقق.
• RFC 9162، تسجيل CT ومراقبته.
• RFC 6797، اعتبارات أمان HSTS.