الخلاصة

  • يُشتق عنوان Onion بالإصدار الثالث من مفتاح الهوية العام للخدمة، لا من تفويض DNS؛ لذلك لا تكفي قابلية الوصول ولا صلاحية حساب ACME لإثبات السيطرة على الاسم.
  • يضيف onion-csr-01 طلب توقيع خاصاً للتحقق، موقعاً بمفتاح هوية Onion ومرتبطاً بقيمتين عشوائيتين، مع وجوب اختلاف مفتاحه عن مفتاح الطلب النهائي.
  • يمكن تقديم CAA داخل الواصف المشفر أو كسجل مؤقت موقع داخل طلب الإنهاء، بينما يبقى مسار Tor والتحويل إلى الويب العام وسجلات الشفافية قرارات خصوصية منفصلة.

دفتران قبل الوصول إلى الشهادة

هناك دفتر صلاحية ودفتر كشف. يسأل الأول: هل يسيطر صاحب الطلب على المفتاح الذي أنشأ اسم Onion، وهل تسمح سياسة CAA لسلطة التصديق بالإصدار؟ ويسأل الثاني: من عرف بوجود الخدمة، وأي بنية تحتية ظهرت، وهل أصبح الاسم عاماً في سجلات شفافية الشهادات؟ لا تلغي إجابة صحيحة في الدفتر الأول ما كُتب في الثاني.

يبدأ الفرق من بنية الاسم. يضع RFC 7686 النطاق .onion خارج DNS التقليدي. وفي صيغة Tor v3، يضم العنوان مفتاح الهوية العام Ed25519 ومجموع تحقق ورقم الإصدار. يستعمل RFC 9799 نوع المعرّف dns في ACME للتوافق، لكنه لا ينقل معه سلطة مسجل أو سلسلة تفويض DNS.

لهذا يُحظر dns-01. ويمكن استخدام http-01 وtls-alpn-01 بعد تعديل طريقة الاتصال؛ على سلطة التصديق أن تصل بنفسها عبر Tor وألا تعتمد على Tor2Web. يثبت هذان الأسلوبان وجود استجابة في موضع معين، ولا يدعمان الشهادات ذات البدل، ولا يفرضان توقيع مفتاح الهوية نفسه.

أما onion-csr-01 فيطلب من ذلك المفتاح أن يتكلم. ترسل سلطة التصديق nonce لا يقل عن 64 بت من العشوائية، ويجب رفض الرد إذا كان قد مضى على إنشاء هذه القيمة أكثر من ثلاثين يوماً. ينشئ العميل CSR للتحقق، ويضع البايتات الأصلية في caSigningNonce، ويضيف applicantSigningNonce مستقلاً بالمقدار نفسه من العشوائية، ثم يوقع بمفتاح Onion الخاص.

تتحقق السلطة من بنية PKCS#10، ومن ارتباط المفتاح العام بالاسم، وصحة التوقيع، وتطابق nonce الصادر عنها، ووجود عشوائية المتقدم. لا تحمل خانة subject معنى إثباتياً ولا يجوز اعتمادها. كما يجب أن يختلف المفتاح العام في هذا الطلب عن المفتاح الموجود في CSR النهائي.

وهكذا تبقى الأدوار واضحة: مفتاح حساب ACME يصادق رسائل البروتوكول، ومفتاح Onion يثبت السيطرة على الاسم، والمفتاح النهائي يستقبل الشهادة. ولا يحتاج التحدي إلى key authorization المعتاد لأن الإثبات ينتقل أصلاً داخل طلب ACME موقع بالحساب.

منح الرؤية لسلطة التصديق له أثر خصوصية

في الاكتشاف المقيّد، لا يستطيع إلا العملاء المخولون فك الطبقة الداخلية من واصف الخدمة. قد تصل سلطة التصديق إلى التطبيق ولا ترى سياسة CAA. لذلك يمكن للتحدي أن يعلن authKey، وهو مفتاح Ed25519 العام الذي ستستخدمه السلطة للوصول.

