المصادقة القائمة على DNS للكيانات المسماة

الموسوعة الحرة

بروتوكولات أمن الإنترنت
إدارة المفاتيح
طبقة التطبيق
نظام اسم النطاق
طبقة الانترنت
  • ف
  • ت
  • هـ

مصادقة الكيانات المسماة القائمة على DNS ( DANE ) هو بروتوكول أمان للإنترنت يسمح بربط الشهادات الرقمية X.509 ، المستخدمة عادةً لأمان طبقة النقل (TLS)، بأسماء النطاق باستخدام ملحقات أمان نظام اسم المجال ( DNSSEC ). [1]

تم اقتراحه في RFC  6698 كطريقة لمصادقة كيانات عميل وخادم TLS دون وجود هيئة شهادة ( CA ). وتم تحديثه بإرشادات التشغيل والنشر في RFC  7671. تم تعريف الاستخدام المحدد للتطبيق لـ DANE في RFC  7672 لـ SMTP و RFC  7673 لاستخدام DANE مع سجلات الخدمة (SRV) .

الأساس المنطقي

يعتمد تشفير TLS/SSL حاليًا على الشهادات الصادرة عن هيئات الشهادات (CAs). خلال السنوات القليلة الماضية [ متى؟ ] ، عانى عدد من موفري هيئات الشهادات من خروقات أمنية خطيرة ، مما سمح بإصدار شهادات للمجالات المعروفة لأولئك الذين لا يمتلكون هذه المجالات. قد تكون الثقة في عدد كبير من هيئات الشهادات مشكلة لأن أي هيئة شهادات مخترقة يمكنها إصدار شهادة لأي اسم مجال. يتيح DANE لمسؤول اسم المجال التصديق على المفاتيح المستخدمة في عملاء أو خوادم TLS لهذا المجال من خلال تخزينها في نظام اسم المجال (DNS). يحتاج DANE إلى توقيع سجلات DNS باستخدام DNSSEC لكي يعمل نموذج الأمان الخاص به.

بالإضافة إلى ذلك، يسمح DANE لمالك المجال بتحديد الجهة المصدرة للشهادات التي يُسمح لها بإصدار شهادات لمورد معين، وهو ما يحل مشكلة قدرة أي جهة مصدرة للشهادات على إصدار شهادات لأي مجال.

يحل برنامج DANE مشاكل مشابهة لما يلي:

شهادة الشفافية
ضمان عدم تمكن السلطات التصديقية المارقة من إصدار الشهادات دون إذن حامل المجال دون أن يتم اكتشافها
تفويض هيئة شهادة DNS
تحديد السلطات التصديقية التي يمكنها إصدار شهادات لنطاق معين

ومع ذلك، على عكس DANE، تحظى هذه التقنيات بدعم واسع من المتصفحات.

تشفير البريد الإلكتروني

حتى وقت قريب، لم يكن هناك معيار مطبق على نطاق واسع لنقل البريد الإلكتروني المشفر . [2] إرسال البريد الإلكتروني لا يعتمد على الأمان؛ لا يوجد مخطط URI لتعيين SMTP آمن. [3] وبالتالي، فإن معظم البريد الإلكتروني الذي يتم تسليمه عبر TLS يستخدم تشفيرًا انتهازيًا فقط . [4] نظرًا لأن DNSSEC يوفر إنكارًا موثقًا للوجود (يسمح للمحلل بالتحقق من عدم وجود اسم مجال معين)، فإن DANE يمكّن من الانتقال التدريجي إلى SMTP الموثق والمشفر دون أي آليات خارجية أخرى، كما هو موضح في RFC  7672. يشير سجل DANE إلى أن المرسل يجب أن يستخدم TLS. [3]

بالإضافة إلى ذلك، يوجد RFC  8162 لتطبيق DANE على S/MIME ، [5] ويقوم RFC  7929 بتوحيد معايير الارتباطات لـ OpenPGP . [6]

يدعم

