💶 🏔️ 🤞 पेट्रिक पैट्रिक के लिए टीएलएस का एक परिचय (भाग 1) 🐑 🎗️ 👩🏻‍🎓

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

यह लेख पैट्रिक और उनके जैसे लोगों के लिए लिखा गया है। वह पहले हमारे आंतरिक शैक्षिक Plesk TechTalk में दिखाई गई एक प्रस्तुति से पैदा हुई थीं, जहां एक सुलभ रूप में कर्मचारी एक-दूसरे के साथ दिलचस्प तकनीकों, प्रक्रियाओं और समाधानों के बारे में जानकारी साझा करते हैं। इसलिए, इस लेख में चित्र स्लाइड की तरह दिखेंगे :) रिपोर्ट के मूल पाठ के लेखक प्रोग्राम मैनेजर प्लस्क रुसलान कोसोलपोव हैं ।

आमतौर पर, सभी टीएलएस सामग्री कुछ छोटे पहलू को कवर करती है, लेकिन बड़ी तस्वीर नहीं। यह बहुत व्यावहारिक नहीं है और पैट्रिक को इससे सिरदर्द होता है। यहां सब कुछ अलग होगा: संक्षेप में, "रोजमर्रा की जिंदगी में" और जितना संभव हो उतना थकाऊ।

टीएलएस क्या है और यह पैट्रिक के लिए क्यों है

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

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

संक्षेप में, शीर्ष-स्तरीय हैंडशेक इस तरह दिखता है:

पैट्रिक: मैं टीएलएस का उपयोग करना चाहता हूं, सिफर संस्करण इस तरह के हैं।
Spongebob: ठीक है, चलो इस तरह के और इस तरह के सिफर संस्करणों का उपयोग करें।

उसके बाद, स्पंज प्रमाण पत्र भेजता है, पैट्रिक इसकी जांच करता है, कहता है कि सब कुछ ठीक है, सत्र कुंजी की जाती है (वास्तव में उनमें से दो हैं, लेकिन यह महत्वपूर्ण नहीं है)। असममित एन्क्रिप्शन के बजाय सत्र कुंजी का उपयोग क्यों करें - क्योंकि यह तेज़ है। उसके बाद, वे डिक्रिप्शन करने के लिए समझ से बाहर की भाषा बोलने लगते हैं। इस प्रकार, सब कुछ संरक्षित है।

सब कुछ सरल लगने लगा है। यह हार्डवेयर पर कैसे काम करता है यह हमारे लिए इतना महत्वपूर्ण नहीं है। लेकिन अगर आप सोचने लगते हैं - और पैट्रिक सोचने लगता है! - यह इस सवाल का जवाब देता है कि आम तौर पर हम टीएलएस का उपयोग करने के लिए कैसे सहमत होंगे? आखिरकार, एक बार टीएलएस नहीं था, लेकिन केवल सामान्य प्रोटोकॉल थे - एसएमटीपी, एचटीटीपी। टीएलएस पर क्या कहना है? और यहां हमारे उद्योग में सब कुछ हमेशा की तरह है - कई तरीके हैं!

सबसे पहले वे एक विशिष्ट बंदरगाह का उपयोग करना चाहते थे, जो उस पर टीएलएस का उपयोग करेगा। इसके क्या नुकसान हैं? और फिर टीएलएस सत्र शुरू करने के लिए स्पष्ट (स्पष्ट) तरीका क्यों दिखाई दिया? इसके कई कारण हैं:

आपको बहुत सारे पोर्ट की आवश्यकता है - और पोर्ट एक ऐसी चीज है जिसे आप खर्च नहीं करना चाहते हैं। क्योंकि जितने अधिक हैं, फायरवॉल को कॉन्फ़िगर करना उतना ही मुश्किल है।
सर्वर इसे अनदेखा कर सकता है - यह पोर्ट 443 से जुड़ा है, और वहां कोई टीएलएस नहीं है, केवल एचटीटीपीएस के बिना HTTP।
कनेक्शन स्थापित होने से पहले, आपको पता नहीं चल सकता है कि टीएलएस सर्वर समर्थित है या नहीं।

