كان المفتاح 4: من يقرّر المواقع التي تثق بها برامجك

تُرجمت هذه المقالة آليًا. النسخة الأصلية متاحة باللغة الإنجليزية.

آخر تحديث: 25 أكتوبر 2026 · 17 دقيقة قراءة

لدينا مشكلة هنا

يوم السبت 17 أكتوبر 2026، عند الساعة 18:05 بتوقيت UTC، تلقّى برنامج شهادات الجذر في Chrome (Chrome Root Program) بلاغًا من باحث أمني لم يُعرَّف علنًا إلا باسم واين. ادّعى أنه يملك المفاتيح الخاصة لثماني سلطات تصديق تديرها eMudhra، وهي شركة مدرجة في البورصة مقرّها بنغالور في الهند. وليُثبت ذلك، استخدم كل مفتاح من المفاتيح الثمانية لتوقيع الرسالة القصيرة نفسها: «لدينا مشكلة هنا – واين».

لم يكن مضطرًا إلى اختراق أي شيء. وبعد أن انتشر الخبر، وصف الباحث الأمني سكوت هيلم ما كانت عليه هذه المفاتيح. كان أحدها ببساطة الرقم 4. وكان اثنان آخران 56 و115. وقال هيلم إنه استخرجها جميعًا من شهاداتها العلنية على حاسوبه المحمول، وإن ذلك استغرق أقل من ثانية. وأكّد تحقّق مستقل أجراه صحفيون أن المفتاح الخاص لسلطة eMudhra المسمّاة «EM OV TLS CA – G3C» هو 4.

كانت السلطات الثماني سلطاتِ تصديق وسيطة، أي الطبقة العاملة في شركة الشهادات، التي توقّع وثائق الاعتماد لصالح الآخرين. ستٌّ منها كانت مخوّلة بإصدار شهادات للمواقع الإلكترونية، وكانت هذه الست موثوقة لدى برامج شهادات الجذر في Chrome وMozilla ومايكروسوفت وآبل. أما الاثنتان الأخريان فكانتا مخصّصتين لتوقيع الشيفرات البرمجية، أي الشهادات التي يستخدمها صانعو البرمجيات لتوقيع برامجهم، وكانت مايكروسوفت تثق بهما. وقد وُلِّدت مفاتيحها على نحو خاطئ، فصار بوسع أي شخص يعرف أين يبحث أن يحسبها من الشهادات نفسها، وهي علنية بحكم تصميمها. وكان ذلك ممكنًا منذ إنشاء الشهادات في أبريل 2025.

عند الساعة 19:45 بتوقيت UTC، أي بعد ساعة وأربعين دقيقة من وصول البلاغ، كان Chrome قد تأكّد من صحة النتائج وأرسل إلى مستخدميه أمر حظر. لم يكن على أحد أن يثبّت تحديثًا أو يعيد تشغيل المتصفح.

كانت السرعة مهمة بسبب ما يستطيع مفتاح كهذا أن يفعله. فمن يملك أيًّا من مفاتيح المواقع الستة ويستطيع اعتراض اتصال شخص ما، كان بوسعه أن يقدّم شهادة مزوّرة لمصرف أو لخدمة بريد إلكتروني أو لأي موقع آخر، أيًّا كانت شركة الشهادات التي يتعامل معها الموقع الحقيقي، وكانت البرمجيات التي تثق بسلسلة eMudhra ستقبلها. ووقف في الطريق حاجزان رئيسيان: نظام تسجيل علني يُدعى Certificate Transparency، تشترطه بعض البرمجيات ولا يشترطه كثير منها، وما وصل إلى كل برنامج من أوامر حظر في الوقت المناسب.

كان نجاح شهادة مزوّرة أو فشلها مرهونًا بقرارات تبقى عادةً غير مرئية: من يكفل موقعًا إلكترونيًا، ومن يقرّر أن الكفيل جدير بالتصديق، وبأي سرعة يمكن سحب هذا التصديق حين يتبيّن أن الكفيل نفسه معطوب.

ما الذي تكفله الشهادة

شهادة الموقع الإلكتروني وثيقة صغيرة موقّعة تربط اسمًا، كعنوان موقع مصرف على الويب، بمفتاح عام. والمفاتيح العامة تأتي أزواجًا مع مفاتيح خاصة. يبقى المفتاح الخاص سرّيًا ويُنتج التواقيع الرقمية، أما المفتاح العام فيتيح لأي شخص التحقق من أن التوقيع صادر عن شريكه. وحين يتصل متصفحك بموقع ما، يُثبت الموقع أنه يملك المفتاح الخاص المطابق للمفتاح العام الوارد في شهادته. والشهادة نفسها تقول إن هذا المفتاح العام يعود إلى هذا الاسم، وتقف وراء هذا القول سلطة تصديق، أو ما يُعرف اختصارًا بـCA، بتوقيعها عليه.

قبل أن توقّع سلطة التصديق شهادة موقع، عليها أن تتحقق من أن مقدّم الطلب يتحكم في النطاق. ومن الطرق المعتمدة لذلك أن تعطي مقدّم الطلب قيمة عشوائية ثم تبحث عنها في سجلات DNS الخاصة بالنطاق، وهي دفتر العناوين العام للإنترنت، حيث لا يستطيع وضعها إلا من يتحكم في النطاق. ويجوز لسلطة التصديق أيضًا أن تتأكد من أن مقدّم الطلب يملك فعلًا المفتاح الخاص الذي يريد اعتماده، عبر اختبار تقني يُسمّى إثبات الحيازة، وإن كان المعيار الذي تقوم عليه الشهادات يسمح لها كذلك بالاكتفاء بكلمة مقدّم الطلب.

