تثبيت الشهادات في تطبيقات الأجهزة المحمولة وسطح المكتب

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

هناك ثلاثة مستويات لتثبيت الشهادات: (1) تثبيت الشهادة كاملة — يجب أن تتطابق الشهادة المشفّرة بترميز DER تمامًا. وهذا النوع هو الأكثر هشاشة؛ إذ يتعطل عند أي تجديد للشهادة. (2) تثبيت المفتاح العام — تتم مقارنة وحدات SubjectPublicKeyInfo (SPKI) فقط. ويستمر في العمل عند تجديد الشهادة إذا أُبقي على زوج المفاتيح نفسه. (3) تجزئة SPKI — يُخزَّن SHA-256(SPKI) بدلًا من المفتاح الخام. وهذا هو النهج المتبع في HTTP Public Key Pinning (HPKP) وAndroid Network Security Config. ويُفضَّل تثبيت المفتاح العام أو SPKI؛ لأنه يتحمل تبديل CA وتجديد الشهادة مع الاستمرار في اكتشاف هجمات MITM باستخدام زوج مفاتيح مختلف.

يوفر Android (API 24+) آلية تثبيت تصريحية عبر ملف XML الخاص بـ Network Security Config. ويحدد الملف res/xml/network_security_config.xml عمليات التثبيت لكل نطاق: pin-set مع digest="SHA-256" وتجزئة SPKI بترميز base64. ويشير التطبيق إلى هذا الملف في AndroidManifest.xml عبر android:networkSecurityConfig. ويفرض Android عمليات التثبيت على جميع اتصالات HTTP التي تُجرى عبر HttpsURLConnection القياسي وOkHttp (عند استخدام مدير الثقة الخاص بالمنصة). ويتطلب pin-set تثبيتًا احتياطيًا واحدًا على الأقل (مفتاحًا مختلفًا أو تثبيت CA مختلفًا) لمنع فقدان الوصول إذا اختُرق المفتاح الأساسي. وتفرض صلاحية التثبيت (السمة expiration) تحديث التطبيقات قبل أن تصبح عمليات التثبيت قديمة.

تنفّذ تطبيقات iOS تثبيت الشهادات في مفوّضي NSURLSession. وتتلقى طريقة المفوّض URLSession(_:didReceive:completionHandler:) كائن ثقة الخادم. ويستدعي التطبيق SecTrustEvaluateWithError للتحقق من السلسلة، ثم يستخرج الشهادة الطرفية باستخدام SecTrustGetCertificateAtIndex(trust, 0)، ويصدّر وحدات SPKI، ويجزّئها باستخدام SHA-256، ثم يقارنها بالتثبيت المخزّن. وتغلف TrustKit (مكتبة مفتوحة المصدر) هذا النمط من خلال تثبيت قائم على الإعدادات، مع دعم عمليات تثبيت متعددة ومطابقة النطاقات الفرعية ووضع إعداد التقارير فقط. ويختلف App Transport Security (ATS) من Apple عن تثبيت الشهادات؛ إذ يفرض ATS حدودًا دنيا لإصدار TLS، لكنه لا يثبت المفاتيح.

حاول HTTP Public Key Pinning (HPKP، ‏RFC 7469) إضافة تثبيت الشهادات إلى متصفحات الويب عبر ترويسات استجابة HTTP: Public-Key-Pins: pin-sha256="base64=="; max-age=5184000; includeSubDomains. وكان المتصفح يتذكر التثبيت طوال مدة max-age ويرفض الاتصالات بالمفاتيح غير المطابقة. وقد أهمل Chrome استخدام HPKP في عام 2017 وأزاله في عام 2019 بسبب حالات الفشل الكارثية؛ إذ كان يمكن لخطأ واحد في الإعداد أو فقدان المفتاح أن يمنع المستخدمين نهائيًا من الوصول إلى موقع ويب من دون مسار للاسترداد. وأصبح HPKP الآن غير مستخدم فعليًا في متصفحات الويب، بينما يظل التثبيت على مستوى التطبيق في تطبيقات الأجهزة المحمولة قابلًا للاستخدام، لأن تحديثات التطبيقات يمكن أن تتضمن عمليات تثبيت جديدة.

