टीएलएस हैंडशेक क्या है और यह कैसे काम करता है? देखें कि अन्य शब्दकोशों में "टीएलएस" क्या है। इस्तेमाल किए गए टीएसएल प्रोटोकॉल को कैसे सेट करें

टीएलएस प्रोटोकॉल सभी प्रकार के इंटरनेट ट्रैफ़िक को एन्क्रिप्ट करता है, जिससे संचार और बिक्री ऑनलाइन सुरक्षित हो जाती है। हम इस बारे में बात करेंगे कि प्रोटोकॉल कैसे काम करता है और भविष्य में हमारा क्या इंतजार है।

लेख से आप सीखेंगे:

एसएसएल क्या है

एसएसएल या सिक्योर सॉकेट लेयर प्रोटोकॉल का मूल नाम था जिसे नेटस्केप ने 90 के दशक के मध्य में विकसित किया था। एसएसएल 1.0 कभी भी सार्वजनिक रूप से उपलब्ध नहीं था, और संस्करण 2.0 में गंभीर खामियाँ थीं। 1996 में जारी एसएसएल 3.0, एक पूर्ण बदलाव था और इसने विकास के अगले चरण के लिए रूपरेखा तैयार की।

टीएलएस क्या है?

जब प्रोटोकॉल का अगला संस्करण 1999 में जारी किया गया, तो इंटरनेट इंजीनियरिंग टास्क फोर्स ने इसे मानकीकृत किया और इसे एक नया नाम दिया: ट्रांसपोर्ट लेयर सिक्योरिटी, या टीएलएस। जैसा कि टीएलएस दस्तावेज़ में कहा गया है, "इस प्रोटोकॉल और एसएसएल 3.0 के बीच अंतर महत्वपूर्ण नहीं है।" टीएलएस और एसएसएल प्रोटोकॉल की एक सतत श्रृंखला बनाते हैं और अक्सर एसएसएल/टीएलएस नाम के तहत संयुक्त होते हैं।

टीएलएस प्रोटोकॉल किसी भी प्रकार के इंटरनेट ट्रैफ़िक को एन्क्रिप्ट करता है। सबसे आम प्रकार वेब ट्रैफ़िक है। आप जानते हैं कि आपका ब्राउज़र कब टीएलएस कनेक्शन स्थापित करता है - यदि एड्रेस बार में लिंक "https" से शुरू होता है।

टीएलएस का उपयोग अन्य अनुप्रयोगों, जैसे मेल और टेलीकांफ्रेंसिंग सिस्टम द्वारा भी किया जाता है।

टीएलएस कैसे काम करता है

ऑनलाइन सुरक्षित रूप से संचार करने के लिए एन्क्रिप्शन आवश्यक है। यदि आपका डेटा एन्क्रिप्टेड नहीं है, तो कोई भी इसका विश्लेषण कर सकता है और संवेदनशील जानकारी पढ़ सकता है।

सबसे सुरक्षित एन्क्रिप्शन विधि है असममित एन्क्रिप्शन. इसके लिए 2 कुंजी, 1 सार्वजनिक और 1 निजी की आवश्यकता होती है। ये जानकारी वाली फ़ाइलें हैं, जो अक्सर बहुत बड़ी संख्या में होती हैं। तंत्र जटिल है, लेकिन सीधे शब्दों में कहें तो, आप डेटा को एन्क्रिप्ट करने के लिए सार्वजनिक कुंजी का उपयोग कर सकते हैं, लेकिन इसे डिक्रिप्ट करने के लिए आपको एक निजी कुंजी की आवश्यकता होगी। दोनों कुंजियाँ एक जटिल गणितीय सूत्र का उपयोग करके जुड़ी हुई हैं जिन्हें हैक करना मुश्किल है।

आप सार्वजनिक कुंजी को एक छेद वाले बंद मेलबॉक्स के स्थान के बारे में जानकारी के रूप में सोच सकते हैं, और निजी कुंजी को मेलबॉक्स खोलने वाली कुंजी के रूप में सोच सकते हैं। जो कोई जानता है कि बक्सा कहां है वह वहां एक पत्र डाल सकता है। लेकिन इसे पढ़ने के लिए व्यक्ति को बॉक्स खोलने के लिए चाबी की जरूरत होती है।

चूँकि असममित एन्क्रिप्शन जटिल गणितीय गणनाओं का उपयोग करता है, इसलिए इसके लिए बहुत सारे कंप्यूटिंग संसाधनों की आवश्यकता होती है। टीएलएस सर्वर और क्लाइंट के बीच संचार को एन्क्रिप्ट करने के लिए केवल सत्र की शुरुआत में असममित एन्क्रिप्शन का उपयोग करके इस समस्या को हल करता है। सर्वर और क्लाइंट को एक एकल सत्र कुंजी पर सहमत होना होगा, जिसका उपयोग वे दोनों डेटा पैकेट को एन्क्रिप्ट करने के लिए करेंगे।

वह प्रक्रिया जिसके द्वारा क्लाइंट और सर्वर एक सत्र कुंजी पर सहमत होते हैं, कहलाती है हाथ मिलाना. यही वह क्षण होता है जब 2 संचार करने वाले कंप्यूटर एक दूसरे से अपना परिचय कराते हैं।

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

टीएलएस हैंडशेक प्रक्रिया काफी जटिल है। नीचे दिए गए चरण सामान्य रूप से प्रक्रिया की रूपरेखा प्रस्तुत करते हैं ताकि आप समझ सकें कि यह सामान्य रूप से कैसे काम करती है।

1. क्लाइंट सर्वर से संपर्क करता है और सुरक्षित कनेक्शन का अनुरोध करता है। सर्वर सिफर की एक सूची के साथ प्रतिक्रिया करता है - एन्क्रिप्टेड कनेक्शन बनाने के लिए एक एल्गोरिदमिक सेट - जिसका वह उपयोग करना जानता है। क्लाइंट सूची की तुलना समर्थित सिफर की सूची से करता है, उपयुक्त सिफर का चयन करता है, और सर्वर को बताता है कि उनमें से कौन सा उपयोग करेगा।
2. सर्वर अपना डिजिटल प्रमाणपत्र प्रदान करता है - तीसरे पक्ष द्वारा हस्ताक्षरित एक इलेक्ट्रॉनिक दस्तावेज़ जो सर्वर की प्रामाणिकता की पुष्टि करता है। प्रमाणपत्र में सबसे महत्वपूर्ण जानकारी सिफर की सार्वजनिक कुंजी है। ग्राहक प्रमाणपत्र की प्रामाणिकता की पुष्टि करता है।
3. सर्वर की सार्वजनिक कुंजी का उपयोग करते हुए, क्लाइंट और सर्वर एक सत्र कुंजी स्थापित करते हैं जिसका उपयोग वे दोनों संचार को एन्क्रिप्ट करने के लिए पूरे सत्र में करेंगे। इसके लिए कई तरीके हैं. क्लाइंट एक मनमाने नंबर को एन्क्रिप्ट करने के लिए सार्वजनिक कुंजी का उपयोग कर सकता है, जिसे बाद में डिक्रिप्ट करने के लिए सर्वर पर भेजा जाता है, और दोनों पक्ष सत्र कुंजी स्थापित करने के लिए उस नंबर का उपयोग करते हैं।

एक सत्र कुंजी केवल एक सतत सत्र के लिए मान्य है। यदि किसी कारण से क्लाइंट और सर्वर के बीच संचार बाधित हो जाता है, तो नई सत्र कुंजी स्थापित करने के लिए एक नए हैंडशेक की आवश्यकता होगी।