لا يستطيع أي متصفح أن يتحقق بنفسه من كل سلطات التصديق في العالم، ولذلك تُفوَّض الثقة عبر سلسلة. في القمة تقع شهادات الجذر، المحفوظة في قائمة تُسمّى مخزن الثقة تأتي مدمجة في نظام تشغيلك أو متصفحك. وتخوّل شهاداتُ الجذر سلطاتِ تصديق وسيطة، وتُصدر السلطات الوسيطة الشهادات التي تستخدمها المواقع. وحين يرى برنامجك شهادة موقع ما، يتتبّع التواقيع صعودًا، من الموقع إلى شهادة وسيطة ثم إلى شهادة جذر، ولا يقبل الموقع إلا إذا انتهت السلسلة عند جذر موجود في مخزنه، وصحّ كل توقيع فيها، وكانت الشهادة سارية وتغطي الاسم الذي تجري زيارته، ولم تمنعها أيٌّ من قواعد البرنامج الأخرى.

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

لا شيء من هذا يخبرك إن كان الموقع نزيهًا، وإن كان كثيرون يفهمون أيقونة القفل في المتصفح على أنها تخبرهم بذلك. حين درست غوغل المسألة عام 2021، لم يفهم معنى القفل فهمًا صحيحًا سوى 11 في المئة من المشاركين، وكانت مواقع التصيد الاحتيالي كلها تقريبًا تستخدم HTTPS، فتعرض القفل هي الأخرى. وفي عام 2023 أعلنت غوغل أن Chrome سيضع أيقونة مختلفة مكان القفل. الشهادة الأساسية لا تقول سوى أن الاتصال يذهب إلى من يملك المفتاح الخاص بذلك الاسم. بعض الشهادات تذكر أيضًا المؤسسة التي تقف وراء الموقع، لكن أيًّا منها لا يكفل نواياها.

وثمة طبقة أخرى. فنظام Certificate Transparency، الذي وضع مهندسون في غوغل أسسه عام 2013، يُدرج الشهادات في سجلات علنية يستطيع فيها أي شخص أن يدقّق ما أصدرته كل سلطة تصديق. وقد أراد مصمّموه أن ترفض البرامج العميلة في نهاية المطاف أي شهادة لم تُسجَّل، بحيث تُرفض كل شهادة أُبقيت خارج السجلات، سواء أصدرتها سلطة تصديق أم لصٌّ يحمل مفتاح سلطة تصديق. ويفعل Chrome ذلك افتراضيًا مع كل اتصال يعتمد على مخزن الجذور الخاص به.

التحذير الذي لم يلقَ جوابًا

قواعد توليد مفاتيح سلطات التصديق صارمة. ففي ما يخص مفاتيح الجذر وبعض مفاتيح السلطات الوسيطة، تنص وثيقة Baseline Requirements، وهي كتاب القواعد الذي تتولى برامج شهادات الجذر في المتصفحات وسلطات التصديق صيانته معًا، على أن تتبع سلطة التصديق نصًّا إجرائيًا مكتوبًا لتوليد المفاتيح، وأن يشهد مدقّق مؤهّل مراسم التوليد أو أن تُسجَّل كاملة بالفيديو. ويجب أن يولّد أيَّ مفتاح لسلطة تصديق عدةُ أشخاص معًا، لا يملك أيٌّ منهم كل المعرفة اللازمة لإنجاز ذلك وحده.

في 30 أبريل 2025 أنشأت eMudhra دفعة من 24 شهادة وسيطة. جاءت في ثلاث مجموعات، تحمل التسميات A وB وC، بنوعين من المفاتيح، RSA والنوع القائم على المنحنيات الإهليلجية المسمّى P-384، ولأربعة أغراض. وكانت المفاتيح الثمانية المعطوبة هي كل مفاتيح P-384 في المجموعتين B وC. وكانت الثمانية كلها أعدادًا صحيحة أصغر من 256. ولو كُتب كل منها كاملًا، لكان صفًّا طويلًا من الأصفار يحمل شيئًا ما في البايت الأخير.

لماذا أمكن تخمين هذا المفتاح

المفتاح الخاص على المنحنى P-384 ليس سوى عدد، يُختار عشوائيًا بين 1 وحدٍّ ثابت يبلغ طوله هو نفسه 384 بتًا. ويُحسب المفتاح العام من المفتاح الخاص بعملية حسابية يسهل إجراؤها في الاتجاه الأمامي، ولا أمل في عكسها حين يكون العدد عشوائيًا كما ينبغي. والمفتاح العام مطبوع في الشهادة. الرقم 4 مفتاح خاص مشروع تمامًا، لكنه أيضًا من أوائل الأرقام التي قد يجرّبها أي شخص. وقد أشارت Mozilla إلى أن مفاتيح بهذا الصغر يمكن استعادتها على الفور تقريبًا: احسب المفاتيح العامة للأعداد 1 و2 و3 وهكذا حتى 256، وقارن كلًّا منها بالمفتاح الوارد في الشهادة. وحين يتطابق اثنان، يكون المفتاح الخاص هو العدد الذي بدأت منه. أما المفتاح العشوائي كما ينبغي فلا يتيح قائمة قصيرة كهذه. وكما قال سكوت هيلم، يضم هذا النطاق قرابة 10 مرفوعة إلى القوة 115 من الاحتمالات، «لذا لن يبحث أحد في ذلك أبدًا». وقد أوكل دينيس جاكسون من Mozilla المهمة أيضًا إلى وكلاء ذكاء اصطناعي يعملون محليًا. فاستعادوا المفتاح من محاولتهم الأولى، انطلاقًا من أمر نصي بسيط.

