مقدمة لتفويض سلطة إصدار الشهادات (CAA)

لماذا استخدام CAA؟

يستخدم المرجع المصدق دائمًا أساليب التحقق من صحة المجال للتأكد من كل SSL /TLS يتم طلب طلب الشهادة (عادة عن طريق التأكد من أنه مرتبط بطريقة ما بموقع معين باستخدام هذا النطاق).

على سبيل المثال ، قد يقدم المرجع المصدق ملف تحقق خاصًا إلى الطالب. يثبت وضع هذا الملف على موقع الويب أن الطالب يتحكم أيضًا في هذا الموقع ، ولكنه لا يضمن ذلك شرعية من هذا التحكم. قد يتنكر المخترق الذي يتحكم في أحد المواقع باعتباره المالك الشرعي ، ويمكنه بعد ذلك طلب / استلام SSL /TLS شهادة اجتياز أي اختبارات CA القياسية وبالتالي يبدو شرعي. يمكنهم بعد ذلك الالتفاف واستخدام SSL /TLS شهادة الأذى ، في هذا الموقع أو في أي مكان آخر.

تساعد CAA في منع هذا النوع من الاستغلال من خلال تحديد CAs المسموح لها بإصدار الشهادات لمجال (أو حتى تقييد إصدار الشهادات تمامًا). هذا يحد من الضرر الذي يمكن أن يلحقه الخاطف - حتى إذا كان لديهم سيطرة على الموقع ، سيكون لديهم خيارات أقل بشكل كبير لتسجيل SSL /TLS شهادة.

كيف يعمل الجهاز المركزي للمحاسبات

يستخدم الجهاز المركزي للمحاسبات نظام أسماء النطاقات

• نظام اسم المجال (DNS) هو جزء حاسم من البنية التحتية للإنترنت. يحتفظ مالك أي مجال بسجلات DNS (داخل ما يسمى ب ملفات المنطقة) توجيه اسم المجال الخاص بهم إلى عنوان IP حيث تتم استضافة موقعهم ، ويتيح لنا الكتابة google.com في نافذة المتصفح بدلاً من 216.58.194.46.

تُستخدم سجلات DNS بشكل شائع كـ "دفتر هاتف للإنترنت" ، ولكن يسمح DNS أيضًا بأنواع أخرى من السجلات الخاصة التي يمكنها تعيين معلومات أخرى لاسم المجال.

سجلات الجهاز المركزي للمحاسبات

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

example.com. CAA 0 العدد "ssl.com"

هنا، example.com هو المجال الذي ينطبق عليه هذا السجل ، ويتيح لنا الجهاز المركزي للمحاسبات معرفة نوع هذا السجل. ال 0 هي العلم (الصفر هو الافتراضي - سنتحدث عن هذا أدناه). العلامة هي قضية والقيمة (بين علامتي الاقتباس) هي ssl.com، والتي تشكل معا الملكية.

الأعلام

تحتوي الأعلام حاليًا على حالتين محددتين بدقة: 0 (غير حرجة) و 1 (حرج). يخبرنا العلم الحاسم CA بذلك يجب فهم تماما علامة الخاصية للمتابعة. يترك RFC 6844 الاحتمالات الأخرى مفتوحة لاستخدام العلم المعرّف من قبل المستخدم (سنتحدث عن ذلك أدناه أيضًا).

علامات

يحدد RFC 6844 استخدام العلامات الثلاث الشائعة: قضية, اصدار و اليود. (كما هو الحال مع العلامات ، فإنه يسمح بأنواع علامات مخصصة محتملة أخرى.)

• قضية بطاقة

• قضية تحدد العلامة أي CA (إن وجد) مخول لإصدار شهادات لهذا المجال. على سبيل المثال ، يمكن لمالك المجال example.com تقييد إصدار الشهادة بمرجع مصدق واحد (هنا ، SSL.com) باستخدام ملف منطقة DNS التالي:

example.com. إصدار CAA 0 "ssl.com"

يمكن لمالك النطاق اختيار إعداد ملفات منطقة متعددة للمجال:

example.com. إصدار CAA 0 "ssl.com" example.com. إصدار CAA 0 "comodoca.com"

السجلات أعلاه تحد SSL /TLS إصدار شهادة example.com إلى اثنين من CAs (SSL.com و Comodo.com).