التطبيقات

  • لا يدعم Google Chrome بروتوكول DANE، نظرًا لأن Google Chrome يرغب في التخلص من استخدام RSA بطول 1024 بت داخل المتصفح [7] (استخدم DNSSEC سابقًا جذرًا موقّعًا بـ RSA بطول 1024 بت، [8] ولا تزال العديد من المناطق موقَّعة بـ RSA بطول 1024 بت، على الرغم من أن الإعداد الافتراضي الحديث هو ECDSA بطول 256 بت [9] ). وفقًا لآدم لانجلي، تمت كتابة الكود [10] ، وعلى الرغم من أنه ليس موجودًا في Chrome اليوم، [11] إلا أنه لا يزال متاحًا في شكل إضافة. [12]
  • لا يدعم متصفح Mozilla Firefox تقنية DANE. استنادًا إلى ردود الأفعال الواردة في التذاكر حول الموضوعات ("ليس لدينا خطط لتطبيق هذه الميزة")، يرى مطورو Mozilla حاليًا أن DNSSEC وDANE خارج نطاق Firefox. [13] [14] كان دعم الإضافات متاحًا حتى Firefox 56 (آخر تحديث في عام 2016 [15] )، لكنه لم يعد موجودًا. لم يعد من الممكن تنفيذه باستخدام واجهات برمجة تطبيقات Firefox-extension الأحدث والأكثر تقييدًا. [16]
  • GNU Privacy Guard يسمح بجلب المفاتيح عبر OpenPGP DANE (--auto-key-locate). خيار جديد --export-options export-dane. (الإصدار 2.1.14) [17]
  • يتيح Cheogram Android التحقق عبر DANE ويظهر الحالة إذا تم استخدام DANE أم لا [18]

الخوادم

خدمات

المكتبات

TLSA RR

يقع سجل الموارد TLSA (RR) لخدمة ما في اسم DNS الذي يحدد قيود الشهادة التي يجب تطبيقها على الخدمات عند منفذ TCP أو UDP معين. يجب أن يوفر سجل الموارد TLSA واحد على الأقل التحقق من صحة (مسار) الشهادة التي تقدمها الخدمة عند العنوان المحدد.

لا تتعامل جميع البروتوكولات مع مطابقة الاسم الشائع بنفس الطريقة. يتطلب HTTP أن يتطابق الاسم الشائع في شهادة X.509 التي توفرها الخدمة بغض النظر عن تأكيد TLSA على صحتها. لا يتطلب SMTP تطابق الاسم الشائع، إذا كانت قيمة استخدام الشهادة 3 (DANE-EE)، ولكن بخلاف ذلك يتطلب تطابق الاسم الشائع. من المهم التحقق مما إذا كانت هناك تعليمات محددة للبروتوكول المستخدم.

حقول بيانات RR

يحتوي RR نفسه على 4 حقول من البيانات، تصف مستوى التحقق الذي يوفره مالك المجال.

  • حقل استخدام الشهادة
  • حقل الاختيار
  • حقل النوع المطابق
  • بيانات جمعية الشهادة

مثلا_25._tcp.somehost.example.com. TLSA 3 1 1 0123456789ABCDEF

استخدام الشهادة

قيمة استخدام الشهادة

التحقق من صحة مسار PKIX		 هدف RR
مرساة الثقة الكيان النهائي
مطلوب 0 1
ليس مطلوبا 2 3

يحدد الحقل الأول بعد نص TLSA في DNS RR كيفية التحقق من الشهادة.

  • القيمة 0 هي لما يسمى عادة بقيد CA (وPKIX-TA). يجب أن تكون الشهادة المقدمة عند إنشاء TLS صادرة عن سلطة التصديق الجذرية المدرجة أو إحدى سلطات التصديق الوسيطة التابعة لها، مع مسار شهادة صالح لسلطة التصديق الجذرية التي يثق بها التطبيق الذي يقوم بالتحقق. قد يشير السجل فقط إلى سلطة تصديق وسيطة، وفي هذه الحالة يجب أن تأتي الشهادة لهذه الخدمة عبر هذه السلطة، ولكن يجب أن تظل السلسلة بأكملها لسلطة التصديق الجذرية الموثوقة صالحة. [أ]
  • القيمة 1 هي ما يسمى عادةً بقيد شهادة الخدمة (وPKIX-EE). يجب أن تتطابق الشهادة المستخدمة مع سجل TLSA، ويجب أن تجتاز أيضًا عملية التحقق من صحة مسار شهادة PKIX إلى سلطة إصدار الشهادات الجذرية الموثوقة.
  • القيمة 2 هي ما يسمى عادةً بتأكيد مرساة الثقة (وDANE-TA). يتطابق سجل TLSA مع شهادة سلطة التصديق الجذرية، أو إحدى سلطات التصديق الوسيطة، للشهادة المستخدمة بواسطة الخدمة. يجب أن يكون مسار الشهادة صالحًا حتى الشهادة المطابقة، ولكن ليست هناك حاجة إلى سلطة تصديق جذرية موثوقة.
  • القيمة 3 هي ما يسمى عادةً بالشهادة الصادرة عن المجال (وDANE-EE). يتطابق سجل TLSA مع الشهادة المستخدمة نفسها. لا يلزم توقيع الشهادة المستخدمة من قبل أطراف أخرى. وهذا مفيد للشهادات الموقعة ذاتيًا، ولكن أيضًا في الحالات التي لا يمتلك فيها المحقق قائمة بشهادات الجذر الموثوقة.