टीएलएस 1.2 और टीएलएस 1.2 प्रोटोकॉल की कमजोरियाँ

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

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

टीएलएस 1.3

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

Google Chrome और Firefox ब्राउज़र में TLS 1.3 समर्थन कैसे सक्षम करें

फ़ायरफ़ॉक्स और क्रोम टीएलएस 1.3 का समर्थन करते हैं, लेकिन यह संस्करण डिफ़ॉल्ट रूप से सक्षम नहीं है। कारण यह है कि यह वर्तमान में केवल ड्राफ्ट रूप में मौजूद है।

मोज़िला फ़ायरफ़ॉक्स

अपने ब्राउज़र के एड्रेस बार में about:config टाइप करें। पुष्टि करें कि आप जोखिमों को समझते हैं।

1. फ़ायरफ़ॉक्स सेटिंग्स एडिटर खुल जाएगा।
2. खोज में Security.tls.version.max दर्ज करें
3. वर्तमान मान पर डबल-क्लिक करके मान को 4 में बदलें।

गूगल क्रोम

1. प्रयोग पैनल खोलने के लिए अपने ब्राउज़र के एड्रेस बार में chrome://flags/ टाइप करें।
2. विकल्प #tls13-वेरिएंट ढूंढें
3. मेनू पर क्लिक करें और इसे सक्षम (ड्राफ्ट) पर सेट करें।
4. अपना ब्राउज़र पुनः प्रारंभ करें.

कैसे जांचें कि आपका ब्राउज़र संस्करण 1.2 का उपयोग कर रहा है?

हम आपको याद दिलाते हैं कि संस्करण 1.3 अभी तक सार्वजनिक उपयोग में नहीं है। अगर आप नहीं चाहते
ड्राफ्ट का उपयोग करें, आप संस्करण 1.2 पर बने रह सकते हैं।

यह जांचने के लिए कि आपका ब्राउज़र संस्करण 1.2 का उपयोग कर रहा है, ऊपर दिए गए निर्देशों के समान चरणों का पालन करें और सुनिश्चित करें कि:

• फ़ायरफ़ॉक्स के लिए, Security.tls.version.max मान 3 है। यदि यह कम है, तो वर्तमान मान पर डबल-क्लिक करके इसे 3 में बदलें।
• Google Chrome के लिए: ब्राउज़र मेनू पर क्लिक करें - चुनें समायोजन- चुनना उन्नत सेटिंग दिखाएं- अनुभाग के नीचे जाएँ प्रणालीऔर क्लिक करें प्रॉक्सी सेटिंग खोलें...:

• खुलने वाली विंडो में, सुरक्षा टैब पर क्लिक करें और सुनिश्चित करें कि टीएलएस 1.2 का उपयोग करें फ़ील्ड चेक किया गया है। यदि नहीं, तो इसे जांचें और ओके पर क्लिक करें:

आपके कंप्यूटर को पुनरारंभ करने के बाद परिवर्तन प्रभावी होंगे।

आपके ब्राउज़र के एसएसएल/टीएलएस प्रोटोकॉल संस्करण की जांच करने के लिए एक त्वरित उपकरण

एसएसएल लैब्स ऑनलाइन प्रोटोकॉल वर्जन चेकर टूल पर जाएं। पेज वास्तविक समय में उपयोग किए गए प्रोटोकॉल संस्करण को दिखाएगा, और क्या ब्राउज़र किसी भी कमजोरियों के प्रति संवेदनशील है।

सूत्रों का कहना है: अनुवाद

रूसी कानून की आवश्यकताओं के अनुसार, केवल रूसी क्रिप्टोग्राफ़िक एल्गोरिदम GOST 28147-89, GOST R 34.10-94, GOST R 34.11-94 और GOST R 34.10-2001 के अनुसार स्थापित TLS कनेक्शन के उपयोग को मान्यता दी गई है। इसलिए, यदि आपको GOST एल्गोरिदम के अनुसार एन्क्रिप्शन का उपयोग करने वाली साइटों का उपयोग करने की आवश्यकता है, तो आपको क्रिप्टोप्रो सीएसपी प्रोग्राम स्थापित करना होगा।

विंडोज़ ऑपरेटिंग सिस्टम क्रिप्टोप्रो सीएसपी प्रोग्राम का उपयोग करते हैं - इलेक्ट्रॉनिक हस्ताक्षर उत्पन्न करने और प्रमाणपत्रों के साथ काम करने के लिए क्रिप्टोग्राफ़िक उपयोगिताओं का एक सेट

क्रिप्टोप्रो सीएसपी स्थापित करने के लिए, आधिकारिक वेबसाइट से सामग्री का उपयोग करें:

क्रिप्टोप्रो सीएसपी स्थापित करने के बाद, ब्राउज़र इस प्रोग्राम की उपस्थिति और कार्यक्षमता की जांच करता है।

GOST TLS एन्क्रिप्शन का अनुरोध करने वाली साइटें

यदि कोई साइट GOST TLS एन्क्रिप्शन का अनुरोध करती है, तो ब्राउज़र जाँचता है कि क्रिप्टोप्रो CSP प्रोग्राम स्थापित है या नहीं। यदि प्रोग्राम स्थापित है, तो नियंत्रण उसे स्थानांतरित कर दिया जाता है।

एन्क्रिप्शन का अनुरोध करने वाली साइटों के उदाहरण: www.gosuslugi.ru, डोमेन .gov.ru, .kamgov.ru, .nalog.ru पर साइटें।

यदि साइट सूची में नहीं है, तो अतिरिक्त पुष्टि का अनुरोध किया जाता है। यदि आप साइट पर भरोसा करते हैं और कनेक्शन GOST TLS एन्क्रिप्शन का उपयोग करके किया जाना चाहिए, तो जारी रखें बटन पर क्लिक करें।

नेटवर्क प्रोटोकॉल एसएसएल और टीएलएस क्रिप्टोग्राफिक प्रोटोकॉल हैं जो अनधिकृत पहुंच और प्रेषित डेटा की अखंडता के उल्लंघन के खिलाफ प्रमाणीकरण और सुरक्षा प्रदान करते हैं। एसएसएल/टीएलएस प्रोटोकॉल क्लाइंट या सर्वर साइड पर पहचानकर्ता स्पूफिंग, डेटा के प्रकटीकरण या भ्रष्टाचार को रोकने के लिए डिज़ाइन किए गए हैं। इन उद्देश्यों के लिए, एक विश्वसनीय प्रमाणीकरण विधि का उपयोग किया जाता है, संचार चैनल एन्क्रिप्शन और संदेश अखंडता कोड का उपयोग किया जाता है। एसएसएल/टीएलएस के लिए मानक डिफ़ॉल्ट पोर्ट एचटीटीपीएस के लिए 443, एसएमटीपीएस (ईमेल) के लिए 465, एलडीएपीएस के लिए 636, एनएनटीपीएस के लिए 563, आईआरसीएस (चैट) के लिए 994, पीओपी3एस के लिए 995 है।

एसएसएल प्रोटोकॉल

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

• निजी चैनल. यह सुनिश्चित करता है कि एन्क्रिप्शन कुंजी निर्धारित करने के लिए आवश्यक संवाद के बाद सभी संदेश एन्क्रिप्ट किए गए हैं।
• चैनल प्रमाणित है. प्रमाणीकरण क्लाइंट पक्ष के लिए वैकल्पिक है, लेकिन सर्वर पक्ष के लिए अनिवार्य है।
• चैनल विश्वसनीयता. जब संदेश भेजे जाते हैं, तो मैक का उपयोग करके अखंडता जांच की जाती है।

