Letencrypt के बजाय DNS-record के माध्यम से स्व-हस्ताक्षरित प्रमाणपत्रों को मान्य क्यों नहीं किया गया

Question

मैं बस सोच रहा था। हम बहुत सारे SSL प्रमाणपत्र का उपयोग करते हैं। आजकल, हम लगभग विशेष रूप से letencrypt (धन्यवाद!) का उपयोग करते हैं। इन प्रमाणपत्रों की निचली रेखा यह है कि प्रमाण पत्र पर डोमेन नाम (ओं) के स्वामित्व का प्रमाण इन डोमेन के तहत DNS रिकॉर्ड या वेबसाइट में हेरफेर करने की शक्ति से आता है। DNS प्रमाण DNS में TXT रिकॉर्ड के रूप में कुछ कुंजी (Letencrypt द्वारा दिए गए) जोड़ने से आता है।

तो, यदि यह एक डोमेन के लिए DNS रिकॉर्ड को बदलने में सक्षम होने के लिए पर्याप्त प्रमाण है, तो DNS में फिंगरप्रिंट के साथ स्व हस्ताक्षरित प्रमाण पत्र का उपयोग क्यों न करें?

मैं कहूंगा कि यह बिल्कुल वैसा ही विश्वास देता है जैसा कि letencrypt (और अन्य CA के) की DNS आधारित प्रक्रिया:

1. एक स्व-हस्ताक्षरित CA बनाएं (बस विभिन्न के चरणों का पालन कैसे करें)
2. कुछ डोमेन के लिए एक प्रमाण पत्र बनाएँ
3. चरण 1 से सीए के साथ चरण 2 से प्रमाण पत्र पर हस्ताक्षर करें। अब आपके पास एक मूल प्रमाण पत्र है, जिस पर एक गैर विश्वसनीय सीए द्वारा हस्ताक्षर किए गए हैं
4. प्रत्येक डोमेन के DNS में TXT (या समर्पित) रिकॉर्ड जोड़ें, बताते हुए: हमने इस CA के साथ इस डोमेन के प्रमाण पत्र पर हस्ताक्षर किए हैं। जैसे: 'CA = -fingerpint of CA-'
5. एक ब्राउज़र प्रमाणपत्र को डाउनलोड करता है और दिए गए डोमेन के लिए DNS में डेटा के साथ CA / CA प्रमाणपत्र के फिंगरप्रिंट की तुलना करके इसे सत्यापित करता है।

यह तीसरे पक्ष के हस्तक्षेप के बिना किसी भी बुनियादी एसएसएल प्रमाणपत्र के समान विश्वास स्तर के बिना विश्वसनीय स्व-हस्ताक्षरित प्रमाण पत्र बनाना संभव होगा। जब तक आपके पास DNS का उपयोग होता है, तब तक आपका प्रमाणपत्र मान्य होता है। कोई भी डीएनएसएसईसी जैसे एन्क्रिप्शन को भी जोड़ सकता है, सीए प्लस के एसओए रिकॉर्ड से एक हैश बनाने के लिए, यह सुनिश्चित करने के लिए कि डीएनएस रिकॉर्ड में बदलाव पर भरोसा गायब हो जाता है।

क्या इस पर पहले विचार किया गया है?

Jelmer

Comments

प्रासंगिक: tools.ietf.org/html/rfc6698

— Håkan Lindqvist

धन्यवाद हाकन! एक अद्यतन के माध्यम से, मुझे इस RFC के लिए DANE शब्द मिला। RFC का अंतिम संस्करण: tools.ietf.org/html/rfc7671 यह भी देखें: en.wikipedia.org/wiki/… (मैं इसे बाद में पढ़ूंगा )।

— जेलर जेल्मा

"क्यों नहीं" भी RFC Håkan से जुड़ा हुआ है: डीएनएसएसईसी के बिना, डीएनएस से निहित कमजोरियों के कारण पूरे मॉडल की विश्वसनीयता से समझौता किया जाता है। यह भी ध्यान दिया जाना चाहिए कि DNSSEC ग्राहकों और पुनरावर्ती प्रणालियों के बीच यातायात को सुरक्षित करने के लिए कुछ भी नहीं करता है, जो मध्य स्पूफिंग में आदमी के लिए अतिसंवेदनशील रहता है।

— एंड्रयू बी