كيف أنتجت مراسم توليد المفاتيح أعدادًا بهذا الصغر؟ تقول eMudhra في تفسيرها الأولي، المنشور في 19 أكتوبر، إن النص الإجرائي الذي استخدمته ذلك اليوم كان فيه خلل. وتقول إنها وافقت على تعديل لمرة واحدة في الإجراء المعتاد لاختبار تصدير المفاتيح، وإن خطأً برمجيًا جعل العتاد يُنشئ زوجًا ثانيًا أضعف من المفاتيح إلى جانب الزوج السليم، وإن المفاتيح الضعيفة استُخدمت بعد ذلك خطأً لطلب الشهادات لأن تسمياتها بدت متشابهة. وتقول إن المفاتيح وُلِّدت في وحدات أمان أجهزة من صنع Utimaco، وهي أجهزة مقاومة للعبث يُفترض أن تُنتج مفاتيح سلطات التصديق وتحرسها.

تصف eMudhra روايتها بأنها أولية، وهي تترك اللغز الأساسي بلا حل. فقد لاحظ أحد المعلّقين على تذكرة الخلل العلنية لدى Mozilla أن الأمر لا يخرج عن احتمالين: إما أن المفاتيح صُنعت خارج العتاد الآمن ثم حُمِّلت فيه، خلافًا للسياسة، وإما أن العتاد يمكن ضبطه بطريقة ما ليصنع هو نفسه مفاتيح معيبة. واقترح مشارك آخر، على القائمة البريدية العلنية لـMozilla، ومن دون تأكيد، أن برنامجًا ما خلط بين ملف صغير يشير إلى المفتاح الحقيقي داخل العتاد وبين المفتاح نفسه. أما Mozilla، فلم تتمكن، رغم أنها حاولت بجهد أكبر بكثير، من استعادة مفاتيح P-384 في المجموعة A من الدفعة نفسها. وأرسلت إلى eMudhra أسئلة في 20 أكتوبر مع مهلة 24 ساعة، وحتى 23 أكتوبر لم تكن قد تلقّت أي رد، ولم يكن أحد قد شرح كيف نشأت المفاتيح الضعيفة.

الثابت بالوثائق أن المشكلة كانت قد كشفت عن نفسها قبل ذلك بأكثر من عام. ففي يونيو 2025 أظهرت خدمة مراقبة علنية أن eMudhra تقدّم ست قوائم لإلغاء الشهادات تحمل تواقيع غير صالحة لهذه الشهادات الوسيطة نفسها. وقائمة الإلغاء، أو CRL، سجلٌّ موقَّع بالشهادات التي ألغتها سلطة تصديق، ويجب أن يصحّ توقيعها عند التحقق منه بالمفتاح العام الوارد في شهادة تلك السلطة. وقال تقرير eMudhra في حينه إن Sectigo، وهي شركة شهادات أخرى، نبّهتها أول مرة برسالة بريد إلكتروني في 3 يونيو 2025، وإن مرشّحات داخلية احتجزت الرسالة في الحجر فلم يرها أحد. واستُبدلت القوائم المعيبة في 6 يونيو.

في أكتوبر 2026 شرحت eMudhra ما كان عليه ذلك الإصلاح. فقد وُقِّعت القوائم في البداية بالمفاتيح الأصلية العشوائية كما ينبغي، ولأن الشهادات كانت تحمل الأنصاف العامة للمفاتيح الضعيفة، فشلت تلك التواقيع، فأعادت الشركة توقيع القوائم بالمفاتيح المعيبة. ففي يونيو 2025 إذن، كان لدى eMudhra دليل على أن شهاداتها لا تطابق المفاتيح التي ظنّت أنها تستخدمها، وأصلحت القوائم.

سأل برنامج شهادات الجذر في Chrome لماذا اكتفت eMudhra بإعادة توقيع القوائم بدلًا من وقف عملياتها، والتحقيق في سبب وجود زوجين من المفاتيح لهذه السلطات، وإلغاء الشهادات. وتقول eMudhra إن شهادات الجذر وسلطات التصديق المُصدِرة لديها خضعت لعمليات تدقيق مستقلة عامين متتاليين. وفي 14 أكتوبر 2026، قبل بلاغ واين بثلاثة أيام، نشرت قائمة إلغاء لشهادة جذر أخرى، هي emSign Root TLS CA – G1، ولم يصحّ توقيعها هي الأخرى.

نوعان من أزرار الإيقاف

جاءت خطوة Chrome الأولى سريعة لأنها استهدفت المفاتيح. يحتفظ Chrome بقائمة حظر تُسمّى CRLSet، ترسلها غوغل إلى المتصفحات في الخلفية. وقد حظر التحديث الذي أطلقه عند الساعة 19:45 بتوقيت UTC بصماتِ المفاتيح العامة للشهادات الوسيطة الست. ولأن الحظر حدّد المفاتيح بأعيانها، فقد شمل كل شهادة تستخدم تلك المفاتيح، بما فيها أي شهادة قد يصنعها مزوّر لاحقًا. وحظرت Mozilla الشهادات في Firefox عبر قائمتها الخاصة، OneCRL، وانتهت من ذلك عند الساعة 22:59 بتوقيت UTC. وتعمل OneCRL من دون أن يحدّث المستخدمون Firefox أو حتى يعيدوا تشغيله.

القائمة المرسلة في الخلفية لا تحمي إلا البرمجيات التي تتلقّاها. ففي 20 أكتوبر أصدرت Mozilla تحديثًا لـFirefox للمستخدمين الذين حالت إعداداتهم دون وصول قائمة الحظر، ثم أصدرت لاحقًا إصلاحًا لبعض ملفات التعريف في Firefox لنظام Android لم تكن تطبّقها. وبدأت غوغل إرسال حظر مماثل إلى أجهزة Android عبر خدمات Google Play نحو الساعة 22:00 بتوقيت UTC يوم الاثنين 19 أكتوبر، وقالت في اليوم التالي إن معظمها تلقّاه. ولحقت بها مايكروسوفت وآبل في غضون أيام، وإن كانت الروايات المنشورة تختلف حول التاريخ الدقيق لإجراء آبل.