एसएसएल प्रोटोकॉल सममित और असममित दोनों कुंजी का उपयोग करता है।

एसएसएल प्रोटोकॉल की विशेषताएं और उद्देश्य

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

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

एसएसएल प्रोटोकॉल की मुख्य विशेषताओं में सॉफ़्टवेयर-प्लेटफ़ॉर्म स्वतंत्रता पर ध्यान दिया जाना चाहिए। वर्तमान में, एसएसएल प्रोटोकॉल पर्याप्त सुरक्षा प्रदान नहीं करता है - इसे टीएलएस प्रोटोकॉल द्वारा प्रतिस्थापित किया गया है।

टीएलएस प्रोटोकॉल

टीएलएस प्रोटोकॉल एक क्रिप्टोग्राफ़िक प्रोटोकॉल है जिसका उपयोग इंटरनेट पर विभिन्न नोड्स के बीच सुरक्षित डेटा ट्रांसफर के लिए किया जाता है। इस प्रोटोकॉल का उपयोग वीओआईपी एप्लिकेशन, वेब ब्राउज़र और इंस्टेंट मैसेजिंग एप्लिकेशन में किया जाता है। टीएलएस को एसएसएल 3.0 विनिर्देश के आधार पर लागू किया गया है। प्रोटोकॉल का विकास और विकास IETF द्वारा किया जा रहा है।

टीएलएस प्रोटोकॉल द्वारा प्रदान किए गए मुख्य सुरक्षा उपायों में शामिल हैं:

• संदेश प्रमाणीकरण कोड को सत्यापित करने के लिए कुंजी का उपयोग करना।
• टीएलएस संस्करण को डाउनग्रेड करने या इसे कम सुरक्षित नेटवर्क प्रोटोकॉल से बदलने की संभावना समाप्त हो गई है।
• हैंडशेक संदेश में पार्टियों के बीच आदान-प्रदान किए गए सभी संदेशों का हैश शामिल होता है।
• मैक का उपयोग करके एप्लिकेशन रिकॉर्ड नंबरिंग का उपयोग करना।
• एक छद्म-यादृच्छिक फ़ंक्शन का उपयोग जो इनपुट संदेशों को 2 भागों में विभाजित करता है, जिनमें से प्रत्येक को एक अलग हैश फ़ंक्शन द्वारा संसाधित किया जाता है।

टीएलएस प्रोटोकॉल की विशेषताएं और उद्देश्य

टीएलएस प्रोटोकॉल निम्नलिखित एल्गोरिदम का उपयोग करता है:

• सममित एन्क्रिप्शन के लिए RC4, ट्रिपल DES, SEED, IDEA, आदि।
• प्रमुख प्रमाणीकरण के लिए आरएसए, डीएसए, डिफी-हेलमैन और ईसीडीएसए।
• हैश फ़ंक्शन के लिए MD5, SHA और SHA-256/384।

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

सामान्य तौर पर, एसएसएल/टीएलएस प्रोटोकॉल में क्रिप्टोग्राफी का उपयोग एप्लिकेशन प्रदर्शन को काफी कम कर देता है, लेकिन विश्वसनीय डेटा ट्रांसमिशन सुरक्षा प्रदान करता है। प्रोटोकॉल के लिए क्लाइंट साइड पर वस्तुतः किसी सेटिंग की आवश्यकता नहीं होती है और इसे इंटरनेट पर सबसे आम सुरक्षा प्रोटोकॉल माना जाता है।

टीएलएस हैंडशेक क्या है और यह कैसे काम करता है?

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

प्रोटोकॉल का एक प्रमुख पहलू हाथ मिलाना है। इस लेख में हम इसी बारे में बात करेंगे।

"एसएसएल/टीएलएस हैंडशेक" HTTPS कनेक्शन स्थापित करने के चरण का नाम है। एसएसएल/टीएलएस प्रोटोकॉल से जुड़ा अधिकांश कार्य इसी चरण में किया जाता है। पिछले साल, IETF ने हैंडशेक प्रक्रिया को पूरी तरह से नया रूप देते हुए TLS 1.3 को अंतिम रूप दिया।
लेख दो प्रकार के हैंडशेक को कवर करेगा - टीएलएस 1.2 और टीएलएस 1.3 प्रोटोकॉल के लिए, जिस पर हम अमूर्त स्तर से शुरू करके और धीरे-धीरे विशिष्टताओं में विस्तार से विचार करेंगे:

• क्रिप्टोग्राफ़िक प्रोटोकॉल का समन्वय;
• एसएसएल प्रमाणपत्र का उपयोग करके प्रमाणीकरण;
• सत्र कुंजी पीढ़ी.

टीएलएस हैंडशेक कैसे काम करता है?

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

डायल वार्ता

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

यही कारण है कि टीएलएस हैंडशेक का पहला चरण क्लाइंट और सर्वर के लिए समर्थित क्रिप्टोग्राफ़िक फ़ंक्शंस का चयन करने के लिए उनकी क्षमताओं के बारे में जानकारी का आदान-प्रदान करना है।

एक बार जब क्लाइंट और सर्वर सिफर सूट के उपयोग पर सहमत हो जाते हैं, तो सर्वर क्लाइंट को अपना एसएसएल प्रमाणपत्र भेजता है।

प्रमाणीकरण

प्रमाणपत्र प्राप्त करने के बाद, ग्राहक इसकी प्रामाणिकता की जाँच करता है। यह एक अत्यंत महत्वपूर्ण कदम है. एक सुरक्षित कनेक्शन सुनिश्चित करने के लिए, आपको न केवल डेटा एन्क्रिप्ट करना होगा, बल्कि यह भी सुनिश्चित करना होगा कि यह सही वेबसाइट पर भेजा गया है। एसएसएल/टीएलएस प्रमाणपत्र यह प्रमाणीकरण प्रदान करते हैं, और वे यह कैसे करते हैं यह उपयोग किए गए सिफर सूट पर निर्भर करता है।

सभी विश्वसनीय एसएसएल प्रमाणपत्र एक प्रमाणपत्र प्राधिकारी (सीए) द्वारा जारी किए जाते हैं। एक सीए को भरोसेमंद प्रमाणपत्र जारी करने और मान्य करने के लिए सख्त नियमों का पालन करना चाहिए। आप सीए को एक नोटरी पब्लिक की तरह सोच सकते हैं - इसके हस्ताक्षर का मतलब है कि प्रमाणपत्र में डेटा वास्तविक है।

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

इस बिंदु पर, क्लाइंट अप्रत्यक्ष रूप से जाँचता है कि सर्वर के पास प्रमाणपत्र से जुड़ी निजी कुंजी है या नहीं।

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

यदि एक अलग क्रिप्टोसिस्टम का उपयोग किया जाता है, तो एल्गोरिदम बदल सकता है, लेकिन दूसरे पक्ष की प्रामाणिकता अभी भी सत्यापित की जाएगी।

कुंजी विनिमय

टीएलएस हैंडशेक के अंतिम भाग में एक "सत्र कुंजी" बनाना शामिल है जिसका उपयोग वास्तव में सुरक्षित संचार के लिए किया जाएगा।

सत्र कुंजियाँ "सममित" हैं, जिसका अर्थ है कि एन्क्रिप्शन और डिक्रिप्शन के लिए एक ही कुंजी का उपयोग किया जाता है।

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

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

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