यह सब एक स्पष्ट पद्धति का उदय हुआ - जब हम एक नियमित बंदरगाह से जुड़ते हैं, और फिर अपने सत्र को टीएलएस में अपग्रेड करते हैं। विभिन्न सेवाओं के लिए, प्रोटोकॉल में अलग-अलग कमांड होते हैं, उदाहरण के लिए, एसएमटीपी के लिए एसएमटीपी प्रोटोकॉल के स्तर पर एक अलग कमांड है - STARTLLS । HTTP में भी इस तरह का मजाक है, इसे Upgrad: TLS / 1.0 कहा जाता है । प्रोटोकॉल स्तर पर, यह समझना आसान है कि टीएलएस सर्वर समर्थित है या नहीं।

आइए हम विभिन्न प्रकार के कनेक्शनों पर थोड़ा और ध्यान दें और उनके लिए टीएलएस के साथ चीजें कैसी हैं।

कनेक्ट: HTTP

सब कुछ आसान होगा अगर, हमेशा की तरह, कोई बारीकियां नहीं थीं। HTTP के मामले में, बढ़ती सुरक्षा आवश्यकताएं TLS के साथ काम करने की प्रक्रिया का निरंतर विकास प्रदान करती हैं। सबसे पहले HTTPS में एक रीडायरेक्ट किया गया था, और यह केवल हेडर में किया गया था। इसने कमजोरियों के लिए एक बचाव का रास्ता छोड़ा, इसलिए साथी Google HSTS (HTTP सख्त परिवहन सुरक्षा) के साथ आया। यह HTTP प्रतिक्रिया में ऐसा हेडर है जो ब्राउज़र को बताता है: "कृपया याद रखें कि जब आप इस डोमेन पर आते हैं, तो सीधे HTTPS पर जाएं, भले ही उस व्यक्ति ने आपको HTTP पर जाने के लिए कहा हो"। इस प्रकार, कोई पुनर्निर्देश नहीं है और सब कुछ बहुत सुरक्षित होता है। इसके अलावा, Google की एक और पहल है - आप एक अनुरोध छोड़ सकते हैं ताकि आपकी साइट Google Chrome के लिए सूची में शामिल हो जाए "हमेशा HTTPS का उपयोग करें", चाहे कोई भी शीर्षक हो।

संक्षेप में: HSTS HTTP से HTTPS भेद्यता तक पुनर्निर्देशित करता है, इसलिए लगभग सभी ब्राउज़र HSTS का समर्थन करते हैं, जो अच्छा है।

कनेक्ट: विदेशी (HTTP के नए संस्करण और न केवल)

HTTP / 2 में, टीएलएस के साथ चीजें अच्छी हैं: यह हमेशा उपयोग किया जाता है (जैसा कि ब्राउज़र अब बना है)। इसके अलावा, HTTP / 2 में TLS ताज़ा होना चाहिए - अर्थात, संस्करण 1.2+ है।

सबसे अधिक संभावना है, बहुत जल्द Google HTTP / 3 के व्यापक उपयोग को बेच देगा, अब इसे IANA मानक द्वारा अपनाया जाता है। इसकी उपस्थिति और विकास की कहानी बल्कि भ्रामक है; पैट्रिक को याद रखने की मुख्य बात:

HTTP / 3 हमेशा TLS 1.3+ है।
HTTP / 3 QUIC पर आधारित है - यह UDP पर एक ऐसा प्रोटोकॉल है, जो Google के अनुसार, टीसीपी से बेहतर है। दरअसल, HTTP / 3 नाम को अंतिम रूप से अनुमोदित किए जाने से पहले, प्रोटोकॉल को HTTP-over-QUIC कहा जाता था।

अभी भी एक दिलचस्प SCTP प्रोटोकॉल है, जिसका उपयोग मुख्य रूप से दूरसंचार में किया जाता है। इसके ऊपर, TLS और DTLS दोनों का उपयोग किया जाता है (यह UDP के लिए ऐसा TLS है)।

संक्षेप में: 2 वर्षों में, QUIC (यानी HTTP / 3) का उपयोग हर जगह किया जाएगा, लेकिन अब हर जगह पहले से ही HTTP / 2 होना चाहिए, लेकिन वास्तव में यह हर जगह नहीं है।

कनेक्ट: मेल

