HTTPS क्या है? TLS एन्क्रिप्शन, प्रमाणपत्र, और विश्वास
स्क्रैपलेस यूनिवर्सल स्क्रैपिंग एपीआई प्रमाणीकृत वेब डेटा अनुरोधों और प्रतिक्रियाओं के लिए HTTPS एंडपॉइंट्स का उपयोग करता है।
TL;DR
- HTTPS HTTP पर TLS है। अनुप्रयोग अर्थशास्त्र HTTP रहते हैं जबकि TLS परिवहन की सुरक्षा करता है।
- एन्क्रिप्शन ट्रांजिट में गोपनीयता की रक्षा करता है। प्रेक्षकों को सामान्य अनुरोध और प्रतिक्रिया सामग्री पढ़ने में सक्षम नहीं होना चाहिए।
- सत्यनिष्ठा संशोधन का पता लगाती है। TLS रिकॉर्ड प्रमाणित होते हैं ताकि परिवर्तित ट्रैफ़िक को अस्वीकार किया जा सके।
- प्रमाणपत्र कुंजियों को पहचान के साथ बाँधते हैं। क्लाइंट्स अनुरोध किए गए होस्ट को प्रमाणपत्र श्रृंखला के खिलाफ मान्य करते हैं।
- HTTPS आवश्यक है, पर्याप्त नहीं। अधिकार, इनपुट मान्यता, भंडारण सुरक्षा, और सुरक्षित अनुप्रयोग डिज़ाइन अभी भी महत्वपूर्ण हैं।
परिचय
HTTPS एक TLS-सुरक्षित कनेक्शन के माध्यम से HTTP है। HTTP विधियाँ, क्षेत्र, स्थिति कोड और सामग्री पहचाने योग्य रहती हैं, जबकि TLS सर्वर की प्रमाणीकरण करता है और ट्रांजिट में निष्क्रिय पढ़ाई और अप्रत्याशित संशोधन के खिलाफ बाइट्स की रक्षा करता है।
पैडलक यह प्रमाणित नहीं करता है कि साइट ई honest है, कनेक्शन समाप्त होने के बाद सुरक्षित है, या एप्लिकेशन बग्स से मुक्त है। यह कहता है कि ब्राउज़र ने इसके विश्वास नियमों के तहत अनुरोधित मूल के लिए स्वीकृत पहचान के साथ एक एन्क्रिप्टेड कनेक्शन स्थापित किया।
TLS हैंडशेक क्या स्थापित करता है
आवेदन डेटा प्रवाह से पहले, क्लाइंट और सर्वर प्रोटोकॉल के पैरामीटर पर बातचीत करते हैं, क्रिप्टोग्राफिक कुंजियों पर सहमति करते हैं, और एक सर्टिफिकेट के साथ सर्वर को प्रमाणित करते हैं। आधुनिक TLS कनेक्शन के लिए ताजा ट्रैफ़िक रहस्य निकालता है बजाय इसके कि नेटवर्क के माध्यम से एक पुन: उपयोग करने योग्य एन्क्रिप्शन कुंजी भेजी जाए।
The TLS 1.3 विनिर्देश हैंडशेक, रिकॉर्ड सुरक्षा और कुंजी अनुसूची को परिभाषित करता है। एक बार स्थापित होने के बाद, कनेक्शन प्रमाणित एन्क्रिप्शन रिकॉर्ड के भीतर सामान्य HTTP संदेश ले जाता है।
सर्टिफिकेट और होस्टनाम सत्यापन
एक प्रमाणपत्र में एक सार्वजनिक कुंजी और पहचान जानकारी होती है जिसे एक श्रृंखला के माध्यम से हस्ताक्षरित किया जाता है जिसे क्लाइंट एक विश्वसनीय मूल से जोड़ सकता है। क्लाइंट वैधता प्रतिबंध, अनुमत कुंजी उपयोग, हस्ताक्षर और यह जांचता है कि अनुरोधित DNS नाम प्रमाणपत्र की पहचानों में प्रकट होता है या नहीं।
एक मान्य हस्ताक्षर अकेला पर्याप्त नहीं है। एक होस्टनेम के लिए जारी किया गया प्रमाणपत्र अलग होस्टनेम को प्रमाणित नहीं करना चाहिए। HTTPS के नियम HTTP अर्थशास्त्र संपर्क किए जा रहे स्रोत के लिए अधिकृत पहुँच और प्रमाण पत्र सत्यापन की आवश्यकता है।
गोपनीयता, अखंडता और प्रमाणीकरण
गोपनीयता सामान्य HTTP सामग्री को एक मार्ग में अवलोकन करने वाले के लिए पढ़ने योग्य नहीं रखती है। अखंडता प्रत्येक अंत बिंदु को परिवर्तित या नकल किए गए रिकॉर्ड का पता लगाने की अनुमति देती है। सर्वर प्रमाणीकरण ग्राहक को यह पुष्टि करने में मदद करता है कि कौन सा स्रोत स्वीकृत प्रमाणपत्र के लिए संबंधित निजी कुंजी रखता है।
ये गुण एक साथ काम करते हैं। प्रमाणीकरण के बिना एन्क्रिप्शन एक हमलावर के लिए निजी चैनल स्थापित कर सकता है। अखंडता के बिना प्रमाणीकरण बाद के संदेशों की सुरक्षा नहीं करेगा। TLS कनेक्शन के लिए उन्हें जोड़ता है, जबकि एप्लिकेशन यह तय करता है कि कौन सा उपयोगकर्ता लॉग इन है और वह उपयोगकर्ता कौन से कार्य कर सकता है।
क्या दिखाई देता है
HTTPS हर नेटवर्क तथ्य को छुपाता नहीं है। IP पतों, पैकेट के आकार, समय और कनेक्शन के अंत बिंदुओं को नेटवर्क के कुछ हिस्सों द्वारा देखा जा सकता है। DNS अलग से सुरक्षित नहीं होने पर दिखाई दे सकता है। एक रिवर्स प्रॉक्सी या लोड बैलेंसर जो TLS को समाप्त करता है, HTTP विनिमय को पढ़ सकता है और अगली कड़ी की सुरक्षा करनी चाहिए।
इस ब्राउज़र ने मूल को उपयोगकर्ता के लिए पते की पट्टी और प्रमाण पत्र की स्थिति के माध्यम से भी उजागर किया है, लेकिन उपयोगकर्ताओं को पैडलॉक को एक प्रतिष्ठा स्कोर के रूप में नहीं मानना चाहिए। एक धोखाधड़ी साइट अपने स्वयं के डोमेन के लिए एक मान्य प्रमाणपत्र प्राप्त कर सकती है। HTTPS नामित मूल के नियंत्रण को प्रमाणित करता है, इसके सामग्री की सत्यता को नहीं।
एप्लिकेशन सुरक्षा अभी भी लागू होती है
TLS SQL इंजेक्शन, टूटी हुई प्राधिकरण, असुरक्षित फ़ाइल हैंडलिंग, प्रतिक्रिया में उजागर रहस्य, या प्रमाणित साइट द्वारा दी गई दुर्भावनापूर्ण JavaScript को ठीक नहीं कर सकता। यह अंत बिंदुओं के बीच के मार्ग की सुरक्षा करता है; यह किसी भी अंत बिंदु पर डेटा का मूल्यांकन नहीं करता।
सुरक्षित परिनियोजन हर जगह HTTPS का उपयोग करते हैं, साधारण HTTP को सावधानी से पुनर्निर्देशित करें, मिश्रित सामग्री से बचें, कुकीज़ को सही ढंग से चिह्नित करें, और सख्त प्राधिकरण लागू करें। MDN परिवहन सुरक्षा मार्गदर्शक ब्राउज़र तैनाती नियंत्रण के साथ प्रोटोकॉल सुरक्षा को जोड़ता है।
HTTPS प्रॉक्सियों और स्वचालन के माध्यम से
कॉर्पोरेट प्रॉक्सियाँ, डिबगिंग टूल्स, और सेवा मेष एक TLS कनेक्शन को समाप्त कर सकते हैं और दूसरा स्थापित कर सकते हैं। यह केवल तब सुरक्षित है जब क्लाइंट स्पष्ट रूप से उस मध्यस्थ पर विश्वास करता है और प्रत्येक होप इच्छित नीति के तहत संचालित होता है। सर्टिफिकेट गलतियों की जांच की जानी चाहिए, उन्हें सुविधा के रूप में अक्षम नहीं किया जाना चाहिए।
स्वचालन क्लाइंट्स को ब्राउज़रों की तरह ही अनुशासन की आवश्यकता होती है: होस्टनामों की पुष्टि करें, वर्तमान ट्रस्ट स्टोर्स का उपयोग करें, एपीआई क्रेडेंशियल्स की रक्षा करें, और संवेदनशील हेडर लॉगिंग से बचें। एक सफल HTTP स्थिति TLS पर पहचान जांच की विफलता का प्रतिफल नहीं देती है।
| सम्पत्ति | HTTPS प्रदान करता है | HTTPS प्रदान नहीं करता |
|---|---|---|
| गोपनीयता | सामान्य HTTP सामग्री को ट्रांजिट में एन्क्रिप्ट करता है | सभी ट्रैफ़िक मेटाडेटा छुपाएँ |
| ईमानदारी | संशोधित TLS रिकॉर्ड का पता लगाता है | व्यापार डेटा मान्य करें |
| सर्वर की पहचान | उत्पत्ति के लिए प्रमाणपत्र की जांच करता है | साइट को विश्वसनीय साबित करें |
| उपयोगकर्ता की पहचान | ऐप्लिकेशन प्रमाणीकरण को सुरक्षित रूप से ले जा सकता है | अधिकार नीति चुनें |
| स्टोरेज | नेटवर्क पर बाइट्स की सुरक्षा करता है | डाटाबेस या लॉग को एन्क्रिप्ट करें |
| ऐप्लिकेशन कोड | प्रमाणित स्रोत से कोड वितरित करता है | सुनिश्चित करें कि कोड सुरक्षित है |
HTTPS क्या है? TLS एन्क्रिप्शन, प्रमाणपत्र और ट्रस्ट मान्यता योजना
HTTPS, TLS पर HTTP है। एप्लिकेशन के अर्थ HTTP पर बने रहते हैं जबकि TLS परिवहन की सुरक्षा करता है। प्रोडक्शन पथ के माध्यम से उस दावे को मान्य करें। छोटे प्रतिनिधि एक्सचेंज से शुरू करें, क्लाइंट और एज पर बातचीत किए गए व्यवहार को रिकॉर्ड करें, और पुष्टि करें कि एप्लिकेशन वही फील्ड्स, फ्रेम्स या इवेंट प्राप्त करता है जो इसे वास्तविक ट्रैफ़िक द्वारा उपयोग किए जाने वाले समान गेटवे, प्रॉक्सी, प्रमाणपत्र समाप्ति बिंदु और नेटवर्क नीति के माध्यम से अपेक्षित होते हैं।
पहले डिजाइन के अनुमान को एक विफलता व्यायाम में बदलें: प्रत्येक प्रोडक्शन रूट को HTTPS पर सेवा दें। फिर दूसरे अनुमान के चारों ओर संसाधन दबाव का परीक्षण करें: हर इच्छित होस्टनाम के लिए मान्य प्रमाणपत्रों का उपयोग करें। एक सही कार्यान्वयन को प्रलेखित सीमाओं के भीतर विफल होना चाहिए, कनेक्शन और बफर स्थिति को रिलीज़ करना चाहिए, और बिना क्रेडेंशियल या निजी पेलोड को उजागर किए बिना परिणाम को समझाने वाला एक ट्रेस छोड़ना चाहिए।
सार्वजनिक वेबसाइटें और सेवा एपीआई डिज़ाइन के विभिन्न भागों का प्रयोग करते हैं, इसलिए संगतता परीक्षण में उन दोनों ट्रैफिक आकारों को शामिल करना चाहिए जहां वे प्रासंगिक हैं। एक वर्तमान ब्राउज़र, एक गैर-ब्राउज़र क्लाइंट, एक धीमा नेटवर्क पथ और सबसे पुराना समर्थित मध्यवर्ती जोड़ें। पसंदीदा पथ और उसके फॉलबैक के लिए संस्करण चयन, कनेक्शन जीवनकाल, संदेश या प्रतिक्रिया आयु, कतार गहराई और समापन कारण रिकॉर्ड करें।
परीक्षण के दौरान अर्थ और परिवहन को अलग परतों के रूप में समीक्षा करें। एक सफल कनेक्शन यह साबित नहीं करता कि एप्लिकेशन ने ऑर्डरिंग, प्राधिकार, निरसन, कैशिंग, पुनःप्रस्तुति, या स्थिति पुनर्प्राप्ति को सही ढंग से संभाला। इसी तरह, एक एप्लिकेशन त्रुटि यह साबित नहीं करती कि बातचीत का प्रोटोकॉल विफल रहा। अवलोकनों को संसाधन, उपयोगकर्ता दायरा, तार्किक ऑपरेशन और कनेक्शन पहचाने नंबर के साथ टैग करें, फिर तुलना करें कि प्रत्येक एंडपॉइंट ने क्या हुआ। यह पृथक्करण क्षमता काम को अधिक उपयोगी बनाता है: टीमें देख सकती हैं कि विलम्ब कनेक्शन सेटअप, नेटवर्क डिलीवरी, कतारबद्ध, एप्लिकेशन प्रोसेसिंग, अनुक्रमिककरण, या धीमे रिसीवर से आया। नियमित टेलीमेट्री से निजी सामग्री को बाहर रखें जबकि पर्याप्त समय और परिणाम डेटा को बनाए रखें ताकि निर्णय की पुनरुत्पत्ति की जा सके।
जहाँ HTTPS क्या है? TLS एन्क्रिप्शन, प्रमाणपत्र और ट्रस्ट प्रकट होता है
सार्वजनिक वेबसाइटें
पृष्ठ सामग्री, कुकीज़, फ़ॉर्म सबमिशन और ब्राउज़र API कॉल को ट्रांज़िट में सुरक्षित करें।
सेवा एपीआई
सेवा के एंडपॉइंट को प्रमाणित करें और तार पर टोकन और पेलोड की सुरक्षा करें।
वेब डेटा वर्कफ़्लो
लक्ष्य URL, कॉन्फ़िगरेशन और एन्क्रिप्टेड API कनेक्शनों के माध्यम से लौटाए गए कंटेंट को ट्रांसमिट करें।
आंतरिक सेवाएं
प्रबंधित प्रमाणपत्रों और गेटवे, कार्यभार और संचालकों के बीच स्पष्ट विश्वास का उपयोग करें।
HTTPS क्या है? TLS एन्क्रिप्शन, प्रमाणपत्र और ट्रस्ट प्रोडक्शन चेकलिस्ट
- प्रत्येक प्रोडक्शन रूट को HTTPS पर सेवा दें। इस बिंदु को एक लिखित स्वीकृति परीक्षण में परिवर्तित करें ताकि समीक्षक इरादा किए गए व्यवहार को आकस्मिक कार्यान्वयन विवरण से भेद कर सकें।
- हर इच्छित होस्टनाम के लिए मान्य प्रमाणपत्रों का उपयोग करें। संरचना की उस सेटिंग का नाम बताएं जो तत्व का मालिक है और उस व्यक्ति या टीम का नाम बताएं जो तब प्रतिक्रिया देती है जब इसका पर्यवेक्षित व्यवहार बदलता है।
- सर्वर ट्रस्ट श्रृंखला को पूरा रखें। लॉग या ट्रेस में प्रासंगिक सिग्नल कैप्चर करें, फिर सत्यापित करें कि सिग्नल वास्तविक पथ में प्रत्येक प्रॉक्सी, गेटवे और सेवा सीमा के माध्यम से जीवित रहता है।
- अनुचित होस्ट इनपुट को प्रतिबिंबित किए बिना HTTP को पुनर्निर्देशन करें। सामान्य मामले, एक धीमे साथी, एक बंद कनेक्शन, एक अत्यधिक आकार के इनपुट, और एक संस्करण या क्षमता असंगति के साथ निर्णय का परीक्षण करें।
- सुरक्षित कुकी गुण सक्षम करें। सुरक्षित डिफ़ॉल्ट और वह सटीक स्थिति जिसे एक अपवाद की अनुमति मिलती है; छिपे हुए अपवाद बाद में परिवर्तनों के दौरान आपसी समस्याएं बन जाते हैं।
- मिश्रित सक्रिय सामग्री को हटा दें। इस व्यवहार की जांच एक प्रतिनिधि ब्राउज़र या क्लाइंट से करें बजाय केवल एक स्थानीय यूनिट परीक्षण या सर्वर-साइड कॉन्फ़िगरेशन स्क्रीन पर निर्भर रहने के।
- न्यूनतम विशेषाधिकार के साथ निजी कुंजियों की सुरक्षा करें। एक सीमित संसाधन सीमा निर्धारित करें और परिणामी अस्वीकृति को संचालनकर्ताओं और कॉल करने वाले एप्लिकेशन के लिए दृश्यमान बनाएं।
- TLS समाप्ति बिंदुओं को खतरे के मॉडल में बनाए रखें। क्लाइंट, एज, एप्लिकेशन, और किसी भी अस्थायी कार्यकर्ता के बीच एक तार्किक एक्सचेंज को सहसंबंधित करने के लिए पर्याप्त पहचानकर्ताओं को बनाए रखें।
- स्वचालन क्लाइंट में प्रमाणपत्र सत्यापन को बनाए रखें। एक ट्रैफ़िक आकार परिवर्तन के बाद विकल्प की समीक्षा करें क्योंकि कनेक्शन की संख्या, पेलोड का आकार, और संदेश की आवृत्ति सही डिज़ाइन को बदल सकते हैं।
- परीक्षा समाप्ति निगरानी और प्रमाणपत्र नवीनीकरण पथ। फाल्बैक पथ को अवलोकनीय और परीक्षण किया जाना चाहिए ताकि संगतता एक पुराने पथ पर निर्भर न हो जो चुपचाप काम करना बंद कर दे।
निष्कर्ष
HTTPS, TLS पर HTTP है। एप्लिकेशन की अर्थवत्ता HTTP रहती है जबकि TLS परिवहन की सुरक्षा करता है। HTTPS आवश्यक है, पर्याप्त नहीं। प्राधिकरण, इनपुट मान्यता, भंडारण सुरक्षा और सुरक्षित एप्लिकेशन डिज़ाइन अब भी महत्वपूर्ण हैं। उन दो तथ्यों को स्पष्ट सीमाओं, अवलोकनीय स्थिति, और एक फाल्बैक के साथ लागू करें जिसे प्रतिनिधि क्लाइंट द्वारा परीक्षण किया गया है न कि कॉन्फ़िगरेशन से मानवीकरण किया गया है।
विश्वसनीय वेब डेटा वर्कफ़्लो बनाने के लिए तैयार हैं?
प्रोटोकॉल निर्णयों को Scrapeless के साथ अवलोकनीय ब्राउज़र और एपीआई वर्कफ़्लो में बदलें।
आज साइन अप करें और प्राप्त करें $5 का मुफ्त क्रेडिट — कोई क्रेडिट कार्ड आवश्यक नहीं.
आपका $5 क्रेडिट प्राप्त करें →अधिकांश प्रश्न
क्या HTTPS का मतलब है कि एक वेबसाइट सुरक्षित है?
नहीं। HTTPS नामित मूल से कनेक्शन की सुरक्षा करता है; यह प्रमाणित नहीं करता कि साइट की सामग्री, व्यवसाय, या आवेदन कोड विश्वसनीय है।
क्या एक इंटरनेट प्रदाता HTTPS पृष्ठ की सामग्री पढ़ सकता है?
एक सामान्य ऑन-पाथ प्रदाता कनेक्शन मेटाडेटा का अवलोकन कर सकता है लेकिन एक विश्वसनीय TLS एंडपॉइंट को नियंत्रित किए बिना सुरक्षित HTTP सामग्री को पढ़ नहीं पाना चाहिए।
SSL और TLS के बीच क्या अंतर है?
TLS वर्तमान प्रोटोकॉल परिवार है। SSL अप्रचलित है, हालांकि SSL प्रमाणपत्र का शब्द अभी भी TLS के साथ उपयोग किए जाने वाले प्रमाणपत्रों के लिए अनौपचारिक रूप से उपयोग किया जाता है।
क्या HTTPS डेटा की सुरक्षा करता है जब यह सर्वर पर पहुंचता है?
नहीं। सर्वर को मेमोरी, लॉग, कतारों, डेटाबेस और डाउनस्ट्रीम सेवाओं में डिक्रिप्टेड डेटा को सुरक्षित रखना होगा।
एक प्रमाणपत्र चेतावनी का मुद्दा क्यों है?
एक प्रमाणपत्र चेतावनी का अर्थ है कि क्लाइंट अपेक्षित पहचान या विश्वास की स्थिति स्थापित नहीं कर सका, इसलिए जारी रखना सत्र को इंटरसेप्शन के जोखिम में डाल सकता है।