टीएलएस 1.3 तक, जब भी आप किसी साइट पर जाते थे, तो हैंडशेक दोबारा होता था। टीएलएस 1.3 हैंडशेक 0-आरटीटी, या शून्य राउंड-ट्रिप पुनरारंभ समय का समर्थन करता है, जो लौटने वाले आगंतुक के लिए गति को काफी बढ़ाता है।

टीएलएस 1.2 में चरण-दर-चरण हैंडशेक प्रक्रिया

आइए आरएसए का उपयोग करके टीएलएस हैंडशेक पर करीब से नज़र डालें। डिफी-हेलमैन एल्गोरिथम के उपयोग का वर्णन नीचे किया जाएगा।

1. पहले संदेश को "क्लाइंट हैलो" कहा जाता है। यह संदेश क्लाइंट की क्षमताओं को सूचीबद्ध करता है ताकि सर्वर संचार के लिए उपयोग करने के लिए सिफर सुइट का चयन कर सके। संदेश में एक बड़ा, यादृच्छिक रूप से चयनित अभाज्य नंबर भी शामिल है जिसे "क्लाइंट रैंडम नंबर" कहा जाता है।
2. सर्वर विनम्रतापूर्वक "सर्वर हैलो" संदेश के साथ जवाब देता है। वहां यह क्लाइंट को बताता है कि कौन से कनेक्शन पैरामीटर चुने गए हैं और उसका यादृच्छिक रूप से चयनित प्राइम नंबर लौटाता है, जिसे "सर्वर रैंडम नंबर" कहा जाता है। यदि क्लाइंट और सर्वर समान सिफर सुइट साझा नहीं करते हैं, तो कनेक्शन विफल हो जाता है।
3. प्रमाणपत्र संदेश में, सर्वर क्लाइंट को अपनी एसएसएल प्रमाणपत्र श्रृंखला भेजता है, जिसमें लीफ और इंटरमीडिएट प्रमाणपत्र शामिल हैं। एक बार जब ग्राहक उन्हें प्राप्त कर लेता है, तो वह प्रमाणपत्र को सत्यापित करने के लिए कई जाँच करता है। क्लाइंट को यह भी सत्यापित करना होगा कि सर्वर के पास प्रमाणपत्र की निजी कुंजी है, जो कुंजी विनिमय/पीढ़ी प्रक्रिया के दौरान होती है।
4. यह एक वैकल्पिक संदेश है, जो केवल कुछ प्रमुख विनिमय विधियों (जैसे डिफी-हेलमैन) के लिए आवश्यक है, जिसके लिए सर्वर से अतिरिक्त डेटा की आवश्यकता होती है।
5. "सर्वर हैलो हो गया" संदेश क्लाइंट को सूचित करता है कि सर्वर ने डेटा संचारित करना समाप्त कर दिया है।
6. फिर क्लाइंट एक सत्र कुंजी बनाने में भाग लेता है। इस चरण की विशिष्टताएँ मूल हैलो संदेशों में चुनी गई कुंजी विनिमय पद्धति पर निर्भर करती हैं। चूँकि हम आरएसए के बारे में बात कर रहे हैं, क्लाइंट प्री-मास्टर सीक्रेट नामक एक यादृच्छिक बाइट स्ट्रिंग उत्पन्न करेगा, इसे सर्वर की सार्वजनिक कुंजी के साथ एन्क्रिप्ट करेगा, और इसे वापस भेज देगा।
7. "चेंज सिफर स्पेक" संदेश से दूसरे पक्ष को पता चलता है कि सत्र कुंजी उत्पन्न हो गई है और वह एन्क्रिप्टेड कनेक्शन पर स्विच कर सकता है।
8. फिर एक "समाप्त" संदेश भेजा जाता है, जो दर्शाता है कि क्लाइंट की ओर से हैंडशेक पूरा हो गया है। इस क्षण से, कनेक्शन एक सत्र कुंजी से सुरक्षित है। संदेश में डेटा (मैक) शामिल है जिसका उपयोग यह सत्यापित करने के लिए किया जा सकता है कि हैंडशेक के साथ छेड़छाड़ नहीं की गई है।
9. अब सर्वर प्री-मास्टर रहस्य को डिक्रिप्ट करता है और सत्र कुंजी की गणना करता है। फिर यह सूचित करने के लिए एक "चेंज सिफर स्पेक" संदेश भेजता है कि वह एक एन्क्रिप्टेड कनेक्शन पर स्विच कर रहा है।
10. सर्वर नव निर्मित सममित सत्र कुंजी का उपयोग करके एक "समाप्त" संदेश भी भेजता है और संपूर्ण हैंडशेक की अखंडता को सत्यापित करने के लिए चेकसम को सत्यापित करता है।

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

इस बिंदु पर, वेब एप्लिकेशन के पहले बाइट्स (वास्तविक सेवा से संबंधित डेटा - HTML, जावास्क्रिप्ट, आदि) भेजे जा सकते हैं।

टीएलएस 1.3 में चरण-दर-चरण हैंडशेक प्रक्रिया

टीएलएस 1.3 हैंडशेक अपने पूर्ववर्ती की तुलना में काफी छोटा है।

1. टीएलएस 1.2 की तरह, "क्लाइंट हैलो" संदेश हाथ मिलाने की शुरुआत करता है, लेकिन इस बार इसमें बहुत अधिक जानकारी शामिल है। टीएलएस 1.3 ने समर्थित सिफर की संख्या 37 से घटाकर 5 कर दी। इसका मतलब है कि ग्राहक अनुमान लगा सकता है कि किस कुंजी समझौते या एक्सचेंज प्रोटोकॉल का उपयोग किया जाएगा, इसलिए संदेश के अलावा यह अनुमानित प्रोटोकॉल से सार्वजनिक कुंजी का अपना हिस्सा भेजता है।
2. सर्वर "सर्वर हैलो" संदेश के साथ प्रतिक्रिया देगा। 1.2 हैंडशेक की तरह, इस चरण में एक प्रमाणपत्र भेजा जाता है। यदि क्लाइंट ने संलग्न डेटा के साथ एन्क्रिप्शन प्रोटोकॉल का सही अनुमान लगाया है और सर्वर इससे सहमत है, तो बाद वाला सार्वजनिक कुंजी का अपना हिस्सा भेजता है, सत्र कुंजी की गणना करता है और "सर्वर समाप्त" संदेश के साथ ट्रांसमिशन पूरा करता है।
3. अब जब क्लाइंट के पास सभी आवश्यक जानकारी है, तो वह एसएसएल प्रमाणपत्र को सत्यापित करता है और सत्र कुंजी की अपनी प्रतिलिपि की गणना करने के लिए दो सार्वजनिक कुंजी का उपयोग करता है। जब यह हो जाता है, तो यह एक "क्लाइंट समाप्त" संदेश भेजता है।

टीएलएस हैंडशेक का ओवरहेड

ऐतिहासिक रूप से, एसएसएल/टीएलएस के बारे में एक शिकायत यह थी कि इससे सर्वर पर अतिरिक्त ओवरहेड का बोझ बढ़ गया था। इसने अब समाप्त हो चुकी धारणा को प्रभावित किया कि HTTPS, HTTP से धीमा है।