कई ग्राहकों का मानना है कि 587 वें बंदरगाह पर टीएलएस होना चाहिए, लेकिन यहां भी बारीकियां हैं: किसी को डिफ़ॉल्ट रूप से टीएलएस की उम्मीद है, और किसी को ग्राहक से एक स्पष्ट STARTTLS अनुरोध की उम्मीद है । इस वजह से, मेल सर्वर और मेल क्लाइंट के विभिन्न संयोजन कभी-कभी अवांछित प्रभाव पैदा करते हैं। उदाहरण के लिए, एक क्लाइंट पोर्ट 587 में प्रवेश करता है, यह उम्मीद करता है कि टीएलएस होगा, जबकि सर्वर क्लाइंट को STARTTLS के लिए स्पष्ट रूप से अनुरोध करने की प्रतीक्षा करता है । कुछ भी प्राप्त नहीं होने पर, क्लाइंट वापस पोर्ट 25 पर आ जाता है। परिणाम असुरक्षित SMTP कनेक्शन के लिए एक मूक स्विच है। परीक्षण और विकास करते समय, यह क्लाइंट-सर्वर संयोजनों के ऐसे प्रभावों के बारे में याद रखने योग्य है। ऑटोडिसकवर के पास टीएलएस निर्दिष्ट करने के लिए विभिन्न विकल्प हैं: यह कैसे होना चाहिए, क्या अपेक्षित है, और क्या करना है। कई मेल क्लाइंट इन बातों को समझते हैं।

संक्षेप में: मेल सर्वर और मेल क्लाइंट में टीएलएस समर्थन के साथ सब कुछ सामान्य रूप से ठीक है, लेकिन विशेष मामलों में समस्याएं हो सकती हैं और टीएलएस एक्सटेंशन बहुत अच्छी तरह से समर्थित नहीं हैं।

कनेक्ट: एफ़टीपी

यहाँ थोड़ा कहा जा सकता है। मुख्य समस्या एसएनआई है (यह तब है जब विभिन्न डोमेन एक ही आईपी पर हैं)। एफ़टीपी स्तर पर, डोमेन नाम स्थानांतरित नहीं होता है। एक स्पष्ट संस्करण में, यह काम नहीं कर सकता, क्योंकि इसे लिखने के लिए कहीं नहीं है। कई समाधान विकल्प हैं - कुछ प्रस्ताव तो, अन्य इसलिए, एक सामान्य समाधान अभी तक नहीं अपनाया गया है, कोई मानक नहीं है।

संक्षेप में: एफ़टीपी (एफटीपीएस, एसएफटीपी - एसएसएच के माध्यम से एफ़टीपी का एक एनालॉग) के लिए टीएलएस समर्थन का कुछ प्रकार है, लेकिन एफ़टीपी की तकनीकी सीमाओं के कारण कुछ पहलुओं को कवर नहीं किया गया है।

टीएलएस हैंडशेक

तो, अब हम जानते हैं कि अलग-अलग कनेक्शनों में टीएलएस का उपयोग करके संचार कैसे शुरू किया जाए, और पैट्रिक अपनी इच्छा को स्पंज तक पहुंचा सके। एक बार जब वे सहमत हो जाते हैं कि वे टीएलएस का उपयोग करेंगे, टीएलएस हैंडशेक का उत्पादन किया जाता है। इसका परिणाम क्लाइंट और सर्वर के बीच एक समझौता होना चाहिए कि वे इसे कैसे एन्क्रिप्ट करते हैं। इसके अलावा, क्लाइंट को यह सुनिश्चित करना होगा कि सर्वर वह है जिसकी आवश्यकता है। कभी-कभी सर्वर क्लाइंट को चेक भी करता है (लेकिन बहुत कम बार)।

सिफर और संस्करण

जैसा कि पहले ही उल्लेख किया गया है, पहला कदम यह चुनना है कि एन्क्रिप्शन के लिए टीएलएस के कौन से संस्करण और किस सिफर का उपयोग किया जाएगा। आमतौर पर, सिफर इस तरह दिखता है:

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

DHE
ECDhe
AES128
AES256
आरएसए
ECDSA
सीबीसी
GCM
SHA256
SHA383
CHACHA20
POLY1308

अच्छे सिपहसालारों को याद करने के लिए चित्र:

यदि यह याद रखना कठिन है, तो अच्छी सेवाएं हैं जो आपको इसके बारे में बता सकती हैं, उदाहरण के लिए, मोज़िला ssl-config.mozilla.org की एक सेवा ।