एंड्रयू, मैं DNSSEC और MIDM के साथ समस्या को देखता हूं, जब DNSSEC को एक डोमेन के लिए मजबूर नहीं किया जाता है, और मजबूर केवल तभी किया जा सकता है जब प्रत्येक और प्रत्येक लुकअप को tld के लिए रूट डोमेन सर्वर की जाँच करके किया जाता है। तो समस्या यह है: हम कुछ DV-प्रमाण पत्र के उपयोग को अधिकृत करना चाहते हैं मालिक की स्थिति इसकी वैधता है, लेकिन हम इसे श्रेणीबद्ध प्रकृति के कारण DNS पर भरोसा नहीं कर सकते। तथ्य यह है कि DNS स्पूफिंग के लिए अवर्णनीय है और MIDM- अटैक डीवी प्रमाणपत्र को एक डोमेन प्रविष्टि के बाहरी सत्यापन की तरह बनाता है। हम्म, मैं

— सोचता रहूँगा

Crossdupe security.stackexchange.com/questions/68504/… (2014) security.stackexchange.com/questions/23648/… (2012) security.stackexchange.com/questions/6824/… (2011)

— dave_thompson_085

Answer 1

बुनियादी ढांचा, जो इसे संभव बनाता है, मौजूद है और इसे नामांकित संस्थाओं ( डीएएनई ) का DNS- आधारित प्रमाणीकरण कहा जाता है और RFC6698 में निर्दिष्ट किया जाता है । यह एक TLSAसंसाधन रिकॉर्ड के माध्यम से काम करता है , जो प्रमाण पत्र या अंतिम इकाई की सार्वजनिक कुंजी या श्रृंखला में इसके सीए में से एक को निर्दिष्ट करता है (वास्तव में चार अलग-अलग प्रकार हैं, विवरण के लिए आरएफसी देखें)।

दत्तक ग्रहण

DANE ने हालांकि व्यापक रूप से अभी तक गोद नहीं लिया है। VeriSign पर नज़र रखता है DNSSEC और डेन गोद लेने और समय के साथ इसके विकास पटरियों :

तुलना के लिए, वेरिसाइन के अनुसार, लगभग 2.7 मिलियन DNS ज़ोन मौजूद हैं, इसलिए इसका मतलब है कि सभी ज़ोन के 1% से अधिक का कम से कम एक TLSA रिकॉर्ड है।

मैं कोई आधिकारिक जवाब नहीं दे सकता, DANE क्यों, लेकिन यहाँ मेरी अटकलें हैं:

DANE सर्टिफिकेशन रेवोकेशन लिस्ट्स (CRLs) और ऑनलाइन सर्टिफिकेट स्टेटस प्रोटोकॉल (OCSP) जैसी ही समस्या से ग्रस्त है। प्रस्तुत प्रमाण पत्र की वैधता को सत्यापित करने के लिए, किसी तीसरे पक्ष से संपर्क करना होगा। हनो बोक एक अच्छा अवलोकन देता है , क्यों यह व्यवहार में एक बड़ी समस्या है। जब आप तीसरे पक्ष तक नहीं पहुंच सकते, तो यह क्या करना है, इस मुद्दे पर उबलता है। ब्राउज़र विक्रेताओं ने इस मामले में नरम-विफल (उर्फ परमिट) का विकल्प चुना , जिसने पूरी बात को व्यर्थ कर दिया और क्रोम ने अंततः 2012 में OCSP को अक्षम करने का फैसला किया।

DNSSEC

संभवतः DNS सीए के CRL और OCSP सर्वरों की तुलना में बहुत बेहतर उपलब्धता प्रदान करता है, लेकिन यह अभी भी ऑफ़लाइन सत्यापन को असंभव बनाता है। DANE के अलावा, केवल DNSSEC के साथ संयोजन में उपयोग किया जाना चाहिए। जैसा कि सामान्य डीएनएस अनधिकृत यूडीपी पर काम करता है, यह जालसाजी, एमआईटीएम हमलों आदि के लिए काफी प्रवण है। डीएनएसएसईसी का गोद लेना डीएएनई के गोद लेने की तुलना में बहुत बेहतर है, लेकिन अभी भी सर्वव्यापी से बहुत दूर है।

और DNSSEC के साथ हम फिर से सॉफ्ट-फेल समस्या में दौड़ते हैं। मेरे ज्ञान का सबसे अच्छा करने के लिए कोई प्रमुख सर्वर / क्लाइंट ऑपरेटिंग सिस्टम डिफ़ॉल्ट रूप से एक मान्य DNSSEC रिज़ॉल्वर प्रदान करता है।

फिर निरसन का मुद्दा भी है। DNSSEC में कोई निरसन तंत्र नहीं है और इसके बजाय अल्पकालिक कुंजियों पर निर्भर करता है।