टीएलएस 1.2 से पहले हैंडशेक के लिए बहुत सारे संसाधनों की आवश्यकता होती है और, बड़े पैमाने पर, सर्वर को गंभीरता से लोड किया जा सकता है। यहां तक ​​कि टीएलएस 1.2 हैंडशेक भी धीमा हो सकता है यदि उनमें से कई एक समय में हो रहे हों। प्रमाणीकरण, एन्क्रिप्शन और डिक्रिप्शन महंगी प्रक्रियाएं हैं।

छोटी वेबसाइटों पर यह संभवतः कोई ध्यान देने योग्य मंदी का कारण नहीं बनेगा, लेकिन एंटरप्राइज़ सिस्टम पर जहां हर दिन सैकड़ों हजारों विज़िटर आते हैं, यह एक बड़ी समस्या हो सकती है। हैंडशेक का प्रत्येक नया संस्करण प्रक्रिया को काफी सरल बनाता है: टीएलएस 1.2 दो चरणों को निष्पादित करता है, जबकि टीएलएस 1.3 सिर्फ एक में फिट होता है और 0-आरटीटी का समर्थन करता है।

टीएलएस 1.2 की तुलना में टीएलएस 1.3 हैंडशेक में सुधार

उपरोक्त स्पष्टीकरण में, हाथ मिलाने को दस अलग-अलग चरणों में विभाजित किया गया है। वास्तव में, इनमें से कई चीजें एक साथ घटित होती हैं, यही कारण है कि उन्हें अक्सर एक साथ समूहीकृत किया जाता है और चरण कहा जाता है।

टीएलएस 1.2 हैंडशेक के दो चरण हैं। कभी-कभी अतिरिक्त की आवश्यकता हो सकती है, लेकिन जब मात्रा की बात आती है, तो डिफ़ॉल्ट इष्टतम परिदृश्य होता है।

1.2 के विपरीत, टीएलएस 1.3 हैंडशेक एक चरण में फिट बैठता है, हालांकि इसे डेढ़ कहना अधिक सटीक होगा, लेकिन यह अभी भी टीएलएस 1.2 की तुलना में काफी तेज है।

सिफर सुइट्स की कमी

किसी ने भी डेटा को एन्क्रिप्ट करने के लिए 37 सुइट्स का उपयोग करने का इरादा नहीं किया था, इसी तरह प्रोटोकॉल विकसित हुआ। हर बार एक नया एल्गोरिदम जोड़ा गया, नए संयोजन जोड़े गए, और जल्द ही IANA ने 37 अलग-अलग सिफर सुइट्स को प्रशासित किया।

यह दो कारणों से ख़राब है:

1. यह परिवर्तनशीलता गलत कॉन्फ़िगरेशन की ओर ले जाती है जो इंटरनेट उपयोगकर्ताओं को ज्ञात कारनामों के प्रति असुरक्षित बना देती है।
2. इससे एसएसएल स्थापित करना और अधिक भ्रमित करने वाला हो गया।

IETF ने TLS 1.3 में सबसे सुरक्षित एल्गोरिदम को छोड़कर सभी के लिए समर्थन हटा दिया, जिससे विकल्पों को सीमित करके भ्रम दूर हो गया। विशेष रूप से, कुंजी विनिमय पद्धति का विकल्प हटा दिया गया है। अल्पकालिक डिफी-हेलमैन योजना एक ग्राहक के लिए हैंडशेक के पहले भाग में "क्लाइंट हैलो" के साथ अपनी महत्वपूर्ण जानकारी भेजने का एकमात्र तरीका बन गई। अन्य सभी स्थिर कुंजी विनिमय योजनाओं के साथ-साथ आरएसए एन्क्रिप्शन को पूरी तरह से हटा दिया गया है।

ऐसा कहा जा रहा है कि, टीएलएस 1.3 में एक संभावित एच्लीस हील है।

शून्य राउंड ट्रिप फिर से शुरू करने का समय - 0-आरटीटी

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

0-आरटीटी के सभी लाभों के बावजूद, इसमें कुछ संभावित नुकसान शामिल हैं। यह मोड क्लाइंट को हमलों को दोबारा खेलने के लिए अतिसंवेदनशील बनाता है, जहां एक हमलावर जो किसी तरह एन्क्रिप्टेड सत्र तक पहुंच प्राप्त करने का प्रबंधन करता है, वह क्लाइंट के पहले अनुरोध सहित 0-आरटीटी डेटा प्राप्त कर सकता है, और इसे सर्वर पर वापस भेज सकता है।

हालाँकि, शोषण का उपयोग करना आसान नहीं है। यह जोखिम संभवतः एक अत्यंत उपयोगी सुविधा के लिए भुगतान की जाने वाली एक छोटी सी कीमत है।

सुरक्षा

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

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

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

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

अब आइए देखें कि टीएलएस 1.3 हैंडशेक के ये अपडेट एसएसएल/टीएलएस हैंडशेक के सभी तीन प्रमुख कार्यों में कैसे लागू किए जाएंगे।

टीएलएस हैंडशेक सिफर सुइट्स

सिफर सुइट एल्गोरिदम का एक सेट है जो एक सुरक्षित कनेक्शन के मापदंडों को निर्धारित करता है।

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

टीएलएस 1.2 सिफरसुइट्स

• टीएलएस एक प्रोटोकॉल है.
• ECDHE एक प्रमुख विनिमय एल्गोरिदम है।
• ईसीडीएसए एक प्रमाणीकरण एल्गोरिदम है।
• एईएस 128 जीसीएम एक सममित एन्क्रिप्शन एल्गोरिदम है।
• SHA256 एक हैशिंग एल्गोरिदम है।

उपरोक्त उदाहरण कुंजी विनिमय के लिए क्षणिक एलिप्टिक कर्व डिफी-हेलमैन (डीएच) प्रणाली और प्रमाणीकरण के लिए एलिप्टिक कर्व डिजिटल हस्ताक्षर एल्गोरिदम का उपयोग करता है। प्रमाणीकरण करने के लिए डीएच को आरएसए (डिजिटल हस्ताक्षर एल्गोरिदम के रूप में कार्य करना) के साथ भी जोड़ा जा सकता है।

यहां सबसे व्यापक रूप से समर्थित टीएलएस 1.2 सिफर सुइट्स की सूची दी गई है:

टीएलएस 1.3 सिफर सुइट्स

• टीएलएस एक प्रोटोकॉल है.
• एईएस 256 जीसीएम संलग्न डेटा (एईएडी) के साथ एक प्रमाणित एन्क्रिप्शन एल्गोरिदम है।
• SHA384 हैश कुंजी जनरेशन फ़ंक्शन एल्गोरिदम (HKFD) है।

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

उपरोक्त उदाहरण से, आप देख सकते हैं कि AES (उन्नत एन्क्रिप्शन स्टैंडर्ड) का उपयोग बड़ी मात्रा में डेटा को एन्क्रिप्ट करने के लिए किया जाता है। यह 256-बिट कुंजियों का उपयोग करके गैलोज़ काउंटर मोड में काम करता है।

यहां पांच सिफर सुइट्स हैं जो टीएलएस 1.3 में समर्थित हैं:

• TLS_AES_256_GCM_SHA384;
• TLS_CHACHA20_POLY1305_SHA256;
• TLS_AES_128_GCM_SHA256;
• TLS_AES_128_CCM_8_SHA256;
• TLS_AES_128_CCM_SHA256.

टीएलएस 1.2 की तुलना में टीएलएस 1.3 में क्या बदलाव आया है?