يدعم OkHttp (المستخدم على نطاق واسع في Android) تثبيت الشهادات عبر CertificatePinner: CertificatePinner.Builder().add("api.example.com", "sha256/AAAA...==", "sha256/BBBB...==").build(). والتثبيت الثاني هو التثبيت الاحتياطي. ويتحقق OkHttp من تطابق تثبيت واحد على الأقل مع أي شهادة في سلسلة الخادم، سواء أكانت الشهادة طرفية أم وسيطة أم جذرية. ويتيح ذلك تثبيت CA وسيطة (بما يسمح باستمرار العمل عند تدوير شهادة طرفية) أو تثبيت CA الجذرية (بما يسمح باستمرار العمل عند تدوير CA الوسيطة). ويطرح OkHttp استثناء SSLPeerUnverifiedException مع رسالة مفيدة تسرد تجزئات SPKI الفعلية للخادم، ما يجعل استخراج التثبيت أثناء التطوير أمرًا مباشرًا.

يرفع تثبيت الشهادات مستوى صعوبة اعتراض حركة المرور، لكنه ليس عصيًا على الكسر. تشمل تقنيات التجاوز الشائعة على الأجهزة المحمولة: (1) خطافات Frida — حقن JavaScript في عملية التطبيق لاعتراض طريقة التحقق من التثبيت وإرجاع true دائمًا. (2) أدوات SSLUnpinning — نصوص Frida/Objection الآلية التي تستهدف مكتبات التثبيت الشائعة (TrustKit وOkHttp وSecTrust الأصلية). (3) ROM مخصص — إجراء root للجهاز وتعديل حزمة TLS. (4) إعادة التغليف — فك ترجمة APK وتعديل إعداد التثبيت ثم إعادة تغليفه بشهادة جديدة. (5) تعديل الذاكرة — تعديل شفرة التحقق أثناء التشغيل. وتشمل إجراءات الحد من المخاطر اكتشاف root/jailbreak، وتمويه الشفرة، وفحوصات السلامة (SafetyNet/App Attest).

يتمثل أكبر خطر تشغيلي لتثبيت الشهادات في فقدان الوصول الذاتي: فإذا فُقد مفتاح الإنتاج أو انتهت صلاحية الشهادة ولم يكن التثبيت الاحتياطي متاحًا، يفقد المستخدمون الوصول حتى إصدار تحديث للتطبيق، وقد يستغرق ذلك أيامًا أو أسابيع. وتشمل أفضل الممارسات: (1) تثبيت مفتاحين على الأقل دائمًا، هما المفتاح الحالي ومفتاح احتياطي مُنشأ مسبقًا ومخزّن دون اتصال (في HSM أو بيئة معزولة عن الشبكة). (2) تحديد تاريخ لانتهاء صلاحية التثبيت وإصدار تحديثات التطبيق قبل حلول ذلك التاريخ. (3) مراقبة حالات فشل التثبيت عبر وضع إعداد التقارير فقط قبل فرض التثبيت. (4) الحفاظ على مسار طوارئ لتحديث التطبيق (مع مراجعة مُعجّلة) للتعامل مع حوادث تدوير التثبيت. (5) إجراء التثبيت على مستوى CA الوسيطة، لا الشهادة الطرفية، للسماح بتدوير الشهادة الطرفية من دون تحديثات للتطبيق.