محدد

عند الاتصال بالخدمة وتلقي شهادة، يحدد حقل المحدد الأجزاء التي يجب التحقق منها.

  • تعني القيمة 0 تحديد الشهادة بأكملها للمطابقة.
  • تعني القيمة 1 تحديد المفتاح العام فقط لمطابقة الشهادة. غالبًا ما تكون مطابقة المفتاح العام كافية، حيث من المرجح أن يكون فريدًا.

نوع المطابقة

  • يشير النوع 0 إلى أن كافة المعلومات المحددة موجودة في بيانات ارتباط الشهادة.
  • نوع 1 يعني إجراء تجزئة SHA-256 للبيانات المحددة.
  • نوع 2 يعني إجراء تجزئة SHA-512 للبيانات المحددة.

بيانات ارتباط الشهادة

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

أمثلة

يحدد سجل TLSA الخاص بـ www.ietf.org التحقق من تجزئة SHA-256 للمفتاح العام للشهادة المقدمة، مع تجاهل أي سلطة اعتماد. 

_443._tcp.www.ietf.org. تلسا 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6

تتمتع خدمة البريد الخاصة بهم بنفس الشهادة و TLSA. 

ietf.org. MX 0 mail.ietf.org. _25._tcp.mail.ietf.org. تلسا 3 1 1 0C72AC70B745AC19998811B131D662C9AC69DBDBE7CB23E5B514B56664C5D3D6

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

_25._tcp.mail.alice.example. TLSA 3 0 1 AB9BEB9919729F3239AF08214C1EF6CCA52D2DBAE788BB5BE834C13911292ED9

المعايير

  •  حالات الاستخدام ومتطلبات RFC 6394 للمصادقة القائمة على DNS للكيانات المسماة (DANE)
  • RFC  6698 بروتوكول مصادقة الكيانات المسماة المستندة إلى DNS (DANE) وبروتوكول أمان طبقة النقل (TLS): TLSA
  • RFC  7218 إضافة اختصارات لتبسيط المحادثات حول المصادقة القائمة على DNS للكيانات المسماة (DANE)
  • RFC  7671 بروتوكول المصادقة المستندة إلى DNS للكيانات المسماة (DANE): التحديثات والإرشادات التشغيلية
  • RFC  7672 أمان SMTP عبر المصادقة الانتهازية القائمة على DNS للكيانات المسماة (DANE) أمان طبقة النقل (TLS)
  • RFC  7673 استخدام سجلات TLSA للمصادقة القائمة على DNS للكيانات المسماة (DANE) مع سجلات SRV
  •  ارتباطات المصادقة القائمة على DNS للكيانات المسماة (DANE) وفقًا لـ RFC 7929 لـ OpenPGP
  • RFC  4255 استخدام DNS لنشر بصمات مفاتيح Secure Shell (SSH) بشكل آمن
  • RFC  8162 استخدام DNS الآمن لربط الشهادات بأسماء النطاقات لـ S/MIME
  • مسودة: التشفير الانتهازي باستخدام دلالات DANE وIPsec: IPSECA [27]

انظر أيضا

ملحوظات

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