सॉफ्टवेयर का समर्थन

सभी भाग लेने वाले सॉफ़्टवेयर को DANE समर्थन को लागू करना होगा।

सिद्धांत रूप में, आप सोच सकते हैं, कि यह क्रिप्टो लाइब्रेरी का काम होगा और एप्लिकेशन डेवलपर्स को बहुत कुछ नहीं करना होगा, लेकिन तथ्य यह है कि क्रिप्टोग्राफिक लाइब्रेरी आमतौर पर केवल प्रिमिटिव प्रदान करते हैं और एप्लिकेशन को बहुत सारे कॉन्फ़िगरेशन और सेटअप खुद करने होते हैं (और दुर्भाग्य से चीजों को गलत करने के कई तरीके हैं)।

मुझे पता नहीं है, उदाहरण के लिए किसी भी बड़े वेब सर्वर (जैसे Apache या nginx) ने DANE को लागू किया है या करने की योजना है। वेब सर्वर यहां विशेष महत्व रखते हैं, क्योंकि अधिक से अधिक सामान वेब प्रौद्योगिकियों पर निर्मित होते हैं और इसलिए वे अक्सर पहले होते हैं, जहां चीजें लागू होती हैं।

जब हम CRL, OCSP और OCSP स्टेपलिंग को तुलना के रूप में देखते हैं, तो हम अनुमान लगा सकते हैं कि DANE की गोद लेने की कहानी कैसी होगी। केवल कुछ एप्लिकेशन, जो OpenSSL, लिबास, GnuTLS आदि का उपयोग करते हैं, इन सुविधाओं का समर्थन करते हैं। अपाचे या नगनेक्स जैसे बड़े सॉफ्टवेयर को इसे सपोर्ट करने में कुछ समय लगा और फिर से हैनो बोके के लेख का जिक्र करते हुए उन्होंने इसे गलत बताया और उनका कार्यान्वयन त्रुटिपूर्ण है। अन्य प्रमुख सॉफ़्टवेयर प्रोजेक्ट्स, जैसे Postfix या Dovecot OCSP का समर्थन नहीं करते हैंऔर बहुत सीमित सीआरएल कार्यक्षमता है, मूल रूप से फ़ाइल सिस्टम में एक फ़ाइल की ओर इशारा करते हुए (जो जरूरी नहीं कि नियामक फिर से पढ़ा जाए, इसलिए आपको अपने सर्वर को मैन्युअल रूप से पुनः लोड करना होगा)। ध्यान रखें कि ये परियोजनाएं हैं, जो अक्सर टीएलएस का उपयोग करती हैं। फिर आप चीजों को देखना शुरू कर सकते हैं, जहां टीएलएस बहुत कम आम है, उदाहरण के लिए पोस्टग्रेक्यूएल / मायक्यूएल और शायद वे सीआरएल को सबसे अच्छे रूप में पेश करते हैं।

इसलिए मैंने आधुनिक वेब सर्वरों को भी लागू नहीं किया है और OCSP और CRL को लागू करने के लिए अन्य सॉफ्टवेयर भी नहीं मिला है, जो आपके 5 साल के एंटरप्राइज एप्लिकेशन या अप्लायंसेज के लिए सौभाग्य है।

संभावित अनुप्रयोग

तो आप वास्तव में डेन का उपयोग कहां कर सकते हैं? अब तक, सामान्य इंटरनेट पर नहीं। यदि आप सर्वर और क्लाइंट को नियंत्रित करते हैं, तो शायद यह एक विकल्प है, लेकिन इस मामले में, आप अक्सर पब्लिक-की पिनिंग का सहारा ले सकते हैं।

मेल स्पेस में, DANE को कुछ कर्षण मिल रहा है, क्योंकि SMTP में सबसे लंबे समय तक किसी भी प्रकार का प्रमाणित परिवहन एन्क्रिप्शन नहीं था। एसएमटीपी सर्वरों ने कभी-कभी एक-दूसरे के बीच टीएलएस का उपयोग किया था, लेकिन यह सत्यापित नहीं किया कि प्रमाणपत्रों में नाम वास्तव में मेल खाते हैं, वे अब डेन के माध्यम से यह जांचना शुरू कर रहे हैं।

Comments

मुझे लगता है कि आपका आखिरी वाक्य कट गया।

— 8bittree

धन्यवाद सेबस्टियन, आपकी प्रतिक्रिया बहुत मददगार है। कृपया ओपी के तहत मेरी और एंड्रयू की टिप्पणियों को देखें।

— जैलमेर जेलेमा