आप तुरंत देख सकते हैं कि यह कहाँ और कैसे समर्थित है - यह वही है जो मोज़िला लोग अनुसरण करने की कोशिश कर रहे हैं।

एक दिलचस्प विवरण: ग्राहक प्राथमिकता के क्रम में सिफर को अपनी प्राथमिकताओं के अनुसार स्थानांतरित करता है, लेकिन सर्वर निर्णय के साथ छोड़ दिया जाता है - यह उस सिफर का चयन करता है जो समर्थित क्लाइंट की सूची से सबसे अच्छा लगता है।

दोनों पक्ष प्रोटोकॉल के अधिकतम समर्थित संस्करण को भी इंगित करते हैं - इस मामले में, पैट्रिक स्पंज की तुलना में अधिक उन्नत है।

वास्तव में प्रमाण पत्र

उत्तर के साथ "चलो ऐसा करते हैं", सर्वर अपना प्रमाण पत्र या प्रमाण पत्र भेजता है - उनमें से कई हो सकते हैं।

एक प्रमाण पत्र क्या है? यह सूचना (विषय) का एक संबंध है - अक्सर यह एक डोमेन या संगठन का नाम है - और एक सार्वजनिक कुंजी (सार्वजनिक कुंजी)। यही है, प्रमाण पत्र कहता है: "यार, मेरी सार्वजनिक कुंजी इस तरह है। अब, उनकी मदद से, हम सत्र कुंजियों पर सहमत होंगे। ” इसके अलावा, इसकी मदद से, आप प्रमाण पत्र या कुछ और के हस्ताक्षर की जांच कर सकते हैं। यही है, सिद्धांत रूप में, प्रमाण पत्र का उपयोग करना संभव होगा, लेकिन रजिस्ट्रियां जहां यह संबंध इंगित किया गया है। और वास्तव में, इस दिशा में कदम जारी हैं, क्योंकि प्रमाणपत्र प्राधिकरण तंत्र को बहुत अच्छा नहीं माना जाता है, बस कुछ और नहीं है।

इस प्रकार, प्रमाण पत्र 'विषय: सार्वजनिक कुंजी' की संरचना है और साथ ही इश्युअर के हस्ताक्षर (रूसी में लिप्यंतरण में जारी करने वाला) भयानक लगता है, लेकिन यहां "निकटतम" के संदर्भ में निकटतम पर्यायवाची "जारीकर्ता" के संदर्भ में बहुत करीब नहीं है कि यह प्रमाण पत्र जारी किया गया था। इश्यूयर के पास एक प्रमाण पत्र और किसी के साथ किसी का कनेक्शन भी है। आप इश्युअर की सार्वजनिक कुंजी लेकर और हस्ताक्षर की जांच करके शुद्धता के लिए प्रमाण पत्र की जांच कर सकते हैं। नतीजतन, यहां कुछ भी नकली नहीं किया जा सकता है।

आइए प्रमाण पत्र पर जाएं और देखें कि इसमें क्या समस्याएं हो सकती हैं।

सबसे पहले, सीरियल नंबर का अर्थ केवल इशिअएयर की सीमा के भीतर विशिष्टता है, हालांकि कुछ सॉफ्टवेयर मानते हैं कि यह पूरे ब्रह्मांड में अद्वितीय है। सौभाग्य से, अधिक बार नहीं, यह वास्तव में पूरी तरह से अद्वितीय है।

प्रमाणपत्र यह भी इंगित करता है कि एन्क्रिप्शन और हस्ताक्षर के लिए कौन से एल्गोरिदम का उपयोग किया जाता है: आरएसए या ईसीडीएसए - जो कि इस सार्वजनिक कुंजी के साथ काम करने के लिए उपयोग करने के लिए क्रिप्टोग्राफी है। आरएसए और ईसीडीएसए के बीच मुख्य अंतर यह है कि ईसीडीएसए का गणितीय सिद्धांत दीर्घवृत्तीय वक्रों पर आधारित है, और आरएसए केवल प्राकृतिक संख्या है, इसलिए यह धीमी है और इसे फटने से बचाने के लिए विशाल कुंजियों (3-4 हजार) का उपयोग किया जाता है। । और ECDSA के लिए, 300-बिट कुंजी पर्याप्त है और यह तेजी से काम करती है। इसलिए, कई ईसीडीएसए पर स्विच कर रहे हैं - हैंडशेक अपने आप में भारी है और मैं इसे कम करना चाहता हूं। प्रमाण पत्र जारी करते समय ईसीडीएसए के लिए कहा जा सकता है, और यदि भावी व्यक्ति इसका समर्थन करता है, तो वह आपके लिए करेगा। लेकिन प्रमाण पत्र पर हस्ताक्षर इस बात पर निर्भर करता है कि वर्तमान में निजी कुंजी इसूहुर के पास है, और इस पर नहीं कि आपने ईसीडीएसए या आरएसए के लिए कहा थाइसलिए, ब्राउज़र दिखा सकते हैं कि एक हस्ताक्षर में और दूसरा सार्वजनिक कुंजी में है, और डरने की कोई ज़रूरत नहीं है अगर हस्ताक्षर ECDSA नहीं है।