• قضية سجل أيضًا يخول المرجع المصدق المعين لإصدار شهادات لأي نطاقات فرعية للمجال المحدد. وبالتالي ، فإن السجل الذي يسمح لـ SSL.com يسمح بإصدار شهادات لـ example.com والنطاقات الفرعية مثل www.example.com, mail.example.com وحتى نطاق البدل الخاص * .example.com.

يمكن استخدام سجل CAA من أجل بتقييد إصدار الشهادة أيضًا - يخبر هذا السجل سلطات التصديق باستخدام CAA ذلك لا SSL /TLS يجب إصدار الشهادات example.com والنطاقات الفرعية بواسطة أي وقت CA:

example.com. إصدار CAA 0 "؛"

(تعني الفاصلة المنقوطة في هذا المثال "لا تسمح بأي شيء هنا"، ولكن كما سنوضح لاحقًا ، يتم استخدامه أيضًا لتحديد المعلمات المخصصة.)

لاحظ أن علامة الإصدار القياسية تسمح للمرجع المصدق بإصدار شهادة لحرف بدل ما لم يتم تعديله بواسطة ...

• اصدار بطاقة

تحدد هذه العلامة أن المرجع المصدق مرخص له بإصدار شهادات أحرف البدل لنطاق المالك (أي * .example.com).

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

example.com. إصدار CAA 0 "ssl.com" example.com. CAA 0 إصدار "؛"

ما سبق يسمح لـ SSL.com بإصدار شهادات لـ example.com وجميع النطاقات الفرعية إلا لحرف البدل * .example.com. (لا يُسمح لـ SSL.com أو أي مرجع مصدق آخر بإصدار شهادات بدل لـ example.com.)

example.com. إصدار CAA 0 "؛" example.com. CAA 0 issuewild "ssl.com"

يحظر هذا المثال من جميع المراجع المصدقة لإصدار الشهادات example.com ونطاقاته الفرعية ، ولكنه ينشئ استثناء للسماح لـ SSL.com بإصدار شهادات بدل (و فقط شهادات البدل) ل example.com.

• اليود بطاقة

العلامة المحددة الثالثة هي اليود. يمكن استخدام هذه العلامة للإبلاغ عن طلبات الشهادات غير الصالحة لمالك النطاق ، وتبدو على النحو التالي:

example.com. CAA 0 iodef "mailto: certissues@example.com" example.com. CAA 0 iodef "certissues.example.com"

يوفر السجل العلوي معلومات المرجع المصدق المطلوبة لإرسال إشعار بالبريد الإلكتروني إلى العنوان certissues@example.com. يوجه الثاني المرجع المصدق (CA) لنشر رسالة حادثة إلى خدمة ويب (تم إعدادها لهذا الغرض من قبل مالك المجال) في certissues.example.com. (يمكن استخدام أي من هاتين الطريقتين أو كلتيهما ، اعتمادًا على كيفية إعداد المرجع المصدق (CA) ومالك المجال لعملياتهما.)

اليود تستخدم الرسائل المشاركة تنسيق قياسي يسمى وصف كائن الحادث أو IODEF - ومن هنا جاء الاسم. (يتم تعريف IODEF في RFC 6546.)

العلامات والعلامات المعرفة بواسطة المرجع المصدق (CA)

CAA كما هو موضح في RFC 6844 يحدد فقط حالتين من علامات العلم (0 و 1) وثلاث علامات (قضية, اصدار و اليود). ومع ذلك ، فإنها تترك التصميم مفتوحًا بشكل كافٍ للمراجع المصدقة لإنشاء العلامات والعلامات المخصصة واستخدامها لتحديد عملية إصدار الشهادات الخاصة بهم. قد تكون الأمثلة:

example.com. إصدار CAA 0 "SSL.com ؛ policy = ev"

يستخدم هذا السجل معيارا قضية علامة بمعلمة إضافية توجه تعليمات CA إلى استخدام سياسة التحقق الموسع (EV) الخاصة بهم عند إصدار شهادة لهذا المجال.

example.com. CAA 128 pca "PCA = 12345"

يمكن لمالك النطاق استخدام هذا السجل مع مرجع مصدق جديد محدد PCA لإظهار أن لديهم حساب عميل مفضل وتعيين رقم الحساب كمعلمة. (يمكن أن تكون العلامة قيمة مخصصة تصل إلى 255.) اعتمادًا على كيفية إعداد المرجع المصدق للحساب ، فقد يسمح ذلك بطرق فوترة معينة أو تحقق إضافي محدد بواسطة الحساب أو معالجة خاصة أخرى.