यह याद रखना महत्वपूर्ण है कि संस्करण 1.3 को सुरक्षा और प्रदर्शन सुधारों को ध्यान में रखकर डिज़ाइन किया गया था। इसे प्राप्त करने के लिए, टीएलएस 1.3 में कुंजी पीढ़ी एल्गोरिथ्म को फिर से डिजाइन किया गया और ज्ञात कमजोरियों को ठीक किया गया।

टीएलएस 1.3 हैंडशेक कुछ प्रक्रियाओं में भी सुधार करता है, जैसे संदेश प्रमाणीकरण और डिजिटल हस्ताक्षर।

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

टीएलएस हैंडशेक में प्रमाणीकरण

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

दूसरे शब्दों में, आरएसए टीएलएस हैंडशेक ईसीडीएच टीएलएस हैंडशेक से अलग है।

आरएसए अभाज्य गुणनखंडन और मॉड्यूलर अंकगणित का उपयोग करता है। बड़ी अभाज्य संख्याओं की गणना करने के लिए बहुत अधिक CPU शक्ति की आवश्यकता होती है और इन्हें ढूँढना कठिन होता है।

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

इतिहास में एक संक्षिप्त भ्रमण इस बात को स्पष्ट कर सकता है।

1976 में, व्हिटफील्ड डिफी और मार्टिन हेलमैन ने राल्फ मर्कले के काम के आधार पर एक प्रमुख एक्सचेंज प्रोटोकॉल बनाया, जिसका नाम, दोनों के अनुसार, प्रोटोकॉल के नाम में भी दिखाई देना चाहिए।

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

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

यह रॉन रिवेस्ट (आरएसए में आर) थे जिन्होंने यह अवधारणा बनाई जो अंततः आरएसए क्रिप्टोसिस्टम बन गई।

कई मायनों में, आरएसए डीएच का आध्यात्मिक उत्तराधिकारी है। यह कार्यान्वित होता है:

• प्रमुख पीढ़ी;
• कुंजी विनिमय;
• कूटलेखन;
• डिक्रिप्शन।

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

जबकि आरएसए प्रमाणीकरण और कुंजी विनिमय को संभालता है, डिफी-हेलमैन केवल कुंजी विनिमय की सुविधा देता है। डीएच परिवार के चार सामान्य प्रकार हैं:

• डिफी-हेलमैन (डीएच);
• अल्पकालिक (अल्पकालिक) डिफी-हेलमैन (डीएचई);
• अण्डाकार वक्र डिफी-हेलमैन (ईसीडीएच);
• अण्डाकार वक्र क्षणिक डिफी-हेलमैन (ईसीडीएचई)।

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

टीएलएस 1.2 हैंडशेक में प्रमाणीकरण

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

दूसरी ओर, यदि डिफी-हेलमैन प्रमाणीकरण नहीं करता है, तो यह क्या करता है? जैसा कि ऊपर उल्लेख किया गया है, प्रमाणीकरण और कुंजी विनिमय प्रदान करने के लिए डीएच का उपयोग अक्सर अण्डाकार वक्र क्रिप्टोग्राफी के संयोजन में किया जाता है।

एलिप्टिक क्रिप्टोग्राफी (ईसीसी) में बहुत छोटे कुंजी आकार होते हैं जो उस एलिप्टिक वक्र में फिट होते हैं जिस पर यह आधारित है। इस संदर्भ में पाँच उपयुक्त वक्र हैं:

• 192 बिट्स;
• 224 बिट्स;
• 256 बिट;
• 384 बिट;
• 521 बिट्स.

लेकिन ईसीसी सार्वजनिक/निजी कुंजी और आरएसए कुंजी के बीच यही एकमात्र अंतर नहीं है। टीएलएस हैंडशेक के दौरान उनका उपयोग दो पूरी तरह से अलग-अलग उद्देश्यों के लिए किया जाता है।

आरएसए में, सार्वजनिक/निजी कुंजी जोड़ी का उपयोग सर्वर प्रमाणीकरण और सममित सत्र कुंजी विनिमय दोनों के लिए किया जाता है। वास्तव में, यह प्री-मास्टर सीक्रेट का सफल उपयोग है जो सर्वर को प्रमाणित करता है।

डिफी-हेलमैन के साथ, सार्वजनिक/निजी कुंजी जोड़ी का उपयोग सममित सत्र कुंजी का आदान-प्रदान करने के लिए नहीं किया जाता है। जब डिफी-हेलमैन शामिल होता है, तो निजी कुंजी वास्तव में संलग्न हस्ताक्षर एल्गोरिदम (ईसीडीएसए या आरएसए) से जुड़ी होती है।

आरएसए प्रमाणीकरण

आरएसए प्रमाणीकरण प्रक्रिया कुंजी विनिमय प्रक्रिया से संबंधित है। अधिक सटीक रूप से, कुंजी विनिमय प्रमाणीकरण प्रक्रिया का हिस्सा है।

जब किसी क्लाइंट को सर्वर का एसएसएल प्रमाणपत्र प्रस्तुत किया जाता है, तो वह कई संकेतकों की जांच करता है:

• सार्वजनिक कुंजी का उपयोग करके डिजिटल हस्ताक्षर;
• यह सुनिश्चित करने के लिए एक प्रमाणपत्र श्रृंखला कि प्रमाणपत्र ट्रस्ट स्टोर में रूट प्रमाणपत्रों में से एक से आता है;
• समाप्ति तिथि यह सुनिश्चित करने के लिए कि यह समाप्त नहीं हुई है;
• प्रमाणपत्र निरस्तीकरण की स्थिति.

यदि ये सभी जाँचें उत्तीर्ण हो गई हैं, तो अंतिम परीक्षण किया जाता है - क्लाइंट सर्वर की सार्वजनिक कुंजी का उपयोग करके प्री-मास्टर रहस्य को एन्क्रिप्ट करता है और भेजता है। कोई भी सर्वर किसी भी एसएसएल/टीएलएस प्रमाणपत्र को अपना मानने का प्रयास कर सकता है। आख़िरकार, ये सार्वजनिक प्रमाणपत्र हैं। और इसलिए क्लाइंट निजी कुंजी को "क्रियाशील" देखकर सर्वर को प्रमाणित कर सकता है।

इस प्रकार, यदि सर्वर प्री-मास्टर रहस्य को डिक्रिप्ट कर सकता है और सत्र कुंजी की गणना करने के लिए इसका उपयोग कर सकता है, तो उसे पहुंच प्राप्त हो जाती है। यह सत्यापित करता है कि सर्वर उपयोग की जा रही सार्वजनिक/निजी कुंजी जोड़ी का स्वामी है।

डीएच प्रमाणीकरण

जब डिफी-हेलमैन और ईसीडीएसए/आरएसए का उपयोग किया जाता है, तो प्रमाणीकरण और कुंजी विनिमय एक साथ काम करते हैं। और यह हमें चाबियों और उनके उपयोगों पर वापस लाता है। आरएसए सार्वजनिक/निजी कुंजी का उपयोग कुंजी विनिमय और प्रमाणीकरण दोनों के लिए किया जाता है। डीएच+ईसीडीएसए/आरएसए में, असममित कुंजी जोड़ी का उपयोग केवल डिजिटल हस्ताक्षर या प्रमाणीकरण चरण के लिए किया जाता है।

जब ग्राहक प्रमाणपत्र प्राप्त करता है, तब भी वह मानक जाँच करता है:

• प्रमाणपत्र पर हस्ताक्षर सत्यापित करता है,
• प्रमाणपत्रों की शृंखला,
• वैधता,
• समीक्षा स्थिति.

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

टीएलएस 1.3 हैंडशेक में प्रमाणीकरण

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