प्रमाण पत्र कैसे प्राप्त करें?

संक्षेप में - इस तरह:

पैट्रिक सर्टिफिकेट अथॉरिटी को बताता है: मुझे एक सर्टिफिकेट चाहिए। यह व्यक्ति (या संगठन) यह देखने के लिए जाँच करता है कि क्या यह पैट्रिक है। चेक बहुत अलग हो सकते हैं। बेशक, एक ग्राहक के रूप में पैट्रिक के पास प्रमाणपत्र नहीं हो सकता है, लेकिन यदि सर्वर के पास प्रमाण पत्र नहीं है, तो कोई टीएलएस नहीं होगा। यह जाँच की जाती है कि क्या प्रमाण पत्र आवेदन में सब कुछ सही ढंग से दर्शाया गया है, क्या पैट्रिक वास्तव में उस विषय का मालिक है जिसके लिए वह प्रमाण पत्र का अनुरोध कर रहा है। यह उच्च प्रमाणपत्र प्राधिकरण केंद्रों - सशर्त लोगों द्वारा किया जाता है, जिन्हें हर कोई मानता है। प्रमाण पत्र जारी करने के लिए, आपको एक सीएसआर (प्रमाण पत्र पर हस्ताक्षर करने का अनुरोध, प्रमाण पत्र के लिए एक अनुरोध) तैयार करना होगा।

यह भी एक संरचना है, जिसके साथ काम करना काफी मुश्किल है, क्योंकि कुछ सेवाएं हैं जो आपको सब कुछ सेट, निर्दिष्ट, सत्यापित और देखने की अनुमति देती हैं।

कुल, हम सार्वजनिक कुंजी की एक जोड़ी उत्पन्न करते हैं: निजी कुंजी, लेकिन हम केवल सार्वजनिक देते हैं, और निजी छिपाते हैं। फिर हम एक प्रमाणपत्र हस्ताक्षर अनुरोध उत्पन्न करते हैं और इसे हमारी निजी कुंजी के साथ हस्ताक्षर करते हैं। हम प्रमाणन प्राधिकरण को यह सब भेजते हैं, और यह सत्यापन शुरू करता है। यह अलग हो सकता है, विशेष रूप से शांत प्रमाण पत्र के लिए विशेष पेचीदा प्रक्रियाएं हैं, लेकिन हम सामान्य मामले पर ध्यान देंगे।

सीएए आरआर

ऐसी समस्या है कि जिन लोगों को हर कोई मानता है वे कभी-कभी बहुत अच्छे नहीं होते हैं। एक कारण यह है कि Symantec DigiCert का हिस्सा बन गया है क्योंकि यह (Symantec) डोमेन मालिकों से पूछे बिना प्रमाणपत्र जारी करता है। आप ऐसा नहीं कर सकते हैं, यह सभी के लिए अपमानजनक था, लेकिन सभी के लिए सिमेंटेक में ही, क्योंकि आपको अपना व्यवसाय बेचना था। सर्वर को इस तरह के बेईमान कामरेड पर कम निर्भर बनाने के लिए, CAA RR - DNS में एक रिकॉर्ड है, जहां यह कहता है कि मालिक कौन अपने डोमेन के लिए प्रमाण पत्र जारी करने की अनुमति देता है। यह सुविधा भी Plesk में है, यह अब तक बहुत कम इस्तेमाल किया जाता है, लगभग DNSSec की तरह, लेकिन फिर भी। सभी प्रमाणीकरण प्राधिकारी इस प्रविष्टि की जाँच करने के लिए सहमत हुए और यदि यह कहता है कि यह प्रमाणीकरण प्राधिकारी जारी नहीं कर सकता है, तो यह कहेगा: "आपने सत्यापन पारित नहीं किया है, यह CAA RR में लिखा गया है,मैं आपके लिए एक प्रमाणपत्र नहीं लिखूंगा - और इसे नहीं लिखूंगा। यदि कोई प्रविष्टि नहीं है, तो आप कर सकते हैं। अब Google पहल को आगे बढ़ा रहा है ताकि ग्राहक CAA RR रिकॉर्ड्स के अनुपालन के लिए प्राप्त प्रमाण पत्र की जांच करें। बहस अभी भी जारी है।

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

