TLS असल में HTTPS कनेक्शन को कैसे सुरक्षित करता है?

TLS हैंडशेक, सर्टिफिकेट वेलिडेशन, और की एक्सचेंज का व्यावहारिक विश्लेषण जो HTTPS को वास्तव में सुरक्षित बनाता है।

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

हैंडशेक, चरण दर चरण

जब आपका ब्राउजर https://example.com से कनेक्ट करता है, तो यह मोटे तौर पर क्या होता है (TLS 1.3, जो अधिकांश साइटें अब उपयोग करती हैं):

ClientHello — ब्राउजर समर्थित cipher suites, एक रैंडम nonce, और की एक्सचेंज के लिए एक की शेयर का अनुमान (X25519 या secp256r1 जैसा कुछ उपयोग करके) भेजता है।
ServerHello — सर्वर एक cipher suite चुनता है, अपना की शेयर भेजता है, और अपना सर्टिफिकेट और एक हस्ताक्षर देता है जो यह साबित करता है कि यह उस सर्टिफिकेट से मेल खाती private key रखता है।
की डेरिवेशन — दोनों पक्ष अब स्वतंत्र रूप से अपने की शेयर पर Diffie-Hellman-स्टाइल गणित का उपयोग करके एक ही साझा रहस्य की गणना करते हैं। कोई भी कभी सीक्रेट ट्रांसमिट नहीं करता; यह डेरिव किया जाता है, भेजा नहीं जाता।
Finished संदेश — दोनों पक्ष पूरे हैंडशेक ट्रांसक्रिप्ट पर एक MAC भेज कर यह पुष्टि करते हैं कि हैंडशेक में छेड़छाड़ नहीं हुई।

इसके बाद, सभी कुछ साझा सीक्रेट से प्राप्त सिमेट्रिक की के साथ एन्क्रिप्ट किए जाते हैं, आमतौर पर AES-128-GCM या ChaCha20-Poly1305। TLS 1.3 ने इसे TLS 1.2 के दो-राउंड-ट्रिप हैंडशेक से प्रभावी रूप से एक राउंड ट्रिप तक सीमित कर दिया, जो स्केल पर वास्तविक लेटेंसी जीत है।

सर्टिफिकेट क्यों एन्क्रिप्शन की तुलना में अधिक महत्वपूर्ण है

पहचान सत्यापन के बिना एन्क्रिप्शन व्यर्थ है — कोई भी एक एन्क्रिप्टेड चैनल सेट कर सकता है, एक आक्रमणकारी सहित जो man-in-the-middle चला रहा हो। सर्टिफिकेट वह है जो एक public key को एक डोमेन नाम से जोड़ता है, और यह एक Certificate Authority (CA) द्वारा हस्ताक्षरित होता है जैसे Let's Encrypt या DigiCert।

आपका ब्राउजर root CAs की एक निर्धारित सूची पर विश्वास करता है जो OS या ब्राउजर trust store में बेक किए गए हैं। सर्वर का सर्टिफिकेट मध्यवर्ती certs के माध्यम से इन रूट में से एक तक जाता है। अगर चेन validate नहीं होती, या सर्ट में डोमेन जिसका आपने अनुरोध किया उससे मेल नहीं खाता, तो आपको लाल चेतावनी पृष्ठ मिलता है। यह chain-of-trust मॉडल वास्तविक सिक्योरिटी बाउंड्री है — CA की साइनिंग की चोरी करें और आप किसी भी डोमेन के लिए वैध certs बना सकते हैं, यही कारण है कि CA compromises को प्रमुख घटनाएं माना जाता है।

सिमेट्रिक बनाम असिमेट्रिक क्रिप्टो यहां क्या कर रहा है

Assymmetric क्रिप्टो (RSA या elliptic curve) धीमा और महंगा है, इसलिए TLS इसका उपयोग केवल हैंडशेक के दौरान करता है — सर्वर को प्रमाणित करने और साझा सीक्रेट स्थापित करने में मदद करने के लिए। एक बार जब वह पूरा हो जाता है, तो सभी वास्तविक डेटा (HTML, JSON, जो भी हो) तेज़ सिमेट्रिक ciphers के साथ एन्क्रिप्ट किए जाते हैं। यह हाइब्रिड दृष्टिकोण वही पैटर्न है जो आप SSH, PGP, और अधिकांश वास्तविक-दुनिया क्रिप्टो सिस्टम में देखते हैं: पहचान और की एक्सचेंज के लिए असिमेट्रिक, बल्क डेटा के लिए सिमेट्रिक।

Forward secrecy एक संबंधित विवरण है जो जानने लायक है: क्योंकि साझा सीक्रेट ephemeral Diffie-Hellman की शेयर से आता है जो प्रत्येक सत्र के लिए नए सिरे से उत्पन्न होते हैं, भले ही कोई आपका ट्रैफिक रिकॉर्ड करता है और बाद में सर्वर की private key चोरी करता है, वे अभी भी पुराने सत्रों को डिक्रिप्ट नहीं कर सकते। यह गुण पुराने RSA-केवल की एक्सचेंज में मौजूद नहीं था।

इसे स्वयं जांचना

आपको green padlock icon पर अंधेरे में विश्वास करने की आवश्यकता नहीं है। चलाएं:

openssl s_client -connect example.com:443 -tls1_3

यह आपको negotiated cipher suite, सर्टिफिकेट चेन, और क्या हैंडशेक वास्तव में पूरा हुआ, यह दिखाता है। जो कुछ ब्राउजर देखता है उसके लिए एक तेज़ नज़र के लिए, curl -v https://example.com TLS संस्करण और cert विवरण HTTP प्रतिक्रिया से पहले प्रिंट करता है।

आप Wireshark में अपने स्वयं के ट्रैफिक को डिक्रिप्ट भी कर सकते हैं यदि आप Chrome या Firefox शुरू करने से पहले SSLKEYLOGFILE environment variable निर्यात करते हैं — TLS समस्याओं को डीबग करने के लिए वास्तव में उपयोगी अनुमान लगाने के बजाय।

यह वास्तव में व्यवहार में कहां टूटता है

अधिकांश वास्तविक-दुनिया HTTPS विफलताएं क्रिप्टोग्राफिक breaks नहीं हैं, वे परिचालन हैं: expired certificates, misconfigured मध्यवर्ती chains, पुरानी TLS संस्करणों पर फंसे clients, या mixed content (एक HTTPS पृष्ठ एक HTTP संसाधन लोड कर रहा है)। आधुनिक TLS 1.3 के विरुद्ध वास्तविक protocol-level attacks दुर्लभ हैं क्योंकि spec ने अधिकांश padding oracle और downgrade tricks को बंद कर दिया जो SSL 3.0 और प्रारंभिक TLS को सताते थे। कमजोर बिंदु अब आमतौर पर endpoints हैं — एक compromised CA, एक चोरी की गई private key, या एक उपयोगकर्ता एक सर्टिफिकेट चेतावनी के माध्यम से क्लिक कर रहा है जो उन्हें नहीं करना चाहिए।

अगर आप आगे जाना चाहते हैं, तो Korra Studio के नेटवर्किंग और क्रिप्टोग्राफी सेगमेंट अंतर्निहित Diffie-Hellman गणित और packet-level प्रोटोकॉल विश्लेषण को अधिक गहराई में कवर करते हैं।

AI सहायता से लिखा गया, माइकल पिल्च (CISSP), Korra Studio द्वारा समीक्षित और प्रकाशित।