SSL हैंडशेक फेलियर्स क्या है?
स्क्रेपलेस स्क्रैपिंग ब्राउज़र सार्वजनिक-वेब कार्यप्रवाह के लिए प्रबंधित क्लाउड ब्राउज़र में ब्राउज़र सत्र चलाता है जिसमें ब्राउज़र-नेटिव TLS और प्रस्तुत पृष्ठ व्यवहार की आवश्यकता होती है।
TL;DR
- SSL हैंडशेक फेलियर्स का एक सटीक तकनीकी सीमा है। यह विफलता स्थानीय या दूरस्थ हो सकती है। एक ग्राहक सर्वर प्रमाणपत्र को अस्वीकार कर सकता है, एक सर्वर ग्राहक के प्रोटोकॉल प्रस्ताव या प्रमाणपत्र को अस्वीकार कर सकता है, एक लोड बैलेंसर गलत प्रमाणपत्र प्रस्तुत कर सकता है, या एक निरीक्षण प्रॉक्सी विश्वास पथ को बदल सकता है। अनुप्रयोग अनुरोध सामान्यतः HTTP हैंडलर तक नहीं पहुँचता।
- संगत TLS संस्करण नहीं होना एक सामान्य कारण है। एक पुराना ग्राहक केवल अक्षम संस्करणों की पेशकश कर सकता है, या एक सर्वर एक संस्करण पर सीमित हो सकता है जिसे ग्राहक समर्थन नहीं करता। सुरक्षित मरम्मत पुरानी सहयोगी को अपडेट करना है, न कि पुरानी प्रोटोकॉल को आकस्मिक रूप से बहाल करना।
- शब्दावली सुरक्षित अगले कदम को बदलती है। SSL हैंडशेक सामान्य शब्दावली है, लेकिन उत्पादन HTTPS कनेक्शन TLS का उपयोग करते हैं; निदान को बातचीत की गई TLS संस्करण का नाम देना चाहिए और उपलब्ध होने पर अलर्ट करना चाहिए।
- डिवाइस घड़ी की जांच करें। तारीख, समय, और समय क्षेत्र प्रमाणपत्र वैधता जांच के लिए सही होना चाहिए।
- ब्राउज़र ऑटोमेशन में TLS विफलताओं के लिए स्पष्ट वर्गीकरण की आवश्यकता होती है। केवल सार्वजनिक या अधिकृत लक्ष्यों का उपयोग करें और सत्र प्रमाण पत्रों को लॉग से बाहर रखें। एक प्रबंधित ब्राउज़र क्लाइंट पक्ष को मानकीकरण कर सकता है, लेकिन यह लक्ष्यों के अनुमति मॉडल को नहीं बदलता है या एक अमान्य प्रमाणपत्र को विश्वसनीय नहीं बनाता।
एन्क्रिप्शन तभी शुरू हो सकता है जब दोनों सहयोगियों पर सहमति हो।
एक SSL हैंडशेक फेलियर का मतलब है कि ग्राहक और सर्वर HTTPS अनुप्रयोग डेटा बहने से पहले आवश्यक बातचीत को पूरा नहीं कर पाए। आधुनिक प्रोटोकॉल TLS है, लेकिन ब्राउज़र संदेश, पुस्तकालय और सर्वर लॉग अभी भी SSL का उपयोग एक परिचित लेबल के रूप में करते हैं।
हैंडशेक प्रोटोकॉल पैरामीटर का चयन करता है, साझा कुंजी स्थापित करता है, सर्वर को एक प्रमाणपत्र के साथ प्रमाणित करता है, और ग्राहक को प्रमाणित कर सकता है। इन चरणों में किसी भी विफलता से एक सामान्य संदेश उत्पन्न हो सकता है, भले ही मरम्मत अलग हो। प्रमाणपत्र बदलने से प्रोटोकॉल असंगति ठीक नहीं होती है, और पुराने प्रोटोकॉल को सक्षम करने से सुरक्षा कमजोर हो सकती है बिना चोरी हुए प्रमाणपत्र श्रृंखला को संबोधित किए।
निदान को वास्तविक होस्टनाम के साथ कनेक्शन को पुनः उत्पन्न करना चाहिए, नोटिस और प्रमाणपत्र श्रृंखला का अवलोकन करना चाहिए, एक अन्य वर्तमान ग्राहक की तुलना करना चाहिए, और सर्वर-साइड TLS लॉग का निरीक्षण करना चाहिए। लक्ष्य पहले हाथों के संदेश की पहचान करना है जो अपेक्षाओं को पूरा नहीं करता इससे पहले कि क्रिप्टोग्राफिक नीति को बदला जाए।
SSL हैंडशेक फेलियर का प्रत्यक्ष अर्थ
एक SSL हैंडशेक फेलियर तब होता है जब TLS सहयोगी प्रमाणित कुंजी स्थापना को पूरा नहीं कर सकते और एन्क्रिप्टेड सत्र के लिए आवश्यक पैरामीटर पर सहमत नहीं हो सकते। RFC 8446 TLS 1.3 हैंडशेक को एक प्रमाणित कुंजी विनिमय के रूप में परिभाषित करता है जो सत्र कुंजी, वार्ता किए गए पैरामीटर और सहयोगी पहचानें आउटपुट करता है।
यह विफलता स्थानीय या दूरस्थ हो सकती है। एक ग्राहक सर्वर प्रमाणपत्र को अस्वीकार कर सकता है, एक सर्वर ग्राहक के प्रोटोकॉल प्रस्ताव या प्रमाणपत्र को अस्वीकार कर सकता है, एक लोड बैलेंसर गलत प्रमाणपत्र प्रस्तुत कर सकता है, या एक निरीक्षण प्रॉक्सी विश्वास पथ को बदल सकता है। अनुप्रयोग अनुरोध सामान्यतः HTTP हैंडलर तक नहीं पहुँचता।
कहाँ पर एक TLS हैंडशेक रुक सकता है
ग्राहक एक ClientHello के साथ शुरू होता है जो समर्थित संस्करण, क्रिप्टोग्राफिक विकल्प, एक्सटेंशन और अनुरोधित सर्वर नाम ले जाता है। सर्वर संगत पैरामीटर का चयन करता है और अपना ServerHello वापस करता है। यदि कोई स्वीकार्य संस्करण या एल्गोरिदम नहीं है, तो वार्ता यहाँ समाप्त हो सकती है।
फिर सर्वर अपने आप को एक प्रमाणपत्र श्रृंखला और संबंधित निजी कुंजी को रखने के सबूत के साथ प्रमाणित करता है। ग्राहक श्रृंखला, होस्टनाम, वैधता अवधि, हस्ताक्षर नीति, और ट्रस्ट एंकर को मान्य करता है। एक गायब इंटरमीडिएट या गलत होस्टनाम कनेक्शन को HTTP शुरू होने से पहले रोक सकता है।
कुछ सेवाओं के लिए ग्राहक प्रमाणपत्र की आवश्यकता होती है। सर्वर इसे अनुरोध करता है, और ग्राहक को एक उपयुक्त प्रमाणपत्र प्रस्तुत करना चाहिए और निजी कुंजी के कब्जे को साबित करना चाहिए। अंततः, दोनों सहयोगी हैंडशेक ट्रांसक्रिप्ट को सत्यापित करते हैं और ट्रैफिक कुंजी निकालते हैं। इन चरणों के करीब अलर्ट कारण को बातचीत, सर्वर पहचान, ग्राहक पहचान, या अखंडता में संकीर्ण करते हैं।
| हैंडशेक चरण | अपेक्षित परिणाम | विफलता सुराग |
|---|---|---|
| ClientHello | समर्थित संस्करण और विकल्प पेश किए | कोई साझा प्रोटोकॉल, एल्गोरिदम, या आवश्यक एक्सटेंशन नहीं |
| सर्वर पहचान | होस्टनाम के लिए सही प्रमाणपत्र श्रृंखला | अज्ञात जारीकर्ता, गलत नाम,Expiry प्रमाणपत्र |
| ग्राहक पहचान | अनिवार्य होने पर स्वीकार किया गया ग्राहक प्रमाणपत्र | गायब या अविश्वसनीय ग्राहक प्रमाणपत्र |
| समाप्त संदेश | दोनों सहयोगी ट्रांसक्रिप्ट को सत्यापित करते हैं | कुंजी, हस्ताक्षर, या मध्यस्थता विरूपण |
सामान्य SSL हैंडशेक फेल्योर कारण
सबसे उपयोगी श्रेणियाँ संगतता, सर्वर पहचान, होस्टनाम राउटिंग, ग्राहक प्रमाणीकरण, और अवरोधन हैं।
संगत TLS संस्करण नहीं है
एक पुराना ग्राहक केवल अक्षम संस्करणों की पेशकश कर सकता है, या एक सर्वर एक संस्करण पर सीमित हो सकता है जिसे ग्राहक समर्थन नहीं करता। सुरक्षित मरम्मत पुरानी सहयोगी को अपडेट करना है, न कि पुरानी प्रोटोकॉल को आकस्मिक रूप से बहाल करना।
कोई स्वीकार्य क्रिप्टोग्राफिक एल्गोरिदम नहीं
क्लाइंट और सर्वर नीति में कोई साझा सिफर सूट या सिग्नेचर एल्गोरिदम नहीं हो सकता। कॉन्फ़िगर किए गए सेट और आधुनिक प्लेटफ़ॉर्म डिफ़ॉल्ट्स की तुलना करें।
अपूर्ण या अमान्य प्रमाणपत्र श्रृंखला
सर्वर एक मध्यवर्ती प्रमाणपत्र छोड़ सकता है, एक पूर्व विलंबित प्रमाणपत्र प्रस्तुत कर सकता है, या एक श्रृंखला का उपयोग कर सकता है जिसे क्लाइंट विश्वसनीय रूट के लिए नहीं बना सकता।
होस्टनाम के लिए गलत प्रमाणपत्र
एक लोड बैलेंसर या आभासी होस्ट SNI रूटिंग की कमी या गलत कॉन्फ़िगरेशन होने पर एक डिफ़ॉल्ट प्रमाणपत्र का चयन कर सकता है। प्रमाणपत्र तब किसी अन्य साइट का नाम देता है।
क्लाइंट प्रमाणपत्र अस्वीकृत
म्यूचुअल TLS विफल हो सकता है जब क्लाइंट कोई प्रमाणपत्र, गलत प्रमाणपत्र, एक गैर-विश्वसनीय उत्तरदाता भेजता है, या एक प्रमाणपत्र बिना आवश्यक उपयोग के।
निरीक्षण प्रॉक्सी या घड़ी की समस्या
TLS निरीक्षण प्रस्तुत श्रृंखला को बदलता है, जबकि एक गलत उपकरण घड़ी एक वैध प्रमाणपत्र को इसकी वैधता विंडो से बाहर दिखा सकती है।
पहली टूटी हुई हैंडशेक चरण खोजें
सटीक होस्टनाम के साथ पुनः प्रस्तुत करें और प्रोटोकॉल या ट्रस्ट सेटिंग्स को बदलने से पहले दोनों समकक्षों से प्रमाण एकत्र करें।
- सटीक क्लाइंट त्रुटि और सर्वर अलर्ट रिकॉर्ड करें। सामान्य ब्राउज़र शब्दावली पुस्तकालय कोड, TLS अलर्ट और सर्वर लॉग की तुलना में कम उपयोगी है।
- वास्तविक होस्टनाम का उपयोग करें। SNI और होस्टनाम सत्यापन सक्षम होने पर परीक्षण करें; केवल IP द्वारा कनेक्ट करने से एक अलग आभासी होस्ट और प्रमाणपत्र का चयन किया जा सकता है।
- प्रस्तुत श्रृंखला की जांच करें। पत्रक प्रमाणपत्र, मध्यवर्ती क्रम, होस्टनाम नाम, वैधता अवधि, उत्तरदाता, सिग्नेचर, और यह कि श्रृंखला एक विश्वसनीय रूट तक पहुँचती है की पुष्टि करें।
- एक वर्तमान क्लाइंट की तुलना करें। यदि एक आधुनिक ब्राउज़र काम करता है लेकिन एक पुरानी रनटाइम विफल होती है, तो समर्थित TLS संस्करणों, सिग्नेचर एल्गोरिदम और ट्रस्ट स्टोर्स की तुलना करें।
- सर्वर चयन की जांच करें। यह सत्यापित करें कि लोड बैलेंसर, इनग्रेस, और आभासी होस्ट इच्छित प्रमाणपत्र और अनुरोधित नाम के लिए TLS नीति को चुनते हैं।
- क्लाइंट-प्रमाणपत्र नीति की समीक्षा करें। म्यूचुअल TLS के लिए, अनुरोधित उत्तरदाताओं, क्लाइंट प्रमाणपत्र उपयोग, श्रृंखला, और निजी-की पहुँच की जांच करें।
- अधिकार प्राप्त निरीक्षण के चारों ओर और इसके माध्यम से तुलना करें। नेटवर्क प्रशासन के साथ, यह निर्धारित करें कि क्या एक कॉर्पोरेट प्रॉक्सी या सुरक्षा उत्पाद प्रमाणपत्र या हैंडशेक पथ को बदलता है।
हैंडशेक मॉडल में TLS 1.3 विनिर्देश, क्रोम के सुरक्षित कनेक्शन मार्गदर्शिका में क्रोम सुरक्षित-कनेक्शन सहायता, और मोज़िला के प्रमाणपत्र-त्रुटि वर्गीकरण में मोज़िला प्रमाणपत्र-त्रुटि मार्गदर्शिका परामर्श अलगाव को ट्रस्ट विफलताओं से अलग करने में मदद करता है।
उपयोगकर्ताओं के लिए सुरक्षित जाँचें
एक TLS विफलता कनेक्शन की सुरक्षा करती है, इसलिए प्रतिक्रिया को उस सुरक्षा को बनाए रखना चाहिए जबकि स्थानीय स्थितियों को अलग करती है।
- उपकरण घड़ी की जांच करें। प्रमाणपत्र की वैधता जांच के लिए दिनांक, समय, और समय क्षेत्र सही होना चाहिए।
- ब्राउज़र और ऑपरेटिंग सिस्टम अपडेट करें। वर्तमान क्लाइंट आधुनिक प्रोटोकॉल समर्थन और ट्रस्ट-स्टोर अपडेट ले आते हैं।
- एक और विश्वसनीय नेटवर्क की तुलना करें। एक कैद पोर्टल, VPN, या निरीक्षण प्रॉक्सी हैंडशेक और प्रस्तुत प्रमाणपत्र को बदल सकती है।
- अनजान रूट प्रमाणपत्र स्थापित न करें। किसी भी कार्यस्थान या स्कूल प्रमाणपत्र को भरोसा करने से पहले व्यवस्थापक के साथ पुष्टि करें।
सर्वर-साइड TLS मरम्मत
ऑपरेटर को विफल चरण की मरम्मत करनी चाहिए जबकि आधुनिक प्रोटोकॉल और प्रमाणपत्र नीति को सुरक्षित रखे।
पूर्ण इच्छित प्रमाणपत्र श्रृंखला प्रस्तुत करें, इसे सही होस्टनाम से बाँधें, और निजी-की पहुँच की पुष्टि करें। प्रत्येक किनारे क्षेत्र और लोड-बैलेंसर श्रोता का परीक्षण करें क्योंकि एक पुरानी नोड अन्य बेड़े से भिन्न पहचान प्रस्तुत कर सकती है।
समर्थित आधुनिक क्लाइंट और सर्वर एल्गोरिदम की जानबूझकर ओवरलैप रखें। जब एक पुराना रनटाइम विफल होता है, तो इसकी वास्तविक व्यावसायिक आवश्यकता को सूचीबद्ध करें और इसे अपग्रेड करें। पुरानी प्रोटोकॉल या कमजोर एल्गोरिदम को व्यापक संगतता के लिए बहाल करना जोखिम को बढ़ाता है और प्लेटफ़ॉर्म नीति का उल्लंघन कर सकता है।
म्यूचुअल TLS के लिए, स्वीकार किए गए क्लाइंट-इश्यूअर और उपयोग आवश्यकताओं को प्रकाशित करें, अस्वीकृति के कारणों की निगरानी करें, और ओवरले के साथ क्लाइंट सर्टिफिकेट्स को घुमाएं। हाथ मिलाने के मैट्रिक्स को HTTP मैट्रिक्स से अलग रखें क्योंकि असफल TLS सत्र कभी एप्लिकेशन रूट तक नहीं पहुँचते।
हैंडशेक विफलता बनाम सर्टिफिकेट त्रुटि
सर्टिफिकेट सत्यापन एक हाथ मिलाने का चरण है, लेकिन कई हाथ मिलाने की विफलताएँ सर्टिफिकेट ट्रस्ट के पहले या बाहर होती हैं।
| लक्षण | प्राथमिक परत | परीक्षण ध्यान |
|---|---|---|
| SSL हैंडशेक विफलता | TLS बातचीत पूरी नहीं हुई | प्रोटोकॉल, एल्गोरिदम, SNI, सर्टिफिकेट, क्लाइंट प्रमाणीकरण |
| सर्टिफिकेट त्रुटि | प्रस्तुत पहचान ने सत्यापन में विफलता | श्रृंखला, होस्टनेम, समय, इश्यूअर, निरस्तीकरण |
| HTTP 5xx | TLS पूरा हुआ और सर्वर ने HTTP लौटाया | अनुप्रयोग या अपस्ट्रीम सेवा |
| TCP रिसेट | परिवहन अचानक समाप्त हो गया | एंडपॉइंट या मध्यस्थ नेटवर्क पथ |
ब्राउज़र ऑटोमेशन में TLS विफलताएँ
यह स्क्रेपलेस स्क्रेपिंग ब्राउज़र सार्वजनिक-वेब पुनर्प्राप्ति के लिए एक ब्राउज़र वातावरण का उपयोग करता है, जो TLS और रेंडरिंग व्यवहार को ब्राउज़र-आधारित वर्कफ़्लोज़ के साथ संरेखित करता है। एक कार्य को भी लक्षित होस्टनेम, कनेक्शन चरण, ब्राउज़र त्रुटि और अंतिम पृष्ठ मान्यता को रिकॉर्ड करना चाहिए।
ऑटोमेशन को सफल दिखाने के लिए सर्टिफिकेट सत्यापन को बंद न करें। यह सर्वर की पहचान सुनिश्चितता को हटा देता है और क्रेडेंशियल या संग्रहित डेटा को उजागर कर सकता है। यदि एक लक्ष्य में असली सर्टिफिकेट दोष है, तो कार्य को सुरक्षित-कनेक्शन निर्वात विफलता के रूप में वर्गीकृत करें और साइट के मालिक से संपर्क करें।
केवल सार्वजनिक या अधिकृत लक्ष्यों का उपयोग करें और सत्र क्रेडेंशियल को लॉग से बाहर रखें। एक प्रबंधित ब्राउज़र क्लाइंट पक्ष को मानकीकृत कर सकता है, लेकिन यह लक्ष्य की अनुमति मॉडल को नहीं बदलता या अवैध सर्टिफिकेट को विश्वसनीय नहीं बनाता।
हैंडशेक चरण का निदान करें, सामान्य लेबल नहीं
एक SSL हैंडशेक विफलता का मतलब है कि TLS बातचीत एक सुरक्षित एप्लिकेशन सत्र स्थापित होने से पहले समाप्त हो गई। प्रोटोकॉल संगतता, क्रिप्टोग्राफिक नीति, SNI रूटिंग, सर्वर सर्टिफिकेट, क्लाइंट सर्टिफिकेट, और निरीक्षण अलग-अलग चरणों को रोक सकते हैं।
सटीक होस्टनेम के साथ पुन: उत्पन्न करें, अलर्ट और श्रृंखला का निरीक्षण करें, वर्तमान क्लाइंट की तुलना करें, और सर्वर लॉग को सहसंबंधित करें। उस चरण का修Repair करें जबकि सर्टिफिकेट सत्यापन और आधुनिक प्रोटोकॉल नीति सक्षम रखें।
क्या आप सुरक्षित-कनेक्शन विफलताओं को निदान करना आसान बनाने के लिए तैयार हैं?
हैंडशेक सीमा, सर्टिफिकेट के सबूत, अंतिम URL, और रेंडर की गई सामग्री को सुरक्षित-पृष्ठ विफलता के नीचे पहुंचने से पहले कैप्चर करें।
आज साइन अप करें और पाएं $5 का मुफ्त क्रेडिट — कोई क्रेडिट कार्ड आवश्यक नहीं.
अपने $5 क्रेडिट का दावा करें →अक्सर पूछे जाने वाले प्रश्न
क्या SSL हैंडशेक विफलता एक सर्टिफिकेट त्रुटि के समान है?
एक सर्टिफिकेट त्रुटि SSL हैंडशेक विफलता का एक संभावित कारण है, लेकिन बातचीत TLS संस्करण, क्रिप्टोग्राफिक एल्गोरिदम, SNI, क्लाइंट-सर्टिफिकेट, या अखंडता समस्याओं के कारण भी असफल हो सकती है।
क्या गलत सिस्टम समय से हैंडशेक विफलता हो सकती है?
एक गलत घड़ी सर्टिफिकेट को समाप्त या अभी मान्य नहीं दिखा सकती है, जिससे सर्टिफिकेट सत्यापन और हैंडशेक रुक जाता है। गहरे परिवर्तनों से पहले सही तिथि, समय और समय क्षेत्र करें।
क्या त्रुटि को ठीक करने के लिए पुराने TLS संस्करण सक्षम होना चाहिए?
जल्दबाजी में एक त्वरित समाधान के रूप में पुराने TLS संस्करणों को व्यापक रूप से सक्षम न करें। पुराने समकक्ष की पहचान करें और उसे अपडेट करें, फिर सर्वर को एक जानबूझकर आधुनिक संगतता नीति पर रखें।
SNI हैंडशेक विफलता का कारण कैसे बनती है?
SNI साझा सर्वर को बताता है कि क्लाइंट कौन सा होस्टनेम चाहता है। गायब या गलत SNI एक डिफ़ॉल्ट वर्चुअल होस्ट, गलत सर्टिफिकेट, या असंगत TLS नीति का चयन कर सकता है।
क्या एक स्क्रैपर SSL हैंडशेक विफलताओं को नजरअंदाज कर सकता है?
एक स्क्रैपर को हैंडशेक विफलताओं को नजरअंदाज नहीं करना चाहिए या सर्टिफिकेट सत्यापन को बंद नहीं करना चाहिए। इसे सुरक्षित-कनेक्शन त्रुटि को रिकॉर्ड करना चाहिए, परिणाम को निष्कर्षण से बाहर छोड़ना चाहिए, और सर्टिफिकेट या TLS कॉन्फ़िगरेशन को सही करने के बाद एक अधिकृत पथ का उपयोग करना चाहिए।