इसे लागू करने के लिए वेब सर्वरों की आवश्यकता क्यों है? मैं अपाचे कॉन्फिगर में स्व हस्ताक्षरित प्रमाण पत्र जोड़ सकता हूं और फिंगरप्रिंट को डीएनएस में डाल सकता हूं, है ना?

— जैलमेर जेलेमा

DNSSEC बनाम DNS के साथ प्रदर्शन और मापनीयता की समस्याएं भी हैं: सादे DNS "डिब्बाबंद" प्रतिक्रियाओं का उपयोग कर सकते हैं, लेकिन DNSSEC को हर अनुरोध के लिए क्रिप्टोडेंस करना पड़ता है, और DNS अनुरोधों का एक बहुत कुछ होता है। जैसे, DNS अनुरोधों का एक बहुत ।

— जोकर_vD

@Joker_vD DNSSEC डेटा पर हस्ताक्षर करता है, न कि ट्रैफ़िक पर। यानी, आधिकारिक छोर पर आप अपने ज़ोन पर हस्ताक्षर कर सकते हैं और हस्ताक्षर के जीवनकाल के लिए (या जब तक आप ज़ोन डेटा नहीं बदलते हैं) अधिक "क्रिप्टोकरेंसी" नहीं है; यह सत्यापनकर्ता पक्ष (क्लाइंट पक्ष) पर है कि प्रति-अन-एक्सेप्टेड "क्रिप्टोडेंस" होने की आवश्यकता है। अतिरिक्त डेटा और DNSSEC स्थिति डीएनएस के लिए सामान्य कैशिंग मॉडल दोनों फिट बैठता है।

— एचकेन लिंडक्विस्ट

Answer 2

विभिन्न प्रकार के प्रमाणपत्र सत्यापन प्रक्रियाएं

नियमित CA- हस्ताक्षरित प्रमाणपत्रों के साथ, प्रमाणपत्र सत्यापन के कई स्तर हैं:

• डोमेन सत्यापन (DV)
  केवल डोमेन नाम स्वामित्व को मान्य किया गया है, केवल डोमेन नाम को प्रमाणपत्र में "विषय" के रूप में दिखाया गया है
• संगठन मान्यता (OV)
  डोमेन नाम और मालिक का नाम मान्य है, डोमेन नाम और मालिक का नाम प्रमाण पत्र में "विषय" के रूप में दिखाते हैं
• विस्तारित सत्यापन (EV)
  मालिक इकाई, डोमेन नाम और मालिक के नाम का अधिक कठोर सत्यापन प्रमाण पत्र में "विषय" के रूप में दिखाता है, मालिक के नाम के साथ हरी पट्टी

आप जिस प्रक्रिया का वर्णन करते हैं, और उसके लिए प्रतिस्थापन का प्रस्ताव करते हैं, वह केवल निम्नतम स्तर, डोमेन सत्यापन (DV) पर लागू होता है।

DV वह स्तर है जहां सत्यापन स्वचालित रूप से सीधा होता है, जैसे कि LetsEncrypt ने क्या किया है, और ट्रस्ट को समान स्तर प्रदान करता है जैसा कि DNS प्रदान कर सकता है अगर यह ट्रस्ट-एंकर (यूआई दिशानिर्देश) के लिए एकमात्र स्रोत के रूप में इस्तेमाल किया गया हो, तो प्रमाणित हो सकता है विश्वसनीय रहें लेकिन अतिरिक्त डेटा शामिल करें जो किसी भी तरह से मान्य नहीं है)।

नामांकित संस्थाओं का डीएनएस-आधारित प्रमाणीकरण

DAN DNSSEC के ऊपर बनाता है (DNS डेटा प्रामाणिकता के रूप में महत्वपूर्ण है) DNS में TLS क्लाइंट के लिए विश्वास-लंगर जानकारी प्रकाशित करने के लिए।

यह का उपयोग करता TLSAआरआर प्रकार और या तो प्रमाणपत्र और सार्वजनिक कुंजी (पहचान करने के लिए इस्तेमाल किया जा सकता चयनकर्ता के साथ या भी (सफल होने के लिए नियमित रूप से प्रमाणपत्र श्रृंखला सत्यापन की आवश्यकता के बिना, दोनों छोर संस्था या सीए की) प्रमाणपत्र के उपयोग ) और कैसे प्रमाणपत्र / कुंजी डेटा को रिकॉर्ड ( मिलान प्रकार ) में दर्शाया गया है ।

