कैसे HTTPS कनेक्शन सुरक्षा प्रदान करता है: हर वेब डेवलपर को क्या पता होना चाहिए

HTTPS वैसे भी कैसे काम करता है? यह एक ऐसा प्रश्न है जो मैं अपने कार्य मसौदे में कई दिनों से संघर्ष कर रहा हूं।

एक वेब डेवलपर के रूप में, मैंने महसूस किया कि उपयोगकर्ता डेटा की सुरक्षा के लिए HTTPS का उपयोग करना एक बहुत अच्छा विचार है, लेकिन मुझे कभी भी इस बात की स्पष्ट समझ नहीं थी कि HTTPS वास्तव में कैसे काम करता है।

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

पाइपलाइन

इससे पहले कि हम यह कैसे काम करते हैं, में संक्षेप में बात करते हैं, आइए इस बारे में संक्षेप में बात करें कि इंटरनेट कनेक्शन की सुरक्षा के लिए यह इतना महत्वपूर्ण क्यों है और HTTPS किससे सुरक्षा करता है।

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



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

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

• इसके लिए अधिक कंप्यूटिंग शक्ति की आवश्यकता होती है।
• अधिक डेटा प्रेषित किया जा रहा है।
• आप कैशिंग का उपयोग नहीं कर सकते

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

ट्रांसपोर्ट लेयर सिक्योरिटी (TLS)

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

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

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

1) एक साझा गुप्त कुंजी और प्रमाणीकरण उत्पन्न करने के लिए असममित एन्क्रिप्शन (एक सार्वजनिक-कुंजी क्रिप्टोकरेंसी) (यह सत्यापित करते हुए कि आप वही हैं जो होने का दावा करते हैं)।
2) अनुरोधों और प्रतिक्रियाओं के आगे एन्क्रिप्शन के लिए एक गुप्त कुंजी का उपयोग करके सममित एन्क्रिप्शन ।

सार्वजनिक कुंजी क्रिप्टोकरेंसी

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

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

इसका मतलब है कि यदि कोई ग्राहक और सर्वर के बीच है और कनेक्शन की निगरानी कर रहा है, तो भी वह ग्राहक की निजी कुंजी, सर्वर की निजी कुंजी या सत्र गुप्त कुंजी का पता नहीं लगा सकेगा।

यह कैसे संभव है? मठ!

डिफी-हेलमैन एलगोरिदम

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

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

गणित का एक सा ...

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

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

याद करें कि ऐलिस और बॉब दोनों की अपनी निजी कुंजी (100 अंकों से अधिक) हैं, जो संचार चैनलों के माध्यम से कभी प्रसारित नहीं होती हैं।

निजी कुंजी से प्राप्त मिश्रण मिश्रण , साथ ही साथ प्राइम और रूट के मूल्यों को संचार चैनल के माध्यम से प्रसारित किया जाता है।

इस तरह से:
ऐलिस का मिश्रण = (जड़ ^ ऐलिस सीक्रेट)% प्राइम
बॉब का मिश्रण = (मूल ^ बॉब का रहस्य)% अभाज्य
जहां% विभाजन का शेष भाग है

इस प्रकार, ऐलिस स्वीकृत निरंतर मूल्यों ( रूट और प्राइम ) के आधार पर अपना मिश्रण मिश्रण बनाता है, बॉब ऐसा ही करता है। जैसे ही वे एक दूसरे के मिश्रण मूल्यों को प्राप्त करते हैं, वे सत्र की निजी कुंजी प्राप्त करने के लिए अतिरिक्त गणितीय कार्य करते हैं। अर्थात्:

ऐलिस की गणना
(बॉब का मिश्रण ^ ऐलिस सीक्रेट)% प्राइम

बॉब की गणना
(ऐलिस का मिश्रण ^ बॉब की सीक्रेट)% प्राइम

इन ऑपरेशनों का परिणाम एलिस और बॉब दोनों के लिए समान संख्या है, और यह संख्या इस सत्र के लिए निजी कुंजी बन जाती है। कृपया ध्यान दें कि किसी भी पक्ष को अपनी निजी कुंजी संचार चैनल पर नहीं भेजनी चाहिए थी, और प्राप्त गुप्त कुंजी को भी एक खुले कनेक्शन पर प्रेषित नहीं किया गया था। वाह!

गणितीय रूप से कम समझ रखने वालों के लिए, विकिपीडिया एक बेहतरीन चित्र प्रदान करता है, जो इस प्रक्रिया को एक उदाहरण के रूप में रंग मिश्रण का उपयोग करके समझाता है:



ध्यान दें कि प्रारंभिक रंग (पीला) अंततः बॉब और एलिस दोनों के लिए एक ही "मिश्रित" रंग में कैसे बदल जाता है। केवल एक चीज जो एक खुले संचार चैनल पर प्रसारित होती है, वह आधा मिश्रित रंग है, जो संचार चैनल को सुनने वाले किसी भी व्यक्ति के लिए वास्तव में अर्थहीन है।

सममित एन्क्रिप्शन

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

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

प्रमाणीकरण

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

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

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

लेकिन, वास्तव में, यह प्रमाण पत्र क्या है, और यह हमें सुरक्षा कैसे प्रदान करता है?

प्रमाणपत्र

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

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

ऊपर दिए गए फ़ोन उदाहरण में, हैकर मुझे अपना सार्वजनिक कुंजी दिखाने की कोशिश कर सकता है, मेरे दोस्त के रूप में प्रस्तुत करता है - लेकिन उसके प्रमाण पत्र पर हस्ताक्षर उस व्यक्ति के नहीं होंगे जिस पर मुझे भरोसा है।

प्रमाण पत्र पर भरोसा करने के लिए किसी भी वेब ब्राउज़र के लिए, इसे एक मान्यताप्राप्त प्रमाणन प्राधिकरण (प्रमाणपत्र प्राधिकरण, सीए) द्वारा हस्ताक्षरित होना चाहिए। CA वे कंपनियाँ हैं जो मैन्युअल सत्यापन करती हैं कि प्रमाणपत्र प्राप्त करने का प्रयास करने वाला व्यक्ति निम्नलिखित दो शर्तों को पूरा करता है:

1. वास्तव में विद्यमान है;
2. उस डोमेन तक पहुंच है जिसके लिए वह एक प्रमाण पत्र प्राप्त करने की कोशिश कर रहा है।

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

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



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

प्रमाण पत्र के बारे में जानने के लिए अन्य बातें

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

सामान्य X.509 प्रमाणपत्रों के अलावा, विस्तारित मान्यता प्रमाणपत्र हैं जो उच्च स्तर का विश्वास प्रदान करते हैं। इस तरह का प्रमाण पत्र जारी करने से, CA प्रमाण पत्र प्राप्त करने वाले व्यक्ति पर और भी अधिक जाँच करता है (आमतौर पर पासपोर्ट विवरण या खातों का उपयोग करके)।

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

एक सर्वर पर कई वेबसाइटों की सेवा

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

यदि आप वेब होस्टिंग सेवाओं का उपयोग करते हैं, तो सबसे अधिक संभावना है कि आपको HTTPS का उपयोग करने के लिए एक समर्पित IP पता खरीदना होगा। अन्यथा, आपको साइट के अपडेट होने के बाद लगातार नए प्रमाणपत्र प्राप्त करने होंगे (और उन्हें सत्यापित करना होगा)।

विकिपीडिया पर इस विषय पर बहुत सारे आंकड़े हैं, कौरसेरा पर एक पाठ्यक्रम है। आज सुबह मेरे सवालों के जवाब देने वाले security.stackexchange.com पर चैट से लोगों को विशेष धन्यवाद।

अनुवादक के नोट:

1) विषय पर उत्कृष्ट लिंक के लिए wowkin habrayuzer के लिए धन्यवाद (वीडियो freetonik habrayuzer द्वारा अनुवादित और आवाज दी गई है):



2) टिप्पणियों में विकसित हुई चर्चा के परिणामों के आधार पर (हब्रायुज़र ए 5 बी , फोगी 4 और एलन की भागीदारी के लिए धन्यवाद), मैं निम्नलिखित जानकारी के साथ मुख्य लेख का पूरक हूं:

एक ताजा एसएसएल सर्वेक्षण (2.4 मिलियन एसएसएल साइटों, जून 2013) के आधार पर नेटक्राफ्ट के अनुसार, अधिकांश एसएसएल कनेक्शन परफेक्ट फॉरवर्ड सिक्योरिटी एल्गोरिदम का उपयोग नहीं करते हैं: news.netcraft.com/archives/2013/06/25/ssl-intercepted-today-tecrypted- tomorrow.html

आईई (यहां तक ​​कि संस्करण 10) के मामले में स्थिति विशेष रूप से खराब है, जो केवल अण्डाकार कर्व्स (आरएसए और ईसीडीएसए प्रमाण पत्र) पर डिफी-हेलमैन का समर्थन करता है, या दुर्लभ डीएसई-सर्टिफिकेट (डीएसए) के साथ क्लासिक डिफी-हेलमैन।
नेटक्राफ्ट के अनुमानों के अनुसार, IE और 99% क्रोम, ओपेरा और फ़ायरफ़ॉक्स के लिए 99.7% कनेक्शन डिफी-हेलमैन का उपयोग नहीं करेंगे।

चर्चा में हैकर न्यूज में , यह भी देखा गया था।

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

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