وتحرّكت سلطات التصديق أيضًا. فقد وسمت eMudhra الشهادات الثماني كلها بأنها ملغاة بحلول الساعة 09:38 بتوقيت UTC في 18 أكتوبر، وذكرت أن السبب هو اختراق سلطة التصديق. وأنهت Sectigo، التي كانت قد وقّعت الشهادات الوسيطة توقيعًا متبادلًا، إلغاء شهادات التوقيع المتبادل الخاصة بها في 19 أكتوبر. ورتّب Chrome كذلك أن ترفض سجلات Certificate Transparency أي شهادة ترتبط سلسلتها بسلطات التصديق المخترقة، حتى لا تتمكن أي شهادة مزوّرة بعد ذلك من جمع قيود السجلات التي تشترطها البرمجيات التي تتحقق من CT.

الأداة الأثقل هي إزالة شهادة الجذر التي خوّلت الشهادات الوسيطة. ففي 20 أكتوبر، وبعد أن لاحظت أن عدة أشخاص كانوا قد استعادوا المفاتيح كلٌّ بمفرده، قرّرت Mozilla الإزالة الطارئة لشهادة emSign ECC Root CA – G3، وهي شهادة الجذر التابعة لـeMudhra التي تعلو الشهادات الوسيطة المعطوبة، من مخزن الثقة لديها. لم يكن Firefox بحاجة إلى ذلك، فقد كانت OneCRL تغطيه بالفعل. كانت الإزالة لكل من عداه ممن يستخدمون قائمة الجذور لدى Mozilla أو قائمة مشتقة منها من دون OneCRL. وحذّرت Mozilla من أن هذا التغيير سيجعل بعض الخوادم غير متاحة لهؤلاء المستخدمين إلى أن تنتقل الخوادم إلى سلاسل شهادات جديدة.

وأزال Chrome شهادة الجذر نفسها من مخزنه. وتوقّعت غوغل أن يصل التغيير إلى كل الأجهزة التي تعتمد على Chrome Root Store صباح الثلاثاء 27 أكتوبر 2026، بتوقيت المحيط الهادئ، وقبل ذلك إلى نسختَي الاختبار Canary وBeta. وقالت غوغل صراحةً إن بعض الشهادات المشروعة المرتبطة سلسلتها بذلك الجذر ستتوقف عن العمل في Chrome نتيجة لذلك.

يختلف الزرّان في ما يلتقطانه ومَن يؤذيانه. فإزالة الجذر تقطع كل مسار يمر عبر ذلك الجذر، بما فيها مسارات المواقع النزيهة، لكنها تُفلت المسارات التي تمر عبر جذور أخرى، وكان للشهادات الوسيطة لدى eMudhra مسار آخر. فقد كانت Sectigo قد وقّعتها توقيعًا متبادلًا، رابطةً المفاتيح نفسها بشهادة جذر تُسمّى AAA Certificate Services، صادرة باسم Comodo. وكان Chrome قد تخلّى عن ذلك الجذر في أبريل 2025، لكن بعض الأنظمة ظلت تثق به: فقد أزالت Ubuntu شهادة emSign ECC Root CA – G3 من كل إصداراتها المدعومة، وأزالت معها جذر Comodo من الإصدارات الأقدم التي كانت لا تزال تحمله. أما الحظر المربوط بالشهادة الوسيطة نفسها فيلتقط كل الطرق دفعة واحدة. وهذا هو النهج الذي اتّبعته لغة البرمجة Go: فابتداءً من الإصدارات التي صدرت في 19 أكتوبر، يستبعد مدقّق الشهادات في Go أي سلسلة تحتوي على إحدى الشهادات الوسيطة المخترقة، أيًّا كان الجذر الذي تنتهي عنده.

التحديث الذي يقع على عاتق الآخرين

في 18 أكتوبر كتبت Mozilla في تذكرتها العلنية أنها قلقة على المنظومة الأوسع، لأن كثيرًا من الأجهزة الطرفية لا تملك وسيلة فعّالة لتلقّي معلومات الإلغاء. فالمتصفحات لديها قوائمها التي تصلها في الخلفية. أما كثير من البرمجيات الأخرى التي تُجري اتصالات آمنة فلا تملك شيئًا من هذا القبيل.

وقد فصّل موقع تتبّع الحادثة، وهو صفحة علنية أنشأها دينيس جاكسون من Mozilla، مَن هم المعرَّضون للخطر. فالتطبيقات والمكتبات البرمجية التي تأتي بحزمتها الخاصة من شهادات الجذر الموثوقة احتاجت إلى تحديثات برمجية. وكذلك التطبيقات المبنية على Electron، الإطار البرمجي الذي تقوم عليه برامج سطح مكتب مثل Slack وDiscord، والتي لا تحصل على إصلاح Electron إلا حين يُعاد بناؤها على إصدار مُرقَّع.

وكانت بعض الثغرات في ملفات الثقة الخاصة بأنظمة التشغيل نفسها. فحتى 22 أكتوبر، كان موقع الحادثة يقول إن macOS يحظر الشهادات الوسيطة المخترقة، لكن أدوات سطر الأوامر المدمجة فيه، ومنها curl وgit وpython3، تتحقق من الشهادات مقابل ملف منفصل من دون الرجوع إلى معلومات الإلغاء، وإن ذلك الملف لم يُحدَّث. وعلى Ubuntu، احتاج مخزن الثقة الخاص بـJava إلى تدخل يدوي بعد تحديث النظام بسبب مشكلة مزامنة لم تكن Canonical قد حلّتها حتى 22 أكتوبر، أما المتصفحات المثبّتة بصيغة حزم snap فلم تكن تستخدم مخزن النظام أصلًا.