• आरएसए (केवल हस्ताक्षर),
• एलिप्टिक कर्व डिजिटल सिग्नेचर एल्गोरिथम (ईसीडीएसए),
• एडवर्ड्स डिजिटल सिग्नेचर एल्गोरिथम (EdDSA)।

टीएलएस 1.2 हैंडशेक के विपरीत, टीएलएस 1.3 हैंडशेक का प्रमाणीकरण भाग कुंजी एक्सचेंज से संबद्ध नहीं है। बल्कि, इसे कुंजी विनिमय और संदेश प्रमाणीकरण के समानांतर संसाधित किया जाता है।

हैंडशेक की अखंडता को सत्यापित करने के लिए एक सममित मैक सर्किट चलाने के बजाय, सर्वर संपूर्ण डिक्रिप्शन हैश पर हस्ताक्षर करता है जब वह साझा कुंजी के अपने हिस्से के साथ "सर्वर हैलो" लौटाता है।

क्लाइंट "सर्वर हैलो" से पारित सभी जानकारी प्राप्त करता है और एसएसएल/टीएलएस प्रमाणपत्र प्रमाणीकरण जांच की एक मानक श्रृंखला निष्पादित करता है। इसमें प्रमाणपत्र पर हस्ताक्षर की जांच करना और फिर डिक्रिप्शन हैश में जोड़े गए हस्ताक्षर की जांच करना शामिल है।

एक मिलान यह पुष्टि करता है कि सर्वर के पास गुप्त कुंजी है।

टीएलएस हैंडशेक में मुख्य आदान-प्रदान

यदि आप इस खंड के मुख्य विचार पर प्रकाश डालें, तो यह इस प्रकार लगेगा:

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

यदि यह अब थोड़ा अमूर्त लगता है, तो इस खंड के अंत तक यह सब स्पष्ट हो जाना चाहिए।

आरएसए कुंजी एक्सचेंज

इसे आरएसए कुंजी एक्सचेंज कहना वास्तव में एक मिथ्या नाम है। यह वास्तव में RSA एन्क्रिप्शन है. आरएसए सत्र कुंजी बनाने के लिए असममित एन्क्रिप्शन का उपयोग करता है। डीएच के विपरीत, सार्वजनिक/निजी कुंजी जोड़ी एक बड़ी भूमिका निभाती है।

यहां बताया गया है कि यह कैसे होता है:

1. एक्सऔर य
2. ग्राहक उत्पन्न करता है पूर्व-मास्टर रहस्य(ए) और फिर इसे एन्क्रिप्ट करने और सर्वर पर भेजने के लिए सर्वर की सार्वजनिक कुंजी का उपयोग करता है।
3. सर्वर डिक्रिप्ट करता है पूर्व-मास्टर रहस्यसंबंधित निजी कुंजी का उपयोग करना। अब दोनों पक्षों के पास सभी तीन इनपुट चर हैं और एक मास्टर कुंजी बनाने के लिए उन्हें कुछ छद्म यादृच्छिक कार्यों (पीआरएफ) के साथ मिलाएं।
4. दोनों पक्ष मास्टर कुंजी को और भी अधिक पीआरएफ के साथ मिलाते हैं और मिलान सत्र कुंजी प्राप्त करते हैं।

डीएच कुंजी एक्सचेंज

यहां बताया गया है कि ईसीडीएच कैसे काम करता है:

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

एक मॉड्यूलो प्रॉपर्टी है जो कहती है कि प्रत्येक पक्ष को समान मूल्य प्राप्त होगा, जो कनेक्शन के दौरान सममित एन्क्रिप्शन के लिए उपयोग की जाने वाली कुंजी होगी।

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

अब जब हमने जान लिया है कि डीएच आरएसए से कैसे भिन्न है, तो आइए देखें कि डीएच-आधारित टीएलएस 1.2 हैंडशेक कैसा दिखता है।

फिर, इन दोनों दृष्टिकोणों के बीच कई समानताएँ हैं। हम कुंजी विनिमय के लिए ईसीडीएचई और प्रमाणीकरण के लिए ईसीडीएसए का उपयोग करेंगे।

1. आरएसए की तरह, क्लाइंट "क्लाइंट हैलो" संदेश से शुरू होता है, जिसमें सिफरसुइट्स की सूची के साथ-साथ क्लाइंट की यादृच्छिक संख्या भी शामिल होती है।
2. सर्वर अपने "सर्वर हैलो" संदेश के साथ प्रतिक्रिया करता है, जिसमें चयनित सिफर सुइट और सर्वर का यादृच्छिक नंबर शामिल होता है।
3. सर्वर अपना एसएसएल प्रमाणपत्र भेजता है। आरएसए टीएलएस हैंडशेक की तरह, क्लाइंट प्रमाणपत्र की प्रामाणिकता पर जांच की एक श्रृंखला निष्पादित करेगा, लेकिन चूंकि डीएच स्वयं सर्वर को प्रमाणित नहीं कर सकता है, इसलिए एक अतिरिक्त तंत्र की आवश्यकता है।
4. प्रमाणीकरण करने के लिए, सर्वर क्लाइंट और सर्वर के यादृच्छिक नंबर, साथ ही डीएच पैरामीटर लेता है जिसका उपयोग सत्र कुंजी की गणना करने के लिए किया जाएगा, और उन्हें अपनी निजी कुंजी के साथ एन्क्रिप्ट करता है। परिणाम एक डिजिटल हस्ताक्षर के रूप में कार्य करेगा: ग्राहक हस्ताक्षर को सत्यापित करने के लिए सार्वजनिक कुंजी का उपयोग करेगा और सर्वर कुंजी जोड़ी का असली मालिक है, और अपने स्वयं के डीएच पैरामीटर के साथ जवाब देगा।
5. सर्वर इस चरण को "सर्वर हैलो हो गया" संदेश के साथ समाप्त करता है।
6. आरएसए के विपरीत, क्लाइंट को असममित एन्क्रिप्शन का उपयोग करके सर्वर पर प्री-मास्टर सीक्रेट भेजने की आवश्यकता नहीं होती है, इसके बजाय, क्लाइंट और सर्वर प्री-मास्टर सीक्रेट प्राप्त करने के लिए पहले एक्सचेंज किए गए डीएच पैरामीटर का उपयोग करते हैं; फिर हर कोई उसी सत्र कुंजी को प्राप्त करने के लिए पूर्व-मास्टर रहस्य का उपयोग करता है जिसकी उन्होंने गणना की थी।
7. क्लाइंट दूसरे पक्ष को सूचित करने के लिए "चेंज सिफर स्पेक" संदेश भेजता है कि वह एन्क्रिप्शन पर स्विच कर रहा है।
8. क्लाइंट यह इंगित करने के लिए एक अंतिम "समाप्त" संदेश भेजता है कि उसने हैंडशेक का अपना हिस्सा पूरा कर लिया है।
9. इसी तरह, सर्वर एक "चेंज सिफर स्पेक" संदेश भेजता है।
10. हैंडशेक सर्वर से "समाप्त" संदेश के साथ समाप्त होता है।

आरएसए की तुलना में डीएचई के लाभ

दो मुख्य कारण हैं कि क्रिप्टोग्राफर समुदाय आरएसए की तुलना में डीएचई का उपयोग करना पसंद करता है: पूर्ण फॉरवर्ड गोपनीयता और ज्ञात कमजोरियाँ।

उत्तम आगे की गोपनीयता

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

आरएसए कुंजी एक्सचेंज भेद्यता

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