TLSAरिकॉर्ड मालिक का नाम एक उपसर्ग जो बंदरगाह और प्रोटोकॉल (जैसे इंगित करता है _443._tcp) और rdata इंगित करता है cert usage, selectorऔर matching type/ कुंजी डेटा का मिलान करने प्रमाणपत्र के अलावा मोड। इन मापदंडों की बारीकियों के लिए RFC6698 का ​​खंड 2.1 देखें ।

TLSAउदाहरण के लिए एक रिकॉर्ड इस तरह दिख सकता है:

_443._tcp.www.example.com. IN TLSA  2 0 1 d2abde240d7cd3ee6b4b28c54df034b9 7983a1d16e8a410e4561cb106618e971

उपयोग मोड 2या 3(टीएलएसए ट्रस्ट-एंकर के अकेले उपयोग का संकेत देता है) के साथ, एक डीएएनई-जागरूक ग्राहक एक ऐसे प्रमाण पत्र को स्वीकार करेगा जो आम तौर पर विश्वसनीय सीए द्वारा हस्ताक्षरित नहीं है लेकिन जो TLSAरिकॉर्ड से मेल खाता है ।
यह वैचारिक रूप से वही है जो आप अपने प्रश्न में प्रस्तावित करते हैं।

कैच? DANE- अवगत क्लाइंट वर्तमान में कम या ज्यादा मौजूद नहीं हैं, एक मुद्दा यह है कि DNSSEC ही व्यापक रूप से तैनात नहीं है (विशेष रूप से क्लाइंट मशीन पर सत्यापन) के रूप में जो संभवतः DANE को दूर करने के लिए आवश्यक होगा। चिकन-एंड-एग समस्या की थोड़ी बहुत संभावना है, यह देखते हुए कि डीएएनई पहले संभावित बड़े नए उपयोग-मामलों में से एक है जो प्रामाणिक डीएनएस डेटा पर भरोसा करते हैं।

एक ब्राउज़र प्लगइन है जो DNSSEC और DANE सत्यापन को जोड़ता है , इसके अलावा वहाँ बहुत कुछ नहीं है जो इस बिंदु पर मुख्यधारा के पास कहीं भी है। और, मूल रूप से समर्थित के बजाय एक प्लगइन होने के नाते, यह सामान्य उपयोग की बात आने पर किसी भी चीज़ की तुलना में प्रूफ-ऑफ-कॉन्सेप्ट के रूप में अधिक कार्य करता है।

यह किया जा सकता है। इस पर विचार किया गया है। यह अभी भी हो सकता है, लेकिन बहुत अधिक आंदोलन नहीं हुआ है।

Comments

धन्यवाद हाकन। जैसा कि एंड्रयू मेरे ओपी के तहत बताते हैं, DNS और DNSSEC के साथ एक समस्या है, क्योंकि DNSSEC को मजबूर नहीं किया जाता है (तब भी जब चाबियाँ TLD DNS में होती हैं, मुझे लगता है) DNS सर्वर जिस तरह से डैनियल जानकारी को खराब कर सकते हैं। , सही? इसलिए DNSSEC को DANE रिकॉर्ड को मान्य करने के लिए बाध्य किया जाना चाहिए, जिसका अर्थ है कि प्रत्येक और हर चेक को TLD सर्वर पर कुंजियों की जांच करनी चाहिए।

— जैलमेर जेलेमा

@ जैल्मरजेल्मा जैसा कि मैंने अपने जवाब में उल्लेख किया है, DNSSEC को क्लाइंट पर वैरिफाइड करने की जरूरत है (ऐसा न करने की समस्या जो एंड्रयू ने बताई है) और केवल सफलतापूर्वक वेरिफाइड टीएलएसए रिकॉर्ड्स का ही इस्तेमाल किया जा सकता है। आप जिस समस्या के बारे में बात करते हैं वह डिजाइन के मामले में समस्या नहीं है, यह मुख्यधारा के सॉफ़्टवेयर में समर्थन के मामले में एक समस्या है।

— हाकन लिंडक्विस्ट

सही नहीं है, ISPs या खुले लोगों पर अधिक से अधिक पुनरावर्ती नामांक, जैसे 8.8.8.8 या 9.9.9.9 DNSSEC सत्यापन कर रहे हैं। डबसेक-ट्रिगर अनबाउंड और / या स्टबबी जैसी चीजों पर निर्मित होता है, जो क्लाइंट पर आवश्यक रूप से पूर्ण मान्य DNS रिसॉल्वर के बिना क्लाइंट पर पूर्ण DNSSEC सत्यापन की अनुमति देगा। लेकिन हम वास्तव में इससे बहुत दूर हैं ...

— पैट्रिक मेवज़ेक