وكانت ثغرات أخرى في مكتبات تحمل قوائمها الخاصة. فقد أصدرت Go إصلاحها في الإصدارين الأمنيين 1.27.3 و1.26.10، تحت المعرّف CVE-2026-111943. وأزالت حزمة certifi الواسعة الانتشار في Python شهادات الجذر الأربع كلها التابعة لـemSign في 18 أكتوبر، ثم أعادت الثلاث التي لم تتأثر في إصدار يحمل الوسم 2026.10.19، وفي 23 أكتوبر أسقط إصدار آلي اثنتين من هذه الثلاث مجددًا. وبعض المنتجات لا يمكن إصلاحها إلا على يد صانعيها: فقد خصّ فريق Talos الأمني التابع لسيسكو الشبكاتِ الافتراضية الخاصة بالذكر بوصفها مرجّحة لأن تحتاج إلى تحديثات.

وتحت كل ذلك كان Certificate Transparency. تفرضه معظم المتصفحات، لكن كثيرًا من البرامج العميلة غير المتصفحات، ومنها curl، لا تفرضه. فشهادة مزوّرة صُنعت بأحد مفاتيح eMudhra ولم تُسجَّل قط كانت ستُرفض في Chrome، لكن تلك البرامج قد تقبلها، ما دامت لا تزال تثق بسلسلة eMudhra ولم يوقفها شيء آخر، كتطبيق لا يقبل إلا الشهادات المعروفة لخوادمه هو.

ثمة حجة قوية على أن النظام نجح. فلم تُسجَّل في Certificate Transparency أي شهادات مواقع مرتبطة سلسلتها بالشهادات الوسيطة الست قبل حظر Chrome في 17 أكتوبر، ولذلك، بين إنشاء المفاتيح في أبريل 2025 وذلك الحظر، لم يكن ممكنًا استخدام أي شهادة مزوّرة منها ضد البرامج العميلة التي تفرض CT. وقال فريق Talos إنه لم يرصد أي استخدام خبيث على أرض الواقع حتى 21 أكتوبر، الساعة 14:00 بتوقيت UTC. وتقول eMudhra إن واحدة فقط من الشهادات الوسيطة المتأثرة وُضعت في الإنتاج على الإطلاق، وإن أيًّا منها لم يُصدر قط شهادة لموقع إلكتروني أو لصانع برمجيات.

بالنسبة إلى البرمجيات التي فرضت CT طوال الوقت، هذه الحجة صحيحة، وقد جاءت الحماية من قاعدة دائمة، لا من حالة الطوارئ في عطلة نهاية الأسبوع. لكن مداها أضيق مما توحي به عبارة «النظام نجح». فلم يبدأ Firefox لنظام Android فرض Certificate Transparency إلا مع الإصدار 145، الذي طُرح للمستخدمين أول مرة في 11 نوفمبر 2025. ولا تستطيع تطبيقات Android استخدام عمليات التحقق المدمجة من CT إلا بدءًا من Android 16، ولا تحصل عليها افتراضيًا إلا حين تُبنى لـAndroid 17.

وكانت لحالة الطوارئ أهميتها أيضًا في ما جاء بعدها. فقد تعمّد أول إشعار أرسلته Mozilla إلى القائمين على مخازن الثقة المتفرّعة عن قائمتها ألّا يذكر أن المفاتيح يمكن أن يستعيدها أي شخص. وبحلول 20 أكتوبر لم يعد لذلك كبير أهمية: فقد استعادها عدة أشخاص كلٌّ بمفرده، ونشر هيلم قيمها الثماني كلها. وما إن صارت المفاتيح علنية فعليًا، حتى أصبح الحظر ورفض سجلات CT هما ما يقف بينها وبين أي تزوير جديد. وحتى 24 أكتوبر، لم يكن في ما نُشر ما يبيّن إن كان مهاجمون قد استخدموا المفاتيح المعيبة ضد برامج عميلة لا تفرض CT بين أبريل 2025 وأكتوبر 2026.

مَن يمسك بالزر

القرارات المتعلقة بشهادات الجذر التي تثق بها المتصفحات وأنظمة التشغيل تعود إلى برامج شهادات الجذر، وقواعد هذه البرامج تمنح مالكيها هامشًا واسعًا. تقول سياسة Chrome إن غوغل تُدرج الشهادات أو تزيلها «وفق تقديرها المطلق»، وإن كل شهادة مُدرجة يجب أن تقدّم للمستخدمين قيمة تفوق مخاطر الإبقاء عليها. وتقول سياسة Mozilla إنها قد تعطّل شهادة أو تزيلها وفق تقديرها المطلق، في أي وقت ولأي سبب. وتقول Mozilla أيضًا إنها لا تتقاضى أي رسوم مقابل الإدراج.

وقد استُخدم هذا التقدير بطرق مختلفة. ففي عام 2014، بعد أن أصدر المركز الوطني للمعلوماتية في الهند شهادات غير مصرّح بها لعدة نطاقات تابعة لغوغل، لم يطرح Chrome شهادة الجذر India CCA التي تعلوه. بل قصر ذلك الجذر على قائمة من النطاقات الهندية. وقبل ذلك بثلاث سنوات كان الرد على سلطة تصديق هولندية شاملًا: ففي 3 سبتمبر 2011 قرّرت غوغل رفض كل سلطات التصديق التي تديرها DigiNotar، وبعد سبعة عشر يومًا أعلنت محكمة هولندية إفلاس الشركة.

DigiNotar، 2011

انكشف اختراق DigiNotar على يد مستخدم عادي. ففي 28 أغسطس 2011 كتب عميل لدى ParsOnline، وهو مزوّد إنترنت إيراني، على أحد منتديات الدعم التابعة لغوغل عن تحذير من شهادة أظهره له Chrome. كانت الشهادة تدّعي أنها لغوغل، وقد جاءت من DigiNotar، التي اختُرقت أنظمتها. وتبيّن لاحقًا لمحقّقين من شركة الأمن Fox-IT، كانوا يعملون لحساب الحكومة الهولندية، أن شهادة مارقة تغطي عناوين google.com استُخدمت في هجوم واسع على نحو 300,000 مستخدم، كلهم تقريبًا في إيران، ويُرجَّح أن حركة بياناتهم مع غوغل اعتُرضت أو أُعيد توجيهها. واستخلصوا هذا التقدير من 298,140 عنوانَ إنترنت مختلفًا تحقّقت من حالة الشهادة المزوّرة، ووصفوه بأنه تقدير تقريبي جدًا. وفي 3 سبتمبر سحبت الحكومة الهولندية ثقتها بـDigiNotar علنًا. ولم يُبلَّغ عن أي هجوم استخدم مفاتيح eMudhra حتى أواخر أكتوبر 2026. لقد أظهرت DigiNotar ما تفعله قدرة سلطة التصديق على التوقيع حين تقع في يد شخص مستعد لاستخدامها.