यही कारण है कि टीएलएस 1.3 में आरएसए को डीएचई के पक्ष में हटा दिया गया था।

टीएलएस 1.3 हैंडशेक में मुख्य विनिमय

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

आरएसए एकमात्र प्रमुख विनिमय योजना नहीं थी जिसे टीएलएस 1.3 में हटा दिया गया था। गैर-क्षणिक डिफी-हेलमैन योजनाओं को भी समाप्त कर दिया गया, जैसा कि अपर्याप्त रूप से सुरक्षित डिफी-हेलमैन मापदंडों की सूची थी।

अपर्याप्त रूप से सुरक्षित सेटिंग्स से आपका क्या तात्पर्य है? बहुत अधिक गणित में जाए बिना, डिफी-हेलमैन और अधिकांश सार्वजनिक कुंजी क्रिप्टोसिस्टम की जटिलता असतत लघुगणक समस्याओं को हल करने की जटिलता है। यदि इनपुट पैरामीटर (क्लाइंट और सर्वर यादृच्छिक संख्या) अज्ञात हैं तो क्रिप्टोसिस्टम को गणना करने के लिए पर्याप्त जटिल होना चाहिए, अन्यथा पूरी योजना बेकार हो जाएगी। डिफी-हेलमैन योजनाएं, जो पर्याप्त बड़े पैरामीटर प्रदान नहीं कर सकीं, टीएलएस 1.3 में समाप्त कर दी गईं।

1. टीएलएस 1.3 हैंडशेक की शुरुआत में, यह जानते हुए कि डीएचई कुंजी समझौता योजना का उपयोग किया जाएगा, क्लाइंट अपने "क्लाइंट हैलो" संदेश में इच्छित कुंजी विनिमय योजना के आधार पर साझा कुंजी के अपने हिस्से को शामिल करता है।
2. सर्वर यह जानकारी प्राप्त करता है और, यदि क्लाइंट सही है, तो सार्वजनिक कुंजी का अपना हिस्सा "सर्वर हैलो" में लौटा देता है।
3. क्लाइंट और सर्वर सत्र कुंजी की गणना करते हैं।

यह बहुत कुछ वैसा ही है जैसा टीएलएस 1.2 हैंडशेक में डीएच के साथ होता है, सिवाय इसके कि टीएलएस 1.3 में कुंजी विनिमय पहले होता है।

निष्कर्ष के बजाय

एसएसएल/टीएलएस हैंडशेक एक आकर्षक प्रक्रिया है जो सुरक्षित इंटरनेट की कुंजी है, फिर भी यह इतनी जल्दी और निर्बाध रूप से होता है कि ज्यादातर लोग इसके बारे में कभी सोचते भी नहीं हैं।

कम से कम जब तक कुछ गलत न हो जाए.

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

एसएसएल टीएलएस प्रोटोकॉल

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

एसएसएल त्रुटि

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

टीएलएस त्रुटि

टीएलएस त्रुटिकई मामलों में यह प्रोटोकॉल समर्थन की कमी का संकेत भी दे सकता है। लेकिन... आइए देखें कि इस मामले में क्या किया जा सकता है।

एसएसएल और टीएलएस प्रोटोकॉल समर्थन

इसलिए, जब आप किसी एसएसएल-सुरक्षित वेबसाइट पर जाने के लिए माइक्रोसॉफ्ट इंटरनेट एक्सप्लोरर का उपयोग करते हैं, तो शीर्षक बार प्रदर्शित होता है सुनिश्चित करें कि एसएसएल और टीएलएस प्रोटोकॉल सक्षम हैं. सबसे पहले, आपको इंटरनेट एक्सप्लोरर में टीएलएस 1.0 प्रोटोकॉल के लिए समर्थन सक्षम करना होगा।

यदि आप ऐसी वेबसाइट पर जा रहे हैं जो इंटरनेट सूचना सेवा 4.0 या उच्चतर चलाती है, तो टीएलएस 1.0 का समर्थन करने के लिए इंटरनेट एक्सप्लोरर को कॉन्फ़िगर करने से आपके कनेक्शन को सुरक्षित करने में मदद मिलती है। बेशक, बशर्ते कि आप जिस दूरस्थ वेब सर्वर का उपयोग करने का प्रयास कर रहे हैं वह इस प्रोटोकॉल का समर्थन करता हो।

मेनू में ऐसा करने के लिए सेवाटीम का चयन इंटरनेट विकल्प.

टैब पर इसके अतिरिक्तअध्याय में सुरक्षा, सुनिश्चित करें कि निम्नलिखित चेकबॉक्स चयनित हैं:

• एसएसएल 2.0 का प्रयोग करें
• एसएसएल 3.0 का प्रयोग करें
• एसएसएल 1.0 का प्रयोग करें

बटन को क्लिक करे आवेदन करना , और तब ठीक है . अपना ब्राउज़र पुनः प्रारंभ करें .

टीएलएस 1.0 सक्षम करने के बाद, वेबसाइट पर दोबारा जाने का प्रयास करें।

सिस्टम सुरक्षा नीति

यदि वे अभी भी होते हैं एसएसएल और टीएलएस के साथ त्रुटियाँयदि आप अभी भी एसएसएल का उपयोग नहीं कर सकते हैं, तो दूरस्थ वेब सर्वर संभवतः टीएलएस 1.0 का समर्थन नहीं करता है। इस स्थिति में, आपको उस सिस्टम नीति को अक्षम करना होगा जिसके लिए FIPS-संगत एल्गोरिदम की आवश्यकता होती है।

ऐसा करने के लिए, में कण्ट्रोल पेनल्सचुनना प्रशासन, और फिर डबल-क्लिक करें स्थानीय सुरक्षा नीति.

स्थानीय सुरक्षा सेटिंग्स में, विस्तृत करें स्थानीय नीतियां, और फिर बटन पर क्लिक करें सुरक्षा सेटिंग्स.

विंडो के दाईं ओर नीति के अनुसार डबल क्लिक करें सिस्टम क्रिप्टोग्राफी: एन्क्रिप्शन, हैशिंग और हस्ताक्षर के लिए FIPS-संगत एल्गोरिदम का उपयोग करें, और फिर बटन पर क्लिक करें अक्षम.

ध्यान!

स्थानीय सुरक्षा नीति पुनः लागू होने पर परिवर्तन प्रभावी होता है। इसे चालू करें और अपने ब्राउज़र को पुनरारंभ करें।

क्रिप्टोप्रो टीएलएस एसएसएल

क्रिप्टोप्रो को अपडेट करें

समस्या को हल करने के विकल्पों में से एक क्रिप्टोप्रो को अपडेट करना है, साथ ही संसाधन को कॉन्फ़िगर करना है। इस मामले में, यह इलेक्ट्रॉनिक भुगतान के साथ काम कर रहा है। प्रमाणन प्राधिकरण पर जाएँ. संसाधन के रूप में इलेक्ट्रॉनिक मार्केटप्लेस का चयन करें।

स्वचालित कार्यस्थल सेटअप प्रारंभ करने के बाद, बस इतना ही शेष रह जाता है प्रक्रिया पूरी होने तक प्रतीक्षा करें, तब ब्राउज़र पुनः लोड करें. यदि आपको संसाधन पता दर्ज करने या चयन करने की आवश्यकता है, तो वह चुनें जिसकी आपको आवश्यकता है। सेटअप पूरा होने पर आपको अपने कंप्यूटर को पुनरारंभ करने की भी आवश्यकता हो सकती है।