أنشأت شركة شهادات هندية ثمانية مفاتيح خاصة، وكانت قيمة أحدها 4.
في الجمعة الماضية، عند الساعة 8:06 مساءً، أبلغ باحث يُدعى Wayne بالأمر كلاً من Firefox وChrome. وعند الساعة 9:48 مساءً، استخرج موظفو Mozilla المفاتيح الثمانية كلها من جانبهم. لم يسألوا الطرف الآخر عن الطريقة التي استخدمها. وعند الساعة 10:59 مساءً، أُضيفت المفاتيح إلى قائمة الحظر التي دُفعت إلى Firefox بالإعدادات الافتراضية. أقل من ثلاث ساعات.
كان يفترض أن تكون هذه مفاتيح خاصة على منحنى P-384، بمساحة بحث تعادل عددًا عشريًا مؤلفًا من 116 خانة.
كانت القيم التي قِيست هي 4 و56 و115، وحتى أكبرها لم يتجاوز 237؛ وكلها أقل من 256. قال الباحث Scott Helme إنه استخرج المفاتيح الثمانية كلها من الشهادات العامة في أقل من ثانية. استخرجها. بهذه السرعة.
يظن كثيرون أن مشكلة الشهادات تعني أن الأنظمة تعرضت للاختراق. لكن ذلك لم يحدث هذه المرة. لم يدخل أحد إلى مركز البيانات، ولم تُفقد أي بيانات، وكانت جميع الضوابط المادية والمنطقية سليمة؛ هذا ما ورد في الإشعار الذي أصدرته eMudhra إلى بورصة بومباي وبورصة الهند الوطنية. فكيف أصبح هذا المفتاح ضعيفًا؟ كُتب نص توليد المفاتيح على نحو خاطئ. ففي مراسم توليد المفاتيح التي أُقيمت في 30 أبريل من العام الماضي، وهي مراسم نُفذت بالكامل وفق وحدات الأجهزة الأمنية من المستوى الثالث المتوافقة مع FIPS 140-2، أُنتجت مجموعة إضافية من المفاتيح الضعيفة أثناء خطوة wrap وunwrap. والمشكلة أن تسمياتها كانت متشابهة. ثم اختيرت المجموعة الخطأ عند إعداد طلب التوقيع، وأُرسلت المجموعة الضعيفة.
اجتازت الشركة عمليات التدقيق لعامين متتاليين، ثم أُضيفت إلى قائمة الثقة في المتصفحات في منتصف عام 2025. ومع ذلك، مرّ 18 شهرًا ولم يلاحظ أحد شيئًا. كانت عمليات التدقيق تتحقق من أن الإجراءات نُفذت وفق الوثائق، لا من أن عشوائية هذا المفتاح كافية.
وتكمن المشكلة أيضًا في بنية سلسلة الثقة. فالشهادات التي توقّعها جهة إصدار شهادات وسيطة يقبلها جميع من هم أدنى منها في السلسلة. ومن بين المفاتيح الوسيطة الثمانية، كان ستة منها تُستخدم لـ TLS واثنان لتوقيع الشيفرات. ويقدّر Yash Kadakia من Security Brigade أن نحو 30,000 شهادة سليمة لا تزال قيد الاستخدام تحتاج إلى نقل. ويقول أيضًا إن تعثر شركة واحدة قد يجرّ منظمات لم تتعامل معها قط إلى الهاوية، بسبب سلاسل الثقة في الإنترنت العالمي.
يمكن إلقاء نظرة على سرعة استجابة المتصفحات الأربعة. حظر Chrome وFirefox الشهادات في اليوم نفسه، في 17 من الشهر. وفعلت Apple ذلك في 19، ثم Microsoft في 20. تلقت Cloudflare البلاغ في 19 وأصدرت تقريرها في 20. حظرت Google بصمة المفتاح العام، ولذلك حُجبت أيضًا الشهادات المتقاطعة الموقعة بالمفتاح نفسه، من دون الحاجة حتى إلى إعادة التشغيل. كان هذا الجزء حاسمًا.
لكن ما لم يُعالج فعلًا هو ما يقع خارج المتصفحات. الخدمات المكتوبة بـ Go، وبرامج Python التي تستخدم certifi، ومكتبة webpki-roots في Rust، ومجموعة من تطبيقات Android التي تضم مكتبات شهادات خاصة بها، وأنظمة Java القديمة في مراكز البيانات، والبوابات المؤسسية، وكاميرات المراقبة، وأجهزة التوجيه؛ قوائم الثقة لديها ليست هي نفسها قائمة Chrome إطلاقًا. أصلحت المتصفحات المشكلة في ثلاث ساعات، أما هذه المكونات فلا خيار لها سوى انتظار تحديث نسختها الخاصة. وسرعة الإصلاح تعتمد على وتيرة تحديث المكوّن، لا على حجم الحادثة. كم مرة يُحدّث جهاز التوجيه في منزلك؟ هل تعرف؟ لم يحصِ أحد ذلك، وحتى الآن لا توجد إجابة مؤكدة.
نشر Dennis Jackson من Mozilla صفحة اختبار تتيح لك التحقق مما إذا كان عميلك لا يزال يثق بهذه الشهادات. يستغرق الأمر بضع عشرات من الثواني. اذهب وتحقق بنفسك.
أما ما تبقى، فهو الجزء الذي يستحق التأمل. يقوم نظام HTTPS بأكمله في الواقع على قائمة: أُعطيك قائمة بالشركات التي أثق بها، ولا أثق بمن هم خارجها. وأقوى ما يمكن فعله بعد وقوع مشكلة هو شطب الاسم. ويمكن شطبه فعلًا. القائمة بيد المتصفحات، وليست بيد الشركة التي تسببت بالمشكلة.
أما منظومة البلوك تشين فتسير بالعكس. لا توجد شركة في Bitcoin تستطيع أن توقّع مرة واحدة فيقبل الجميع. يتحقق كل عقدة بنفسها من التاريخ كله، بدءًا من أول معاملة. بطيء. مرهق. يستهلك الكهرباء. لكنه عند حدوث خلل لا يضطر إلى انتظار المتصفحات الأربعة كي تصدر كل منها قائمة منفصلة. والثمن حقيقي أيضًا: لا وجود للإلغاء على السلسلة؛ إذا أُرسل شيء بالخطأ، فسيبقى في دفتر الأستاذ إلى الأبد.
التوقيعات المتعددة في جسور السلاسل، وأسعار التغذية التي توفرها أوراكلات البيانات، وإثباتات احتياطيات العملات المستقرة؛ كلها تؤدي العمل نفسه الذي تؤديه جهة إصدار الشهادات الوسيطة. يوقّع الطرف الأعلى في السلسلة، فيثق به الطرف الأدنى. وإذا وقع خلل، فلن يختلف شكله كثيرًا عما حدث هذه المرة.
الفارق الوحيد هو ما إذا كان بالإمكان إعادة التحقق بعد وقوع الحادثة. في سلسلة الشهادات، لا يسعك إلا انتظار تحديث القائمة. أما في سلسلة دفتر الأستاذ، فيمكنك إعادة التحقق من كل معاملة.
وعلى أرض الواقع، هناك أمران ينبغي فعلهما. راجع الخدمات التي تعمل باستمرار، وتحقق مما إذا كان أي منها لا يزال يعتمد على شهادة قديمة. ثم تفقد قائمة عناوين السحب المسموح بها في محفظتك ومنصة التداول: هل الأشخاص الثلاثة الموقّعون على التوقيع المتعدد يعملون من المكتب نفسه، وعلى الخدمة السحابية نفسها، وتحت إدارة رقم الهاتف نفسه؟ إذا اجتمع اثنان من هذه الأمور الثلاثة، فلن يبقى من مستويات الأمان سوى مستوى واحد.
$BTC $ETH $LINK
#比特币 #以太坊 #网络安全 #سلسلة_الشهادات
في الجمعة الماضية، عند الساعة 8:06 مساءً، أبلغ باحث يُدعى Wayne بالأمر كلاً من Firefox وChrome. وعند الساعة 9:48 مساءً، استخرج موظفو Mozilla المفاتيح الثمانية كلها من جانبهم. لم يسألوا الطرف الآخر عن الطريقة التي استخدمها. وعند الساعة 10:59 مساءً، أُضيفت المفاتيح إلى قائمة الحظر التي دُفعت إلى Firefox بالإعدادات الافتراضية. أقل من ثلاث ساعات.
كان يفترض أن تكون هذه مفاتيح خاصة على منحنى P-384، بمساحة بحث تعادل عددًا عشريًا مؤلفًا من 116 خانة.
كانت القيم التي قِيست هي 4 و56 و115، وحتى أكبرها لم يتجاوز 237؛ وكلها أقل من 256. قال الباحث Scott Helme إنه استخرج المفاتيح الثمانية كلها من الشهادات العامة في أقل من ثانية. استخرجها. بهذه السرعة.
يظن كثيرون أن مشكلة الشهادات تعني أن الأنظمة تعرضت للاختراق. لكن ذلك لم يحدث هذه المرة. لم يدخل أحد إلى مركز البيانات، ولم تُفقد أي بيانات، وكانت جميع الضوابط المادية والمنطقية سليمة؛ هذا ما ورد في الإشعار الذي أصدرته eMudhra إلى بورصة بومباي وبورصة الهند الوطنية. فكيف أصبح هذا المفتاح ضعيفًا؟ كُتب نص توليد المفاتيح على نحو خاطئ. ففي مراسم توليد المفاتيح التي أُقيمت في 30 أبريل من العام الماضي، وهي مراسم نُفذت بالكامل وفق وحدات الأجهزة الأمنية من المستوى الثالث المتوافقة مع FIPS 140-2، أُنتجت مجموعة إضافية من المفاتيح الضعيفة أثناء خطوة wrap وunwrap. والمشكلة أن تسمياتها كانت متشابهة. ثم اختيرت المجموعة الخطأ عند إعداد طلب التوقيع، وأُرسلت المجموعة الضعيفة.
اجتازت الشركة عمليات التدقيق لعامين متتاليين، ثم أُضيفت إلى قائمة الثقة في المتصفحات في منتصف عام 2025. ومع ذلك، مرّ 18 شهرًا ولم يلاحظ أحد شيئًا. كانت عمليات التدقيق تتحقق من أن الإجراءات نُفذت وفق الوثائق، لا من أن عشوائية هذا المفتاح كافية.
وتكمن المشكلة أيضًا في بنية سلسلة الثقة. فالشهادات التي توقّعها جهة إصدار شهادات وسيطة يقبلها جميع من هم أدنى منها في السلسلة. ومن بين المفاتيح الوسيطة الثمانية، كان ستة منها تُستخدم لـ TLS واثنان لتوقيع الشيفرات. ويقدّر Yash Kadakia من Security Brigade أن نحو 30,000 شهادة سليمة لا تزال قيد الاستخدام تحتاج إلى نقل. ويقول أيضًا إن تعثر شركة واحدة قد يجرّ منظمات لم تتعامل معها قط إلى الهاوية، بسبب سلاسل الثقة في الإنترنت العالمي.
يمكن إلقاء نظرة على سرعة استجابة المتصفحات الأربعة. حظر Chrome وFirefox الشهادات في اليوم نفسه، في 17 من الشهر. وفعلت Apple ذلك في 19، ثم Microsoft في 20. تلقت Cloudflare البلاغ في 19 وأصدرت تقريرها في 20. حظرت Google بصمة المفتاح العام، ولذلك حُجبت أيضًا الشهادات المتقاطعة الموقعة بالمفتاح نفسه، من دون الحاجة حتى إلى إعادة التشغيل. كان هذا الجزء حاسمًا.
لكن ما لم يُعالج فعلًا هو ما يقع خارج المتصفحات. الخدمات المكتوبة بـ Go، وبرامج Python التي تستخدم certifi، ومكتبة webpki-roots في Rust، ومجموعة من تطبيقات Android التي تضم مكتبات شهادات خاصة بها، وأنظمة Java القديمة في مراكز البيانات، والبوابات المؤسسية، وكاميرات المراقبة، وأجهزة التوجيه؛ قوائم الثقة لديها ليست هي نفسها قائمة Chrome إطلاقًا. أصلحت المتصفحات المشكلة في ثلاث ساعات، أما هذه المكونات فلا خيار لها سوى انتظار تحديث نسختها الخاصة. وسرعة الإصلاح تعتمد على وتيرة تحديث المكوّن، لا على حجم الحادثة. كم مرة يُحدّث جهاز التوجيه في منزلك؟ هل تعرف؟ لم يحصِ أحد ذلك، وحتى الآن لا توجد إجابة مؤكدة.
نشر Dennis Jackson من Mozilla صفحة اختبار تتيح لك التحقق مما إذا كان عميلك لا يزال يثق بهذه الشهادات. يستغرق الأمر بضع عشرات من الثواني. اذهب وتحقق بنفسك.
أما ما تبقى، فهو الجزء الذي يستحق التأمل. يقوم نظام HTTPS بأكمله في الواقع على قائمة: أُعطيك قائمة بالشركات التي أثق بها، ولا أثق بمن هم خارجها. وأقوى ما يمكن فعله بعد وقوع مشكلة هو شطب الاسم. ويمكن شطبه فعلًا. القائمة بيد المتصفحات، وليست بيد الشركة التي تسببت بالمشكلة.
أما منظومة البلوك تشين فتسير بالعكس. لا توجد شركة في Bitcoin تستطيع أن توقّع مرة واحدة فيقبل الجميع. يتحقق كل عقدة بنفسها من التاريخ كله، بدءًا من أول معاملة. بطيء. مرهق. يستهلك الكهرباء. لكنه عند حدوث خلل لا يضطر إلى انتظار المتصفحات الأربعة كي تصدر كل منها قائمة منفصلة. والثمن حقيقي أيضًا: لا وجود للإلغاء على السلسلة؛ إذا أُرسل شيء بالخطأ، فسيبقى في دفتر الأستاذ إلى الأبد.
التوقيعات المتعددة في جسور السلاسل، وأسعار التغذية التي توفرها أوراكلات البيانات، وإثباتات احتياطيات العملات المستقرة؛ كلها تؤدي العمل نفسه الذي تؤديه جهة إصدار الشهادات الوسيطة. يوقّع الطرف الأعلى في السلسلة، فيثق به الطرف الأدنى. وإذا وقع خلل، فلن يختلف شكله كثيرًا عما حدث هذه المرة.
الفارق الوحيد هو ما إذا كان بالإمكان إعادة التحقق بعد وقوع الحادثة. في سلسلة الشهادات، لا يسعك إلا انتظار تحديث القائمة. أما في سلسلة دفتر الأستاذ، فيمكنك إعادة التحقق من كل معاملة.
وعلى أرض الواقع، هناك أمران ينبغي فعلهما. راجع الخدمات التي تعمل باستمرار، وتحقق مما إذا كان أي منها لا يزال يعتمد على شهادة قديمة. ثم تفقد قائمة عناوين السحب المسموح بها في محفظتك ومنصة التداول: هل الأشخاص الثلاثة الموقّعون على التوقيع المتعدد يعملون من المكتب نفسه، وعلى الخدمة السحابية نفسها، وتحت إدارة رقم الهاتف نفسه؟ إذا اجتمع اثنان من هذه الأمور الثلاثة، فلن يبقى من مستويات الأمان سوى مستوى واحد.
$BTC $ETH $LINK
#比特币 #以太坊 #网络安全 #سلسلة_الشهادات