كتبت غوغل أن الإدراج في مخزن الجذور الخاص بـChrome يتطلب من مالك سلطة التصديق أن يُثبت باستمرار الكفاءة التقنية والصرامة التشغيلية اللازمتين لحماية مستخدمي Chrome، وقالت إنها «تحقق عن كثب» في ما إذا كان ينبغي أن تبقى شهادات سلطات التصديق المتبقية لدى eMudhra. وفي 23 أكتوبر قالت eMudhra في التذكرة العلنية إن التدقيق المكثف على وسائل التواصل الاجتماعي والتحليلات التي يجريها المستثمرون والعملاء جعلا أي تحليل ذي معنى للحادثة «شبه مستحيل». وردّ Chrome في اليوم نفسه بأن هذا ليس عذرًا، وبأن على eMudhra التزامات لا تزال قائمة تجاه «المليارات» من الناس الذين يعتمدون على النظام، وهم أناس عرّضهم خطؤها للخطر.

وكان مجلس إدارة eMudhra قد قرّر بالفعل، في 22 أكتوبر، الانسحاب من نشاط شهادات SSL/TLS على المستوى العالمي. وتقول الشركة إن هذا النشاط لا يمثّل سوى جزء صغير جدًا من عملياتها.

وتضع الشركات نفسها أيضًا قواعد مشتركة مع سلطات التصديق في هيئة تُسمّى CA/Browser Forum. ففي اقتراع أُغلق في 11 أبريل 2025، أي قبل تسعة عشر يومًا من توليد eMudhra للمفاتيح المعيبة، صوّتت آبل وغوغل ومايكروسوفت وMozilla جميعًا لصالح تقصير مدة صلاحية شهادات المواقع، وصوّتت 25 جهة إصدار للشهادات، منها eMudhra، بنعم كذلك. وكانت حجة الاقتراع أن الإلغاء لا يحمي الناس على النحو الكافي على نطاق الإنترنت، في حين أن انتهاء الصلاحية يحميهم. وجاء فيه: «مدد صلاحية الشهادات، وتطبيق الأطراف المعتمِدة لها، موثوقة إلى حدّ لا يُصدَّق». وبموجب القواعد السارية في أكتوبر 2026، لا يجوز أن تتجاوز صلاحية شهادات المواقع الصادرة اعتبارًا من 15 مارس 2026 مدة 200 يوم، و100 يوم للصادرة اعتبارًا من 15 مارس 2027، و47 يومًا للصادرة اعتبارًا من 15 مارس 2029.

هذه الحدود القصوى تنطبق على الشهادات التي تستخدمها المواقع، بحسب تاريخ إصدارها. ونص القاعدة لا يضع حدًّا لشهادات سلطات التصديق التي تقع في قلب هذه الحادثة، ولذلك ما كانت مدد الصلاحية الأقصر لتُنهي صلاحية الشهادات الوسيطة لدى eMudhra. ولم يختفِ الإلغاء كذلك. فقد أوقفت Let’s Encrypt، سلطة التصديق المجانية، في أغسطس 2025 خدمة OCSP لديها، التي كانت تتيح للمتصفحات الاستعلام عن شهادة واحدة في كل مرة، لأن كل استعلام كان يخبر سلطة التصديق بالموقع الذي تجري زيارته ومن أي عنوان إنترنت. أما أوامر الحظر الطارئة في 17 أكتوبر فكانت، في جوهرها، قوائم إلغاء انتقاها صانعو المتصفحات وأرسلوها بأنفسهم.

يضع هذا الترتيب قدرًا كبيرًا من السلطة في أيدٍ خاصة قليلة، معظمها أمريكية. وما تُظهره قضية eMudhra هو الطريقة التي تُمارَس بها هذه السلطة: في تذكرة مفتوحة يستطيع أي شخص أن يقرأ فيها الأسئلة والمهل والردود، مع أسباب تنشرها الشركات التي تتولى الإزالة.

الشهادات التي يجب أن تنتقل

إزالة شهادة جذر سريعة الإعلان بطيئة الاستيعاب. فحتى 21 أكتوبر، أحصى Chrome نحو 30,800 شهادة مسبقة (precertificate) غير منتهية الصلاحية ترتبط سلسلتها بـemSign ECC Root CA – G3. والشهادة المسبقة هي نسخة من الشهادة تُقدَّم إلى سجلات الشفافية قبل إصدارها، ولذلك فالرقم عدد للشهادات المسجّلة، لا للمواقع التي لا تزال تستخدمها. ومن بين هذه، جاءت 30,791، أي 99.9 في المئة، من شهادتين وسيطتين تابعتين لـInCommon، وهي خدمة شهادات تديرها Internet2، وهي منظمة أمريكية متخصصة في الشبكات. ولم تكن هاتان من بين الشهادات الوسيطة الثماني المعطوبة، بل كانتا ببساطة معلّقتين بالجذر الذي تجري إزالته. وقدّرت eMudhra أن نحو 30,000 شهادة تحتاج إلى الانتقال، صدرت كلها تقريبًا عبر ACME، البروتوكول الذي يتيح للخوادم طلب الشهادات وتجديدها آليًا. وأوقفت eMudhra الإصدار تحت جذر G3 في 20 أكتوبر.

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

