في النهاية ، أشارت تغريدة جيف جونسون بوضوح إلى السبب الجذري. اتضح أن خدمة مستجيب OCSP من Apple كانت محملة أكثر من اللازم ، لذلك لم يتمكن macOS من التحقق من شهادات التشفير لمطوري التطبيقات.
ولكن لماذا يعتبر مستجيب OCSP على المسار الحرج لإطلاق التطبيقات؟ في هذه المقالة ، سنناقش بإيجاز توقيع الكود ، وكيف يعمل بروتوكول حالة الشهادة عبر الإنترنت (OCSP) ، ولماذا خاطئ تمامًا ، وبعض أفضل البدائل. على عكس المنشورات الأخرى حول هذا الحادث ، أود مناقشة الجوانب العملية للتشفير (على مستوى عالٍ) وتقديم منظور متوازن.
التوقيع بالرمز
في بوابة المطورين ، تشرح Apple الغرض من توقيع الكود:
يضمن توقيع كود تطبيقك للمستخدمين أنه يأتي من مصدر معروف ولم يتم تعديله منذ آخر مرة تم التوقيع عليه. يجب توقيع التطبيق بشهادة صادرة عن Apple قبل أن يمكن دمجه أو تثبيته على جهاز أو إدخاله في كتالوج التطبيق.
بمعنى آخر ، لكي يتم الوثوق بتطبيق ما على macOS ، يجب توقيعه بشهادته الخاصة القائمة على زوج المفاتيح. يتم استخدام سلسلة المفاتيح لإنشاء شهادة "معرف مطور" فريدة تتضمن مفتاحًا خاصًا ليستخدمه المطور ومفتاحًا عامًا للتوزيع. عندما تقوم Apple بالتوقيع على شهادة معرف المطور ، يمكن للمطور استخدام المفتاح الخاص لإنشاء توقيعات مشفرة على تطبيقاتهم مع كل إصدار.
عندما يتم تشغيل التطبيق ، يتم التحقق من توقيعه مقابل المفتاح العام لشهادة المطور. ثم يتم التحقق من الشهادة نفسها للتأكد من أنها لم تنتهِ صلاحيتها (عادةً ما تكون الشهادات صالحة لمدة عام واحد) ، وأنها موقعة في النهاية بواسطة شهادة جذر Apple. يمكن أيضًا أن تكون هناك شهادات متوسطة كجزء من السلسلة حتى الشهادة الجذر. هذه "سلسلة ثقة" لأنه تم توقيع شهادة معرف المطور بواسطة التطبيق ، والشهادة الوسيطة وقعت على شهادة معرف المطور ، وشهادة جذر Apple وقعت على الشهادة الوسيطة. يمكن لأي جهاز Apple التحقق من سلسلة الثقة هذه ، وبالتالي الموافقة على إطلاق التطبيق.
هذا مشابه لبنية المفتاح العام TLS للإنترنت. ولكن أيضًا يختلف اختلافًا جوهريًا ، حيث تمتلك Apple سيطرة كاملة على سلسلة الثقة الخاصة بها. لا يُسمح لمراجع التصديق الأخرى بإصدار شهادات توقيع رمز صالحة لأنه يجب ربط جميع الشهادات بـ Apple.
إذا فشل التحقق ، فسترى المستخدم نافذة رهيبة:
ردود الفعل
ماذا يحدث إذا انتهك مطور سياسات Apple أو فقد مفتاحه الخاص؟ يجب على المرجع المصدق إبطال الشهادات الصادرة على الفور. إذا تم استخدام شهادة بشكل ضار ، فمن غير المقبول الانتظار أيامًا أو شهورًا حتى تنتهي صلاحيتها بشكل طبيعي ، وإلا فإن تسرب المفتاح الخاص سيجعل النظام بأكمله عديم الفائدة.
في هذه الحالة يتم إبطال الشهادة. هذه خطوة إضافية في عملية التحقق من التوقيع ، والتي تتضمن مطالبة المرجع المصدق بأن الشهادة لا تزال صالحة.
على الإنترنت ، يتم ذلك بأبسط طريقة. يمنحك المرجع المصدق (CA) قائمة إبطال الشهادات (CRL) مع الأرقام التسلسلية لجميع الشهادات الملغاة ، وتتحقق من عدم وجود الشهادة في القائمة. ومع ذلك ، توقفت المتصفحات عن استخدام هذا الأسلوب لأن القائمة أصبحت أطول وأطول. خاصة بعد المآثر المروعة مثل Heartbleed التي تطلبت عمليات إلغاء شهادات ضخمة.
بروتوكول حالة الشهادة عبر الإنترنت (OCSP) هو بديل يسمح لك بالتحقق من صحة الشهادات في الوقت الفعلي. تحتوي كل شهادة على مستجيب OCSP مضمن ، وهو عنوان URL الذي تطلبه ويخبرك إذا تم إبطال الشهادة. في حالة Apple ، هذا هو
ocsp.apple.com... الآن ، بالإضافة إلى التحقق من صلاحية التشفير للتوقيع ، في كل مرة تقوم فيها بتشغيل التطبيق ، تقوم بإجراء فحص في الوقت الفعلي على موقع Apple (مع بعض التخزين المؤقت) بحيث لا يزالون يعتبرون أن شهادة المطور شرعية.
مشكلة توفر OCSP
المشكلة الكبيرة في OCSP هي أن الخدمة الخارجية تصبح نقطة فشل واحدة. ماذا يحدث إذا كان مستجيب OCSP معطلاً أو غير متوفر؟ هل نرفض فقط التحقق من الشهادة (فشل شديد)؟ أم نتظاهر بأن الشيك كان ناجحًا (فشل بسيط)؟
تُجبر Apple على استخدام سلوك الفشل الناعم ، وإلا فلن تعمل التطبيقات في وضع عدم الاتصال. تنفذ جميع المتصفحات الرئيسية أيضًا سلوك فشل ضعيف نظرًا لأن مستجيبي OCSP غير موثوقين تقليديًا ويريد المتصفح تحميل الموقع حتى إذا كان مستجيب CA معطلاً مؤقتًا.
لكن فشل soft-فشل ليس خيارًا جيدًا ، لأنه من خلال التحكم في الشبكة ، يمكن للمهاجم حظر الطلبات إلى المستجيب ، وسيتم تخطي الفحص. في الواقع ، تم تعميم مثل هذا "الإصلاح" للخطأ على نطاق واسع على Twitter خلال هذه الحادثة: تم
ocsp.apple.comحظر حركة المرور إليه بواسطة سطر في ملف etc / hosts / /. سيترك الكثير من هذا الخط لفترة من الوقت ، لأن تعطيل OCSP لا يسبب أي مشاكل ملحوظة.
حادث
إذا كانت عملية التحقق من صحة OCSP من Apple مبنية على فشل بسيط ، فلماذا تتوقف التطبيقات عند تعطيل مستجيب OCSP؟ ربما لأنه كان في الواقع خللًا مختلفًا: لم يتم تعطيل مستجيب OCSP تمامًا. انها فقط لم تعمل بشكل جيد.
نظرًا للحمل من ملايين المستخدمين حول العالم الذين كانوا يقومون بالتحديث إلى macOS Big Sur ، تباطأت خوادم Apple ولم تستجيب بشكل صحيح لطلبات OCSP. لكن في نفس الوقت عملوا بشكل جيد بما فيه الكفاية لدرجة أن الفشل الضعيف لم ينجح.
مشكلة خصوصية OCSP
بالإضافة إلى مشكلة توفر OCSP ، لم يتم تصميم البروتوكول لحماية الخصوصية في المقام الأول. يتضمن طلب OCSP الأساسي طلب HTTP غير مشفر إلى مستجيب OCSP مع الرقم التسلسلي للشهادة. وبالتالي ، لا يستطيع المستجيب تحديد الشهادة التي تهتم بها فحسب ، بل يستطيع أيضًا موفر خدمة الإنترنت وأي شخص آخر يعترض الحزم. يمكن أن تسرد Apple ، بالترتيب ، تطبيقات المطورين التي تفتحها ، ويمكن للأجانب فعل الشيء نفسه.
كان من الممكن إضافة التشفير ، وهناك إصدار أفضل وأكثر خصوصية يسمى OCSP stapling ، لكن Apple لم تفعل ذلك أيضًا. تدبيس OCSP ليس منطقيًا حقًا في هذا السيناريو ، لكن هذه التقنية توضح أن OCSP لا ينبغي أن يتسرب البيانات افتراضيًا.
مستقبل افضل
أثار الحادث نقاشًا حيويًا في المجتمع ، حيث قال أحد الجانبين "جهاز الكمبيوتر الخاص بك ليس ملكك حقًا" ، بينما جادل الآخر ، "إن بناء الثقة في التطبيقات أمر صعب ، لكن Apple تفعل ذلك جيدًا . " أحاول إظهار أن OCSP هي طريقة مروعة لإدارة عمليات إلغاء الشهادات على أي حال ، وستؤدي في المستقبل إلى المزيد من الحوادث المتعلقة بتوافر المستجيب والخصوصية. في رأيي ، هذا قرار هندسي سيئ - لتعيين تبعية مشغل التطبيق على OCSP. على المدى القصير على الأقل ، قاموا بتخفيف الضرر عن طريق زيادة أوقات التخزين المؤقت للاستجابة .
لحسن الحظ ، فإن أفضل طريقة لإلغاء الشهادات ، وهي CRLite ، قد نضجت تقريبًا. يسمح لك بتقصير جميع قوائم إبطال الشهادات إلى حجم معقول. في سكوت HELME بلوق موجزا خير كيف يستخدم CRLite مرشحات بلوم للعودة النهج القديم مع قائمة الشهادات المبطلة، والتي تعمل حتى OCSP.
قد تتلقى أجهزة MacOS تحديثات دورية لقائمة الشهادات الباطلة (CRL) هذه وتقوم بإجراء فحوصات محليًا على الجهاز ، ومعالجة مشكلات توفر OCSP والخصوصية. من ناحية أخرى ، نظرًا لأن قائمة إبطال معرف المطور أصغر بكثير من قائمة جميع الشهادات التي تم إبطالها في PKI ، يجدر التساؤل عن سبب عدم استخدام Apple لقواعد إلغاء الشهادات. قد لا يرغبون في الكشف عن الشهادات التي تم إبطالها.
خاتمة
بشكل عام ، كان هذا الحادث سببًا جيدًا للتفكير في نموذج الثقة الذي تروج له مؤسسات مثل Apple و Microsoft. أصبحت البرامج الضارة أكثر تعقيدًا ، ولا يستطيع معظم الأشخاص تحديد ما إذا كان تشغيل بعض الثنائيات آمنًا أم لا. يبدو أن توقيع الكود طريقة تشفير رائعة لتأسيس الثقة في التطبيقات وربط التطبيقات على الأقل بمطورين معروفين. وإلغاء الشهادات جزء ضروري من تلك الثقة.
لكن مجرد بعض الثغرات في عملية التحقق من OCSP تفسد أناقة التشفير لعملية توقيع الرمز والتحقق منه. يستخدم OCSP أيضًا على نطاق واسع لشهادات TLS على الإنترنت ، ولكن الإخفاقات هناك أقل كارثية بسبب العدد الكبير من المراجع المصدقة والجهل المنتشر بالفشل من المتصفحات. علاوة على ذلك ، اعتاد الأشخاص على رؤية مواقع الويب غير متوفرة من وقت لآخر ، لكنهم لا يتوقعون نفس الشيء من التطبيقات الموجودة على أجهزة الكمبيوتر الخاصة بهم. يشعر مستخدمو MacOS بالقلق من تأثر تطبيقاتهم بمشاكل البنية التحتية لشركة Apple. ومع ذلك ، فهذه نتيجة حتمية ، تنبع من حقيقة أن التحقق من صحة الشهادة يعتمد على البنية التحتية الخارجية ، ولا توجد بنية تحتية يمكن الاعتماد عليها بنسبة 100٪.
كما يعرب سكوت هيلم عن مخاوفه بشأن السلطة التي تحصل عليها CA إذا كان إلغاء الشهادات فعالاً حقًا. حتى إذا لم تكن قلقًا بشأن احتمال وجود رقابة ، فستحدث أخطاء في بعض الأحيان ويجب موازنتها مقابل مزايا الأمان. كما اكتشف أحد المطورين عندما ألغت شركة Apple شهادته عن طريق الخطأ ، فإن خطر التشغيل على نظام أساسي معزول هو أنه يمكن عزلك عنها.