यह सब किसी भी प्रकार के प्रमाण पत्र के लिए काम करता है, और चूंकि हम बाद में मतभेदों के बारे में बात करेंगे, यह अधिक विस्तार से प्रकारों के बारे में बात करने का समय है।

प्रमाणपत्र प्रकार

उनमें से तीन हैं:

डोमेन सत्यापन

विषय एक डोमेन है, अर्थात्, हम इसे केवल जाँचते हैं। पहले, जब कोई स्वचालित सत्यापनकर्ता नहीं थे, तो सत्यापन मुख्य रूप से ई-मेल द्वारा व्हिस सेवा के माध्यम से हुआ। यह मानने के लिए पर्याप्त कारण माना जाता था कि आप इस डोमेन के मालिक हैं। फिर उन्होंने डीएनएस के माध्यम से जाँच करने का विचार किया - उन्होंने आपको ई-मेल द्वारा लिखा: "और डीएनएस को ऐसे रिकॉर्ड जोड़ें"। बाद में स्वचालित तरीके दिखाई दिए (हम एसीएमई के बारे में थोड़ी आगे बात करेंगे)।

संगठन का सत्यापन

"विषय" फ़ील्ड में, डोमेन नाम के अलावा, संगठन का नाम भी इंगित किया गया है। चेक में यह सत्यापित करना शामिल है कि क्या डोमेन इस संगठन का है और क्या प्रमाण पत्र के लिए आया व्यक्ति वहां काम करता है। यह कैसे किया जाता है: वे रजिस्टरों पर संगठनों की तलाश करते हैं, फोन करते हैं, कुछ करने के लिए कहते हैं (फोन सही निकला, सही व्यक्ति ने उत्तर दिया, जिसका अर्थ है कि सबसे अधिक संभावना है कि सब कुछ ठीक है)।

विस्तारित मान्यता

OV के रूप में ही, केवल कूलर। यहां सब कुछ बहुत विनियमित है - "पैराग्राफ 5.6.8 में निम्नलिखित के रूप में एक 40-पृष्ठ का दस्तावेज़ होना चाहिए: ...", आदि। बहुत सी चीजों की जाँच की जाती है - देश, विभाग (यदि आवेदन में संकेत दिया गया है), और कभी-कभी एक विशेष व्यक्ति भी अपनी आँखों से देखने के लिए छोड़ देता है। व्यावहारिक अंतर क्या है? लगभग सभी ब्राउज़र OV और DV के बीच अंतर करना बंद कर चुके हैं, और यह खराब है, क्योंकि इस मामले में संगठन का नाम प्रदर्शित नहीं होता है। नतीजतन, कोई भी एक डोमेन aliepxress.ru बनाने के लिए परेशान नहीं करता है, एक ही पृष्ठ ड्रा करें और क्रेडिट कार्ड चोरी करें। और ऐसे किसी भी डोमेन को बनाना और उस पर DV प्रमाणपत्र प्राप्त करना बिल्कुल वैध होगा।

EV के साथ उदाहरण - संगठन का नाम यहाँ दिखाई दे रहा है, इसलिए यदि कोई कुछ चुराता है, तो उपयोगकर्ता को पता चलेगा कि यह वाल्व कॉर्प निगम था, और निगम को पंजीकृत करना डोमेन (अधिक चेक) की तुलना में कुछ अधिक कठिन है।