مراجع

  1. ^ صمد، محمد عليف أدها بن (6 أكتوبر 2011). "DANE: نقل مصادقة TLS إلى المستوى التالي باستخدام DNSSEC". مجلة IETF . تم الاسترجاع في 5 أغسطس 2018 .
  2. ^ "دعم Postfix TLS - التحقق من شهادة الخادم الآمنة". Postfix.org . تم الاسترجاع في 2015-12-30 .
  3. ^ ab Dukhovni; Hardaker (2013-07-28). DANE for SMTP (PDF) . IETF 87 Proceedings. IETF.
  4. ^ فيليبو فالسوردا (2015-03-31). "الحالة المحزنة لتشفير SMTP" . تم الاسترجاع في 2015-12-30 .
  5. ^ Hoffman, P. (مايو 2017). استخدام DNS الآمن لربط الشهادات بأسماء النطاقات لـ S/MIME. IETF . doi : 10.17487/RFC8162 . RFC 8162 . تم الاسترجاع في 2022-03-30 .
  6. ^ Wouters, P. (أغسطس 2016). ارتباطات المصادقة القائمة على DNS للكيانات المسماة (DANE) لـ OpenPGP. IETF . doi : 10.17487/RFC7929 . RFC 7929 . تم الاسترجاع في 2016-09-14 .
  7. ^ Langley, Adam (2015-01-17). "ImperialViolet - Why not DANE in browsers". www.imperialviolet.org . تم الاسترجاع في 2017-03-24 .[ المصدر منشور ذاتيًا ]
  8. ^ Duane Wessels, Verisign (2016-05-16). "زيادة مفتاح توقيع منطقة القوة لمنطقة الجذر". Verisign.com . تم الاسترجاع في 2016-12-29 .
  9. ^ "دليل Bind9 DNSSEC". bind9.readthedocs.io . تم الاسترجاع في 2021-08-22 .
  10. ^ آدم لانجلي (2012-10-20). "DANE شهادات مدبسة". ImperialViolet . تم الاسترجاع في 2014-04-16 .[ المصدر منشور ذاتيًا ]
  11. ^ Adam Langley (2011-06-16). "بروتوكول HTTPS المعتمد على DNSSEC في Chrome". ImperialViolet . تم الاسترجاع في 2014-04-16 .[ المصدر منشور ذاتيًا ]
  12. ^ كيفية إضافة دعم DNSSEC إلى Google Chrome
  13. ^ "672600 - استخدام سلسلة DNSSEC/DANE المدمجة في مصافحة TLS في التحقق من صحة سلسلة الشهادات".
  14. ^ "1479423 - دعم للتحقق من صحة DNSSEC/DANE/TLSA".
  15. ^ ويبر، يوهانس (25 أكتوبر 2016). "كيفية استخدام DANE/TLSA". Weberblog.net .
  16. ^ مُحقق DNSSEC/TLSA
  17. ^ "GnuPG - ملاحظات الإصدار". gnupg.org. 12 يونيو 2021. تم الاسترجاع في 2021-08-27 .[ المصدر منشور ذاتيًا ]
  18. ^ "cheogram-android 2.13.0-1" . تم الاسترجاع في 2021-02-11 .
  19. ^ "Postfix TLS Support - DANE". Postfix.org . تم الاسترجاع في 2014-04-16 .
  20. ^ "إصدار PowerMTA 5.0". SparkPost.com . تم الاسترجاع في 2020-04-26 .
  21. ^ "Exim 4.91 spec: Encrypted SMTP connections using TLS/SSL / 15. DANE". exim.org . تم الاسترجاع في 2018-07-05 .
  22. ^ "mod_s2s_auth_dane_in". prosody.im . تم الاسترجاع في 2024-02-11 .
  23. ^ Scaturro, Michael (2014-08-24). "Protect your email the German way". The Guardian . تم الاسترجاع في 2018-04-29 . ... في مايو الماضي، أصبحت [Posteo] أول مزود بريد إلكتروني في العالم يتبنى مصادقة الكيانات المسماة القائمة على DNS (Dane) على خوادمها. ...
  24. ^ DANE في كل مكان؟! دعونا نجعل الإنترنت مكانًا خاصًا مرة أخرى، tutanota.de ، تم الاسترجاع في 2015-12-17[ المصدر منشور ذاتيًا ]
  25. ^ ريتشارد ليفيت (2016-01-07). "DANE CHANGES". GitHub . تم الاسترجاع في 2016-01-13 .[ المصدر منشور ذاتيًا ]
  26. ^ "التحقق من الشهادة باستخدام DANE (DNSSEC)". Gnu.org.[ المصدر منشور ذاتيًا ]
  27. ^ أوسترويل، إيريك؛ وايلي، جلين؛ أوكوبو، توموفومي؛ لافو، رامانا؛ موهايسن، عزيز (6 يوليو 2015). "التشفير الانتهازي باستخدام دلالات DANE وIPsec: IPSECA". فريق عمل هندسة الإنترنت .
  • DNSSEC غير ضروري - ضد DNSSEC
  • من أجل DNSSEC - رد على النقاط الواردة في "ضد DNSSEC"
  • قائمة مواقع اختبار DANE
  • أداة عبر الإنترنت للتحقق من خوادم البريد الإلكتروني بحثًا عن دعم DNSSEC وDANE
  • صور توضيحية لدعاية DANE مع روابط لكيفية القيام بذلك والأدوات
تم الاسترجاع من "https://en.wikipedia.org/w/index.php?title=المصادقة القائمة على DNS للكيانات المسماة&oldid=1231360674#TLSA_RR"
Original text
Rate this translation
Your feedback will be used to help improve Google Translate