يحظر استعمال المفتاح نفسه مع خدمات Onion مختلفة، وإن جاز استعماله عند إعادة التحقق من الخدمة ذاتها. يمنع ذلك أن يتحول مفتاح الوصول إلى معرف يجمع خدمات أراد المشغل فصلها.

تحسب السلطة CLIENT-ID وتبحث عن سطر auth-client مطابق. لا توجد إشارة مستقلة تقول إن المصادقة مطلوبة؛ إذا لم تجد تطابقاً فعليها افتراض أنها غير مطلوبة. وإذا كان المفتاح جديداً، يضيفه المشغل ويعيد توقيع الواصف ونشره.

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

سلطة الإصدار في مكانين محتملين

توجد سجلات CAA بصيغة RFC 8659 في الطبقة الثانية المشفرة. لا صعود في شجرة DNS ولا فحص لنطاق .onion أعلى، وتشترك النطاقات الفرعية تحت عنوان Onion أساسي واحد في السياسة ذاتها.

يمكن وضع caa-critical في الطبقة الأولى. تكشف الإشارة وجود سياسة من دون كشف محتواها، وتمنع الإصدار حتى تفك السلطة الطبقة الثانية وتقرأها. هي إشارة توقف، وليست إيصالاً بأن الفحص نجح.

والبديل هو onionCAA داخل طلب الإنهاء. يقدم العميل نص CAA أو null، ووقت انتهاء Unix ينبغي ألا يتجاوز ثماني ساعات، وتوقيع Ed25519 بمفتاح هوية Onion. يغطي التوقيع تسلسلاً دقيقاً: onion-caa|، ثم وقت الانتهاء عشرياً بلا أصفار بادئة، ثم |، ثم نص CAA؛ وتصبح null نصاً فارغاً.

يمكن للسلطة الاعتماد على المجموعة الموقعة وحدها، أو تجاهلها وجلب الواصف، أو فحص الاثنين. وإذا لم تستطع جلب CAA من الواصف وغاب الكائن، تعيد onionCAARequired، ويمكن لـinBandOnionCAARequired إعلان الشرط مسبقاً.

نجاح التوقيع لا يبين أي مسار اختارته السلطة. يجب أن يسجل التدقيق مصدر البايتات الفعلي، وبصمتها، وموعد انتهائها، وقرار السياسة. أدلة Tor نفسها جهات توزيع غير موثوقة؛ في المسارين تعود السلطة إلى مفتاح الهوية نفسه.

فاتورة الكشف لا تختفي عند نجاح الإصدار

على سلطة التصديق أن تتصل بالخدمة عبر Tor بنفسها. وينبغي لعميل ACME أيضاً استخدام Tor وتفضيل نقطة Onion للسلطة إذا توفرت. الاتصال المباشر بعنوان معروف لسلطة تصديق قد يكشف أن الجهاز الطالب يشغل خدمة Onion.

قد يحول http-01 إلى نطاق عام، فيظهر عنوان IP أو ارتباط في الاستضافة. ولا يجوز للسلطة التحقق من الهدف العام عبر مخرج Tor بسبب خطر اختطاف المخرج. حماية الخصوصية وسلامة التحقق لا تستخدمان دائماً المسار الشبكي نفسه.

أما الشهادة العامة ضمن WebPKI فتسجل اسم Onion في Certificate Transparency. قد يكون ذلك ثمناً مقبولاً لثقة المتصفح، لكنه إعلان دائم. للخدمات غير العامة بدائل خاصة أو ذاتية التوقيع. ويوصي RFC بتقليل بيانات المشترك، ويفرض حسابات ACME منفصلة إذا أراد المشغل منع السلطة من ربط خدمات مختلفة.

لهذا لا تكفي عبارة «صدرت الشهادة». السجل المسؤول يجمع مفتاح الاسم، والحساب، وإثبات nonce، ومنحة الوصول الخاصة بالخدمة، ومصدر CAA المختار، والمفتاح النهائي، وكل كشف وافق عليه المشغل. البروتوكول يوحد طريقة الانتقال؛ ولا يمنح النتيجة الأخيرة حق محو القرارات السابقة.

المصادر