إيجابيات وسلبيات

الإيجابيات ...

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

يعمل تصميم CAA على زيادة الأمان ولكنه يمكن أيضًا أن يسمح بتخصيص أكثر تفصيلاً للموارد - على سبيل المثال ، يمكن للشركة إعداد سجلات للسماح (أو الحد) من قسم المبيعات والتسويق لشراء شهادات SSL لـ sales.example.com من مصدر معين.

بالإضافة إلى ذلك ، يوفر CAA مرونة كبيرة. بالنسبة لمالك النطاق ، فإنه يستخدم سجلات موارد DNS التي تقع تحت سيطرتهم ويمكن تغييرها حسب الحاجة ، بحيث لا تكون مرتبطة بمرجع مصدق معين (ويمكن أن يكون لها أكثر من مرجع مصدق واحد مع سجلات المشاكل لأي اسم مجال معين) . بالنسبة إلى CAs ، حتى بصرف النظر عن الاستخدامات المخصصة ، يمكن للقواعد المعتمدة حديثًا من قبل CA / B Forum (المجموعة التي تحدد المعايير الخاصة بأمان CA والمستعرض) أن تسمح باستخدام سجلات CAA لأغراض التحقق ، مما يوفر سببًا جيدًا آخر لاستخدامها.

… وسلبيات

أكبر مشكلة مع CAA هي أنه لم يتم اعتمادها من قبل جميع CAA. تطلب المتطلبات الأساسية لمنتدى CA / B (والتي تفي بها جميع المراجع المصدقة الموثوقة) من المرجع المصدق تحديد الدرجة التي يدعم بها CAA في وثائقها عبر الإنترنت. حتى كتابة هذه السطور ، كان استخدام CAA فقط موصى به، غير مطلوب. لا يزال من الممكن استهداف سلطات الشهادات غير المتوافقة مع CAA ، وحتى يتم استخدام CAA على نطاق أوسع ، من المحتمل أن يتمكن الخاطف من العثور على CA غير متوافق على استعداد لإصدار شهادة مارقة.

من العيوب ذات الصلة أنه حتى عند وجود سجلات CAA ، لا يمكن للمستخدم فرض استخدامه من قبل سلطة تصديق. يجب أن يكون المرجع المصدق (CA) متوافقًا مع RFC 6844 حتى يتم التصرف وفقًا لتلك السجلات ، وقد يتجاهل المرجع المصدق غير المتوافق ببساطة رغبات مالك النطاق الصريحة كما هو معلن في سجلات CAA الخاصة بهم.

يجب أيضًا تكوين CAA بشكل صحيح من قبل كل من مالك المجال و CA. Let's Encrypt (الذي يدعم CAA) مؤخرًا أبلغ عن مشكلة بسيطة في قاعدة الرموز الخاصة بهم الأمر الذي أدى للأسف إلى تجاهل قواعد هيئة الطيران المدني وسوء إصدار ست شهادات. لم يكن أي من هذه الاستثناءات ضارة (وتنويه لفريق Let's Encrypt لحل المشكلة والإبلاغ عنها في غضون ساعات من الاكتشاف). ومع ذلك ، هذا يؤكد أن المرجع المصدق متوافق يجب تنفيذ الجهاز المركزي للمحاسبات لا تشوبه شائبة.

هناك مشكلة أخرى محتملة وهي اعتماد CAA على DNS. ما لم يؤمن مالك المجال خدمات اسمه ، يمكن أن يكون هذا متجهًا للهجوم. يقترح RFC 6844 التنفيذ ملحقات أمان نظام اسم المجال (DNSSEC)، الذي يستخدم سجلات DNS الموقعة رقميًا لمصادقة البيانات ومكافحة تهديد خداع DNS.

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

وفي الختام

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

مراجع حسابات

• RFC6844: سجل موارد ترخيص هيئة مصادقة DNS (CAA)
• RFC5070: صيغة تبادل وصف عنصر الحادثة
• RFC6546: نقل رسائل الدفاع بين الشبكات (RID) في الوقت الحقيقي عبر HTTP /TLS
• RFC4033: مقدمة ومتطلبات أمان DNS
• الاقتراع 125 لمنتدى CA / B - سجلات CAA
• إدخال ويكيبيديا حول تفويض سلطة إصدار شهادات DNS