हालांकि, सब कुछ उस बिंदु पर जाता है जहां ईवी अलग होना बंद हो जाएगा, मोबाइल उपकरणों पर यह अब दिखाई नहीं देता है और आपको एक अलग बटन दबाने की आवश्यकता है, और सफारी में भी। Google Chrome अभी भी पकड़ रहा है (UPD - अब नहीं! मुझे IE से एक स्क्रीन बनानी थी)। जो नहीं दिखाते हैं उनका तर्क: "यदि आप चिंतित हैं, तो क्लिक करें और देखें," लेकिन कोई भी स्वाभाविक रूप से नहीं दबाता है।

एक प्रमाण पत्र प्राप्त करना: स्वचालन

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

ACME

ACME (स्वचालित प्रमाणपत्र प्रबंधन पर्यावरण) एक प्रोटोकॉल है जो प्रमाणपत्र प्राप्त करने की प्रक्रिया को स्वचालित और मानकीकृत करने के लिए डिज़ाइन किया गया है।

ACME कैसे साबित करता है कि आप एक डोमेन स्वामी हैं? आप कहते हैं: मैं एक प्रमाण पत्र चाहता हूं और स्वचालित सत्यापन के प्रकार को इंगित करता हूं - उदाहरण के लिए, ACME HTTP-01। आइए एन्क्रिप्ट करें आपसे डेटा को एक फ़ाइल में रखने के लिए कहते हैं, और यदि आप फ़ाइलों को अपने डोमेन पर रख सकते हैं (और चलो एन्क्रिप्ट उन्हें HTTP के माध्यम से वहां से उठा सकते हैं), तो आप शायद इसके मालिक हैं। अब इस दृष्टिकोण की आलोचना की जाती है, जिसमें Google भी शामिल है, क्योंकि यह फ़िशिंग से रक्षा नहीं करता है। यही है, मैनुअल मान्यता के साथ, aliepxress.ru डोमेन संदेह पैदा करने की संभावना है, लेकिन चलो अब तक खुद को एन्क्रिप्ट करें पता नहीं कैसे (या यह कर सकते हैं, लेकिन बुरी तरह से)।

डीएनएस चुनौती

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

लेट्स एनक्रिप्ट के बारे में दो और शब्द

लेट्स एनक्रिप्ट सर्टिफिकेट के साथ काम करने में एक महत्वपूर्ण पहलू सीमा है। संदेह (या संदेह है कि उन्हें हासिल किया गया है) के मामले में, लिंक का पालन करना सबसे अच्छा है: letencrypt.org/docs/rate-limits

कभी-कभी उन्हें अपडेट किया जाता है। ऐसी अस्पष्ट सीमाएं हैं जिनके बारे में लोग भूल जाते हैं: अक्सर, समर्थन के अनुरोधों को देखते हुए, उन्हें प्रमाणपत्र में 100 डोमेन नामों की सीमा का सामना करना पड़ता है। आइए Encrypt में एक स्टेजिंग सर्वर भी है और इसकी सीमाएं अधिक हैं, लेकिन ऐसे प्रमाणपत्रों को गैर-विश्वसनीय माना जाता है और ब्राउज़र के लिए वे स्व-हस्ताक्षरित के समान हैं। व्यवहार में, 100 नामों की सीमा के साथ, वे शायद ही कभी हमारे पास आते हैं (इस तथ्य के बावजूद कि प्लेस्क पर साइटों के पास कुल 1,300,000 लेट्स एनक्रिप्टेड प्रमाण पत्र हैं)। मेडियन, हमारे आंकड़ों के अनुसार, प्रति प्रमाणपत्र 20 नाम हैं। इसलिए अगर कुछ काम नहीं करता है, तो देखें - शायद सीमा पूरी हो गई है। आइए Encrypt में अच्छी त्रुटि रिपोर्टिंग है, और आप आमतौर पर समझ सकते हैं कि क्या हुआ।

आगे क्या होगा?

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

टीएलएस 1.3 के एक खुले चैनल से गुजरने से पहले हमने जो कुछ भी बात की थी, और कोई भी इन सभी चीजों को देख सकता है। कई दिलचस्प हमले हैं जो आप अपने बारे में पढ़ सकते हैं। लेख
की दूसरी ~~श्रृंखला~~ में, हम सीखेंगे कि ग्राहक प्रमाणपत्र को कैसे सत्यापित करता है।

पेट्रिक पैट्रिक के लिए टीएलएस का एक परिचय (भाग 1)