يمكن لتطبيقات سطح المكتب المكتوبة باستخدام Electron أو Qt أو الشفرة الأصلية تنفيذ تثبيت الشهادات باستخدام واجهات برمجة التطبيقات الخاصة بحزمة TLS. وتستخدم تطبيقات Electron الحدث app.on("certificate-error") والطريقة session.setCertificateVerifyProc() لتنفيذ تحقق مخصص. وتستخدم شِفرة الشبكة في Qt ‏QSslSocket مع رد نداء مخصص للتحقق. وتستخدم تطبيقات .NET ‏ServicePointManager.ServerCertificateValidationCallback. أما تطبيقات Windows الأصلية فتستخدم WinHTTP مع فحص يدوي للشهادة. وتواجه تطبيقات سطح المكتب تحديات إضافية؛ إذ إن اعتراض TLS على مستوى نظام التشغيل عبر الوكلاء المؤسسيين شائع، وقد يتوقع المستخدمون أن تعمل وظيفة الوكيل، ما يتطلب اتخاذ قرار بشأن ما إذا كان التثبيت ينطبق على نقاط نهاية معينة فقط.

يعقّد تثبيت الشهادات الاختبار الآلي ومسارات CI/CD. ويجب أن تستخدم اختبارات التكامل التي تجري اتصالات HTTPS فعلية بخوادم الاختبار شهادات اختبار تكون تجزئات SPKI الخاصة بها مثبتة في إعدادات الاختبار. وتشمل الأساليب: (1) نكهات البناء — يتضمن بناء debug/staging تثبيتات خادم الاختبار، بينما يثبت بناء release خادم الإنتاج. (2) تجاوزات Network Security Config — يسمح Android بإعداد تثبيت خاص بالتصحيح فقط. (3) خادم وهمي — الاعتراض على مستوى عميل HTTP قبل TLS، متجاوزًا التثبيت بالكامل. (4) CA موقعة ذاتيًا لـ CI — إصدار شهادات اختبار من CA خاصة بـ CI، بحيث تكون جذورها موثوقة في أبنية الاختبار فقط. لا تُصدر أبدًا بناءً يكون فيه التثبيت معطلًا في الإنتاج.

تكون تثبيتات الشهادات عادةً تجزئات لمفاتيح RSA أو EC العامة. وعند بدء الترحيل إلى تقنيات ما بعد الكم، ستنتقل الخوادم إلى ML-DSA (CRYSTALS-Dilithium) أو مفاتيح هجينة. وستتغير تجزئات SPKI المثبتة لأن نوع المفتاح وترميزه سيتغيران. وستحتاج التطبيقات التي تثبت الشهادات الطرفية أو المفاتيح العامة إلى تحديثات منسقة: (1) إصدار نسخة جديدة من التطبيق تتضمن تجزئة SPKI الخاصة بما بعد الكم كتثبيت احتياطي قبل ترحيل الخادم. (2) إكمال ترحيل الخادم. (3) إصدار تحديث يزيل التثبيت الكلاسيكي القديم. وتتطلب فترة الانتقال تنسيقًا دقيقًا. وستتأثر التطبيقات التي تثبت CA الوسيطة أو الجذرية بدرجة أقل؛ إذ سيتغير مفتاح CA فقط، وليس بالضرورة وفق الجدول الزمني نفسه للشهادات الطرفية.

لماذا يُفضَّل تثبيت تجزئة SubjectPublicKeyInfo ‏(SPKI) على تثبيت الشهادة الكاملة؟

يقيّد تثبيت الشهادة الثقة في TLS بشهادة أو مفتاح عام محدد، مما يحمي من اختراق سلطة الشهادات وهجمات MITM. ويُفضَّل تثبيت تجزئة SPKI ‏(SHA-256 لـ SubjectPublicKeyInfo) على تثبيت الشهادة الكاملة لأنه أكثر قدرة على تحمّل تجديد الشهادة. يستخدم Android ملف Network Security Config XML، بينما يستخدم iOS مفوَّض URLSession مع واجهات SecTrust API، ويدعم OkHttp الأداة CertificatePinner. احرصوا دائمًا على تضمين تثبيت احتياطي لتجنب فقدان الوصول إلى التطبيق. وقد أُهمل HPKP ‏(رأس HTTP في المتصفح). ويمكن تجاوز التثبيت باستخدام خطافات Frida وتعديلات ROM. ويتطلب الانتقال إلى مفاتيح ما بعد الكم تحديثات منسقة للتطبيق لتحديث تجزئات SPKI.