تصل شهادات InCommon عبر CertiNext، وهي جهة توريد شركتُها الأم eMudhra. وفي 22 أكتوبر أبلغت InCommon مشتركيها بأن كثيرين منهم أمضوا الأسبوع في التعامل مع أخطاء الشهادات والتخطيط للتكيّف مع تغييرات خارجة عن سيطرتهم، بعد انتقال ناجح لكنه مُنهِك خلال الربيع والصيف. وكانت نصيحتها ذلك الصباح إعادة إصدار الشهادات المتأثرة بمفاتيح RSA إلى أن يُستأنف الإصدار بالمنحنيات الإهليلجية.

وكانت eMudhra قد قالت في 20 أكتوبر إن البديل الوحيد أمام عملاء G3 لديها هو الشهادات الوسيطة المرتبطة سلسلتها بجذرها القائم على RSA، أي emSign Root CA – G1. وقالت Mozilla في اليوم نفسه إنها لا تسحب الثقة من G1 في ذلك الوقت. وكان جذر G1 من بين شهادات eMudhra المتبقية التي قال Chrome في 20 أكتوبر إنه يحقق فيها عن كثب، وحتى 24 أكتوبر لم يكن Chrome قد أعلن أي قرار. وفي 21 أكتوبر طلب Chrome من eMudhra أن تؤكد ما إذا كان العملاء يُنقلون إلى G1، أو إلى التسلسل الهرمي لشركة أخرى، أو إلى كليهما.

تحديث InCommon مساء 22 أكتوبر حسم المشكلة العاجلة. فقد استؤنف إصدار الشهادات القائمة على المنحنيات الإهليلجية، وصارت الآن مرتبطة بجذر G1، وأصبح بوسع البرامج العميلة القائمة أن تجدّد من دون أي تغيير في إعداداتها. وذكر التحديث نفسه أن eMudhra ستتوقف عن الإصدار من أي شهادة وسيطة مرتبطة بجذورها العامة بعد 30 يومًا، في موعد ستؤكده CertiNext، وأن InCommon تعمل على مسار بديل. وبالنسبة إلى مشتركين أنهوا عملية ترحيل مرهقة في الربيع والصيف، كان سحب جذر واحد بداية لعملية ترحيل أخرى.

مقالات ذات صلة

• إلى أي مدى تطال قائمة عقوبات أمريكية محكمةً في لاهاي
• ما الذي ينتظر البيتكوين؟
• كيف يعمل الذكاء الاصطناعي فعلًا: ما يعرفه المطوّرون وتجهله العناوين

قراءات إضافية

بصفتها شريكًا في برنامج أمازون، تحصل Eikleaf على عمولة من عمليات الشراء المؤهلة. روابط الكتب أدناه روابط تابعة: إذا اشتريت من خلالها، فقد نحصل على عمولة صغيرة دون أي تكلفة إضافية عليك.

• The Code Book: The Science of Secrecy from Ancient Egypt to Quantum Cryptography — Simon Singh (1999). تاريخ ميسّر للتشفير يشرح التشفير بالمفتاح العام، وهي الرياضيات الكامنة وراء الشهادات والمفاتيح الخاصة في المقال.
• Security Engineering: A Guide to Building Dependable Distributed Systems (3rd ed.) — Ross Anderson (2001). المرجع المعتمد في كيف تفشل أنظمة الأمن الحقيقية، مع فصول عن البنية التحتية للمفتاح العام وسلطات الشهادات والثقة.
• Secrets and Lies: Digital Security in a Networked World — Bruce Schneier (2000). كاتب بارز في الأمن يشرح، دون رياضيات، لماذا لا تزيد قوة الشهادات الرقمية وسلاسل الثقة على قوة المؤسسات التي تقف وراءها.

مقاطع فيديو مقترحة

تنويه بشأن الذكاء الاصطناعي التوليدي

أُنشئ بعض محتوى هذه الصفحة و/أو حُرِّر بمساعدة الذكاء الاصطناعي التوليدي.

الوسائط

HTTPS والقفل في شريط عنوان الموقع – Wikimedia Commons (تصوير: Santeri Viinamäki, CC BY-SA 4.0)

وحدة أمان الأجهزة nCipher nShield F3 – Wikimedia Commons (تصوير: Alexander Klink, CC BY 3.0)

المقر الرئيسي «غوغلبلكس» – Wikimedia Commons (تصوير: Asoundd, CC BY-SA 4.0)

أبرز المصادر والمراجع

Mozilla Bugzilla. “Bug 2083449: eMudhra: Private key compromise of Intermediate Certificates.” Opened 18 October 2026, comments to 23 October 2026. https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

Chrome and Android Security Teams. “Protecting Chrome and Android Users from Compromised eMudhra Intermediate CA Certificates.” Google, The Keyword, 20 October 2026. https://blog.google/security/protecting-chrome-and-android-users-from-compromised-emudhra-intermediate-ca-certificates/

Mozilla dev-security-policy mailing list. “Compromised eMudhra Intermediate Certificates” thread, posts by Dennis Jackson (Mozilla) and the Chrome Root Program, 20 October 2026, and by Wayne and Corey Bonnell, 21 October 2026. https://groups.google.com/a/mozilla.org/g/dev-security-policy/c/0R3XLJL6FuE

Jackson, Dennis. “eMudhra Intermediate CA Compromise.” Incident tracking site, 20 October 2026, updated 22 October 2026. https://emudhra.we-have-a-problem.com/

InCommon (Internet2). “Moving Forward Together: InCommon Certificate Service Update.” Updates of 22 October 2026. https://incommon.org/about/news/incommon-certificate-service-update

InCommon (Internet2). “InCommon Certificate Service FAQ.” Last updated 22 October 2026, 18:30 ET. https://incommon.org/certificates

Stanescu, Luci. “eMudhra CA compromise fixes available.” Ubuntu blog, Canonical, 20 October 2026, updated 22 October 2026. https://ubuntu.com/blog/emudhra-ca-compromise-fixes-available

Canonical. “USN-8944-1: ca-certificates update” and “USN-8944-2: ca-certificates update.” Ubuntu security notices, 20 October 2026. https://ubuntu.com/security/notices/USN-8944-1 and https://ubuntu.com/security/notices/USN-8944-2

Go team. “[security] Go 1.27.3 and Go 1.26.10 are released.” golang-announce, posted 20 October 2026 (releases dated 19 October 2026). https://groups.google.com/g/golang-announce/c/66pojueaQek

Go project. “Release History.” Accessed 24 October 2026. https://go.dev/doc/devel/release

certifi. “Remove emsign (#437),” “Restore unaffected emSign roots (#439) (#440)” and “2026.10.23 (#445).” python-certifi repository, 18, 20 and 23 October 2026. https://github.com/certifi/python-certifi/commit/5cb238caeeb6c30ec1a7309ad3e16a5aa7b10ce8 and https://github.com/certifi/python-certifi/commit/662df63d7906df66f1f07c0751a3dfe9da14d914 and https://github.com/certifi/python-certifi/commit/b60466c9f2882d9cf088943c650b0faac06c080c

Cisco Talos. “Compromised eMudhra intermediate certificates.” Talos Intelligence blog, 21 October 2026. https://blog.talosintelligence.com/compromised-intermediate-certificates/

eMudhra Limited. “eMudhra Statement on distrust of select Global TLS Intermediate and one Root CA.” 21 October 2026. https://emudhra.com/en/press-release/emudhra-statement-distrust-global-tls-intermediate-root-ca

eMudhra Limited. “eMudhra to exit global SSL/TLS certificate business.” 22 October 2026. https://emudhra.com/en/press-release/emudhra-to-exit-global-ssl-tls-certificate-business

Abrams, Lawrence. “Mozilla, Google, Apple block compromised eMudhra CA certificates.” BleepingComputer, 20 October 2026. https://www.bleepingcomputer.com/news/security/mozilla-google-apple-block-compromised-emudhra-ca-certificates/

Helme, Scott. “Eight Bits of Trust; eMudhra’s CA keys cracked in milliseconds.” 20 October 2026. https://scotthelme.co.uk/eight-bits-of-trust-emudhras-ca-keys-cracked-in-milliseconds/

Sharwood, Simon. “Indian certification authority eMudhra’s private keys compromised – one of them was the number ‘4’.” The Register, 20 October 2026. https://www.theregister.com/a/5304312

Mozilla Bugzilla. “Bug 1970728: eMudhra: Invalid CRL signatures.” June 2025. https://bugzilla.mozilla.org/show_bug.cgi?id=1970728

Mozilla. “Firefox for Android 145.0 release notes.” 11 November 2025. https://www.firefox.com/en-US/firefox/android/145.0/releasenotes/

Cooper, D., et al. “RFC 5280: Internet X.509 Public Key Infrastructure Certificate and Certificate Revocation List (CRL) Profile.” IETF, May 2008. https://www.rfc-editor.org/rfc/rfc5280

Laurie, B., Langley, A., and Kasper, E. “RFC 6962: Certificate Transparency.” IETF, June 2013. https://www.rfc-editor.org/rfc/rfc6962

CA/Browser Forum. “Baseline Requirements for the Issuance and Management of Publicly-Trusted TLS Server Certificates, Version 2.3.1.” 4 October 2026, sections 3.2.2.4.7, 6.1.1.1 and 6.3.2. https://github.com/cabforum/servercert/blob/3574ae809e5f909b58ee4c26b7bac4a3b9e78421/docs/BR.md

CA/Browser Forum. “Ballot SC081v3: Introduce Schedule of Reducing Validity and Data Reuse Periods.” 11 April 2025. https://cabforum.org/2025/04/11/ballot-sc081v3-introduce-schedule-of-reducing-validity-and-data-reuse-periods/

Google. “Chrome Root Program Policy, Version 1.8.” Last updated 5 February 2026. https://googlechrome.github.io/chromerootprogram/crp/policy/

Mozilla. “Mozilla Root Store Policy, Version 3.1.” Effective 1 July 2026. https://www.mozilla.org/en-US/about/governance/policies/security-group/certs/policy/

Aas, Josh. “OCSP Service Has Reached End of Life.” Let’s Encrypt, 6 August 2025. https://letsencrypt.org/2025/08/06/ocsp-service-has-reached-end-of-life/

Adrian, David, Serena Chen, Joe DeBlasio, Emily Stark and Emanuel von Zezschwitz. “An update on the lock icon.” Chromium Blog, May 2023. https://blog.chromium.org/2023/05/an-update-on-lock-icon.html

von Zezschwitz, Emanuel, Emily Margarete Stark and Serena Chen. “‘It builds trust with the customers’ – Exploring User Perceptions of the Padlock Icon in Browser UI.” SecWeb 2022, IEEE. https://research.google/pubs/it-builds-trust-with-the-customers-exploring-user-perceptions-of-the-padlock-icon-in-browser-ui/

Android Developers. “Network security configuration: Certificate transparency.” Accessed 24 October 2026. https://developer.android.com/privacy-and-security/security-config

Langley, Adam. “Maintaining digital certificate security.” Google Online Security Blog, July 2014. https://security.googleblog.com/2014/07/maintaining-digital-certificate-security.html

Adkins, Heather. “An update on attempted man-in-the-middle attacks.” Google Online Security Blog, 29 August 2011, updated 3 September 2011. https://security.googleblog.com/2011/08/update-on-attempted-man-in-middle.html

Fox-IT. “Black Tulip: Report of the investigation into the DigiNotar Certificate Authority breach.” 13 August 2012. https://zoek.officielebekendmakingen.nl/blg-191225.pdf