एचटीटीपीएस मतलब टीएलएस के ऊपर एचटीटीपी। ब्राउज़र (या आपकी सर्विस क्लाइंट) टीसीपी कनेक्शन खोलती है, फिर टीएलएस हैंडशेक चलाती है ताकि दोनों तरफ़ कुंजियाँ तय हों और क्लाइंट जाँच सके कि सर्वर वही है जो दावा करता है। उसके बाद ऐप्लिकेशन बाइट्स (एचटीटीपी/१.१, एचटीटीपी/२, क्विक पर एचटीटीपी/३) रिकॉर्ड लेयर पर एन्क्रिप्टेड चलते हैं।

आपको क्रिप्टो इम्प्लीमेंट करने की ज़रूरत नहीं। हाँ, यह जानना ज़रूरी है कि सर्टिफ़िकेट एक्सपायर होने, एसएएन ग़लत होने, रिवर्स प्रॉक्सी के पीछे एसएनआई न होने, या मिक्स्ड-कंटेंट वॉर्निंग "ठीक" करने के लिए बैकएंड क्लाइंट में वेरिफ़िकेशन बंद करने पर क्या टूटता है। यह पोस्ट वही नक्शा है: हैंडशेक की समझ, सर्टिफ़िकेट, एसएनआई, और स्टेटस पेज व इंसिडेंट चैनल में आने वाले ग़लत कॉन्फ़िग।

टीएलएस १.२ और टीएलएस १.३ वे हैं जो २०२६ में मिलेंगे। पुराने संस्करण बंद होने चाहिए। नीचे का मॉडल टीएलएस १.३ पर केंद्रित है (तार पर सरल), और बताता है कहाँ डिबग में १.२ अभी भी मायने रखता है।

एचटीटीपीएस असल में क्या बचाता है

गुण मोटा मतलब टीएलएस का योगदान
गोपनीयता सुनने वाला पेलोड नहीं पढ़ पाता कुंजी समझौते के बाद सिमेट्रिक एन्क्रिप्शन
अखंडता छेड़छाड़ पकड़ी जाती है एईएडी सिफ़र (एन्क्रिप्ट + प्रमाणित)
सर्वर प्रमाणीकरण क्लाइंट सही होस्ट से बात करता है सर्टिफ़िकेट चेन + होस्टनेम जाँच
क्लाइंट प्रमाणीकरण सर्वर क्लाइंट की पहचान जानता है वैकल्पिक म्यूचुअल टीएलएस (एमटीएलएस)

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

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

डेवलपर के रूप में आप किन परतों को छूते हैं

Application:  HTTP request/response (or gRPC, etc.)
    |
TLS:          handshake, certs, keys, encrypted records
    |
Transport:    TCP (or UDP for QUIC / HTTP/3)
    |
Network:      IP

आम डिप्लॉय आकार:

१. ब्राउज़र → सीडीएन / लोड बैलेंसर टीएलएस खत्म करता है, फिर सादा एचटीटीपी या ओरिजिन तक फिर से एन्क्रिप्टेड टीएलएस। २. सर्विस ए → सर्विस बी मेश या एपीआई गेटवे के अंदर एमटीएलएस के साथ। ३. सीएलआई / एसडीके → पब्लिक एपीआई सिस्टम ट्रस्ट स्टोर + होस्टनेम वेरिफ़िकेशन के साथ।

टीएलएस कहाँ खत्म होता है, सुरक्षा का फ़ैसला है। अगर लोड बैलेंसर डिक्रिप्ट करके पॉड नेटवर्क से एचटीटीपी बात करे, तो उस रास्ते पर कोई भी ट्रैफ़िक पढ़ सकता है। कई टीमें ऐप तक फिर से एन्क्रिप्ट करती हैं ("हर जगह टीएलएस") या मेश साइडकार इस्तेमाल करती हैं। ट्रस्ट बाउंड्री लिखें; यह न मानें कि "एज पर एचटीटीपीएस है" मतलब पूरा रास्ता निजी है।

सर्टिफ़िकेट की बुनियाद (जो रात दो बजे टूटती है)

एक सर्टिफ़िकेट हस्ताक्षरित बयान है: "पब्लिक की पी नाम एन की है, तारीख डी तक, नीति के तहत…" एक सर्टिफ़िकेट अथॉरिटी (सीए) उस पर हस्ताक्षर करती है। आपके क्लाइंट के पास ट्रस्ट स्टोर होता है: रूट (और कभी-कभी इंटरमीडिएट) सीए जिन्हें वह मानता है।

ट्रस्ट की चेन

आम लीफ़ चेन:

Root CA (in trust store)
  → Intermediate CA
      → Leaf (your server: api.example.com)

सर्वर को लीफ़ और आमतौर पर इंटरमीडिएट पेश करने चाहिए। क्लाइंट के पास पहले से रूट है। गायब इंटरमीडिएट क्लासिक बग है: "मेरे लैपटॉप पर चलता है, सीआई और मोबाइल पर नहीं"। डेस्कटॉप ब्राउज़र इंटरमीडिएट कैश करते हैं; कुछ क्लाइंट नहीं।

क्लाइंट क्या जाँचता है (सरलीकृत)

१. चेन भरोसेमंद रूट तक बनती है (हस्ताक्षर सही, अज्ञात गैप नहीं)। २. एक्सपायर नहीं / अभी वैध नहीं (notBefore / notAfter)। ३. होस्टनेम मेल खाता है: डीएनएस एसएएन (सब्जेक्ट अल्टरनेटिव नेम) में वह नाम हो जिससे जुड़े (या वैध वाइल्डकार्ड)। सिर्फ़ सीएन पुराना है; आधुनिक क्लाइंट एसएएन देखते हैं। ४. की यूसेज / एक्सटेंडेड की यूसेज सर्वर ऑथ की अनुमति दें (एमटीएलएस क्लाइंट सर्ट के लिए क्लाइंट ऑथ)। ५. रिवोकेशन (जब लागू हो): सीआरएल, ओसीएसपी, या छोटे जीवन वाले सर्ट। प्लेटफ़ॉर्म पर लागू होना असमान है; "ओसीएसपी स्टेपल नहीं" को "सर्ट हमेशा अच्छा" न मानें, और अपना अधूरा चेक भी न गढ़ें। ६. एंटरप्राइज़ पीकेआई में नेम कंस्ट्रेंट्स और पॉलिसी (पब्लिक वेब पर कम आम)।

इनमें से कोई फेल हो तो टीएलएस लाइब्रेरी रोक देती है। आपकी एचटीटीपी क्लाइंट को बॉडी वाला २०० नहीं मिलता। हैंडशेक एरर मिलता है: CERTIFICATE_VERIFY_FAILED, hostname mismatch, unknown CA, और उनके साथी।

पब्लिक सीए बनाम प्राइवेट सीए बनाम सेल्फ़-साइन्ड

प्रकार उपयोग क्लाइंट ट्रस्ट
पब्लिक सीए (लेट्स एन्क्रिप्ट, कमर्शियल) इंटरनेट-फेसिंग नाम ओएस/ब्राउज़र डिफ़ॉल्ट ट्रस्ट स्टोर
प्राइवेट सीए इंटरनल सर्विस, एमटीएलएस, कॉर्प ऐप आप रूट/इंटरमीडिएट क्लाइंट तक पहुँचाते हैं
सेल्फ़-साइन्ड लीफ़ लोकल डेमो, ब्रेक-ग्लास पिन या वेरिफ़ाई बंद (भूल जाओ तो ख़तरा)

पब्लिक साइटों के लिए पब्लिक सीए लें और रिन्यूअल ऑटोमेट करें (सर्ट-मैनेजर, एसीएमई क्लाइंट, क्लाउड-मैनेज्ड सर्ट)। इंटरनल सर्विस आइडेंटिटी के लिए ऑटोमेशन वाली प्राइवेट सीए (स्पिफ़े/स्पायर, मेश सीए, इंटरनल एसीएमई) बेहतर है बजाय हर रेपो में सेल्फ़-साइन्ड पीईएम कॉपी करने के।

वाइल्डकार्ड और मल्टी-नेम सर्ट

  • *.example.com api.example.com से मेल खाता है, example.com से नहीं, और a.b.example.com से नहीं (सिर्फ़ एक लेबल)।
  • एसएएन में कई नाम हो सकते हैं: www, api, एपेक्स, प्रीव्यू होस्ट।
  • साझा लोड बैलेंसर पर एक सर्ट ठीक है जब एसएनआई और वीहोस्ट कॉन्फ़िग सही नाम पर सही सर्ट लगाएँ।

टीएलएस हैंडशेक की समझ (टीएलएस १.३)

हर फ़्लाइट याद किए बिना डिबग कर सकते हैं। यह कहानी रखें:

१. क्लाइंटहेलो: "मैं टीएलएस १.३ बोलता हूँ, ये सिफ़र सूट पसंद हैं, की एग्रीमेंट के लिए मेरा की शेयर, और सर्वर नाम api.example.com है (एसएनआई)।" २. सर्वरहेलो (+ एन्क्रिप्टेड एक्सटेंशन, सर्ट, सर्ट वेरिफ़ाई, फ़िनिश्ड): सर्वर पैरामीटर चुनता है, अपनी सर्टिफ़िकेट चेन भेजता है, प्राइवेट की रखने का सबूत देता है, और दोनों हैंडशेक व ऐप्लिकेशन ट्रैफ़िक सीक्रेट निकालते हैं। ३. क्लाइंट फ़िनिश्ड (फिर ऐप्लिकेशन डेटा): क्लाइंट सर्ट और सर्वर सबूत जाँचता है, हैंडशेक ट्रांस्क्रिप्ट पुष्टि करता है, फिर दोनों नई कुंजियों से ऐप्लिकेशन डेटा भेजते हैं।

टीएलएस १.३ आमतौर पर १-आरटीटी में खत्म होता है (टीसीपी के बाद क्रिप्टो मैसेज का एक राउंड ट्रिप)। सेशन टिकट / पीएसके रिजंप्शन से ०-आरटीटी डेटा मिल सकता है (रीप्ले जोखिम के साथ: सुरक्षित, आइडेम्पोटेंट अनुरोधों के लिए ही, जब तक जोखिम समझें)।

टीएलएस १.२ में ज़्यादा मैसेज थे (सर्वरकीएक्सचेंज, चेंजसाइफ़रस्पेक थिएटर, अलग क्रम वाला वैकल्पिक क्लाइंट सर्ट नृत्य)। वायरशार्क अभी भी पुराने अप्लायंस पर १.२ दिखाता है। कॉन्फ़िग में १.३ पसंद करें; १.२ सिर्फ़ तब रखें जब असली डिपेंडेंसी माँगे, और १.०/१.१ बंद करें।

सर्वर को "साबित" क्या करता है

सर्ट पब्लिक की को नाम से बाँधता है। हैंडशेक में सर्वर मैचिंग प्राइवेट की इस्तेमाल करता है ताकि क्लाइंट जाने कि कोई रैंडम बॉक्स बिना की के कॉपी किया सर्ट नहीं दिखा रहा। सिर्फ़ पीईएम सर्टिफ़िकेट चुराना काफ़ी नहीं; प्राइवेट की चुराना रिवोक और रोटेट तक विनाशकारी है।

सिफ़र सूट (आपको क्या फिक्र)

आधुनिक स्टैक पर आप लगभग कभी हाथ से एईएस बनाम चाचा नहीं चुनते। ओपनएसएसएल, बोरिंगएसएसएल, गो और ब्राउज़र इंजन के डिफ़ॉल्ट एईएडी सूट (एईएस-जीसीएम, चाचा२०-पॉली१३०५) और आधुनिक कर्व (एक्स२५५१९, पी-२५६) पसंद करते हैं। आपका काम:

  • अगर स्कैनर पुराने या एक्सपोर्ट-ग्रेड सूट ढूँढे तो बंद करें।
  • ऐसे सर्वर कॉन्फ़िग चुनें जो मेंटेन प्रोफ़ाइल फॉलो करें (मोज़िला एसएसएल कॉन्फ़िगरेशन जेनरेटर, क्लाउड प्रोवाइडर की "मॉडर्न" टीएलएस पॉलिसी)।
  • २०१४ के ब्लॉग से कस्टम सिफ़र स्ट्रिंग न गढ़ें।

सेशन रिजंप्शन

पूरा हैंडशेक सीपीयू और लेटेंसी खाता है। रिजंप्शन पुराने सीक्रेट दोबारा इस्तेमाल करता है (१.३ में टिकट)। मोबाइल ऐप और हाई-क्यूपीएस क्लाइंट के लिए अच्छा। मल्टी-नोड टर्मिनेटर पर टिकट की रोटेशन देखें: अगर हर पॉड की रैंडम टिकट की हो और शेयर न हो, रिजंप्शन गिर जाता है और आप लगातार पूरा हैंडशेक चुकाते हैं।

एसएनआई: एक आईपी, कई सर्टिफ़िकेट

सर्वर नेम इंडिकेशन (एसएनआई) क्लाइंटहेलो एक्सटेंशन है जो बताता है क्लाइंट कौन सा होस्टनेम चाहता है। बिना एसएनआई, एक आईपी पर कई सर्ट वाले सर्वर को नहीं पता कौन सा लीफ़ दिखाना है।

आपको क्यों फिक्र:

१. साझा लोड बैलेंसर / इंग्रेस: एसएनआई नाम से रूट और सर्ट चुनते हैं। २. सीडीएन और मल्टी-टेनेंट प्लेटफ़ॉर्म: वही एनीकास्ट आईपी, अलग कस्टमर सर्ट। ३. डिबग: curl https://ip/ या बिना एसएनआई आईपी से कनेक्ट अक्सर डिफ़ॉल्ट सर्ट देता है, जो आपके मतलब वाले नाम की होस्टनेम जाँच फेल करता है।

व्यावहारिक एसएनआई फेल

लक्षण संभावित कारण
ब्राउज़र ठीक, कोई जावा/पुराना क्लाइंट फेल क्लाइंट एसएनआई नहीं भेजता
ग़लत सर्ट (दूसरे टेनेंट का नाम) डिफ़ॉल्ट सर्वर ब्लॉक / ग़लत इंग्रेस टीएलएस सीक्रेट
curl --resolve से चलता है, डीएनएस से नहीं डीएनएस अलग वीआईपी पर
एमटीएलएस या एपीआई गेटवे "कोई सर्टिफ़िकेट मेल नहीं खाता" एसएनआई नाम ≠ सर्ट एसएएन ≠ रूट होस्ट

स्पष्ट सर्वर नाम से टेस्ट करें:

# Force connect to an IP but send SNI + Host for api.example.com
openssl s_client -connect 203.0.113.10:443 -servername api.example.com </dev/null

curl -v --resolve api.example.com:443:203.0.113.10 https://api.example.com/health

-servername छोड़ें तो आप यूज़र वाला रास्ता नहीं टेस्ट कर रहे।

एसएनआई और प्राइवेसी

क्लासिक एसएनआई टीसीपी पर टीएलएस १.२/१.३ में साफ़ टेक्स्ट है। नेटवर्क ऑब्ज़र्वर होस्टनेम सीख लेता है भले एचटीटीपी पथ एन्क्रिप्टेड हो। ईसीएच उसे एन्क्रिप्ट करना चाहता है; अपनाना बढ़ रहा है पर सार्वभौमिक नहीं। अगर थ्रेट मॉडल में होस्टनेम प्राइवेसी है, जानें एज और क्लाइंट असल में क्या डिप्लॉय करते हैं।

एचटीटीपी/२, एचटीटीपी/३ और एएलपीएन

एप्लिकेशन-लेयर प्रोटोकॉल नेगोशिएशन (एएलपीएन) हैंडशेक में चलता है ताकि क्लाइंट और सर्वर h2, http/1.1, या h3 (क्विक के लिए) तय करें। अगर मिडलबॉक्स एएलपीएन काटे या प्रॉक्सी ग़लत हो, तो एचटीटीपी/१.१ पर गिर सकते हैं या क्लाइंट पॉलिसी के हिसाब से हैंडशेक फेल हो सकता है।

  • एचटीटीपी/२ पब्लिक वेब (ब्राउज़र) पर लगभग हमेशा टीएलएस चाहता है।
  • एचटीटीपी/३ क्विक (यूडीपी) इस्तेमाल करता है। टीएलएस १.३ क्विक में बना है; सर्ट की कहानी वही आइडिया, अलग वायर पैकेजिंग।

जब "एचटीटीपीएस चलता है पर एचटीटीपी/२ कभी नेगोशिएट नहीं होता", टर्मिनेटर पर एएलपीएन देखें और बीच का एल७ प्रॉक्सी क्लाइंट से सिर्फ़ एचटीटीपी/१.१ तो नहीं बोल रहा।

म्यूचुअल टीएलएस (एमटीएलएस) एक पेज में

सामान्य एचटीटीपीएस में सिर्फ़ सर्वर सर्ट दिखाता है। एमटीएलएस में क्लाइंट भी दिखाता है। सर्वर क्लाइंट सर्ट चेन + (अक्सर) स्पिफ़े आईडी, सीएन/एसएएन अलाउलिस्ट, या मेश आइडेंटिटी जाँचता है।

उपयोग: ज़ीरो-ट्रस्ट नेटवर्क में सर्विस-टू-सर्विस, पार्टनर एपीआई, डिवाइस आइडेंटिटी।

कठिन हिस्सा ऑपरेशनल है, क्रिप्टोग्राफ़िक नहीं:

  • क्लाइंट सर्ट जारी करना और रोटेट करना
  • ट्रस्ट बंडल बाँटना
  • कुल आउटेज के बिना एक्सपायरी संभालना
  • क्लाइंट सर्ट गायब / ग़लत / एक्सपायर्ड पर साफ़ एरर

पब्लिक ब्राउज़र ऐप पर सिर्फ़ यूज़र लॉगिन के लिए एमटीएलएस न ठोकें। ब्राउज़र और यूएक्स लड़ते हैं; इसे सर्विस और नियंत्रित क्लाइंट के लिए रखें।

आम ग़लत कॉन्फ़िग (जो शिप हो जाते हैं)

१. एक्सपायर्ड सर्टिफ़िकेट

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

२. अधूरी चेन (इंटरमीडिएट गायब)

लक्षण: क्रोम में चलता है, जावा, पाइथन, मोबाइल, या साफ़ ट्रस्ट स्टोर वाले curl में नहीं। ठीक: लीफ़ + इंटरमीडिएट सर्व करें; openssl s_client और बाहरी एसएसएल चेकर से जाँचें। हर जगह एआईए फ़ेच पर भरोसा न करें।

३. होस्टनेम / एसएएन मिसमैच

लक्षण: सर्ट www.example.com के लिए वैध है पर यूज़र example.com या api.example.com खोलते हैं। ठीक: सभी पब्लिक नाम एसएएन में डालें, या ग़लत नाम पर टीएलएस टर्मिनेट होने से पहले एपेक्स/www रीडायरेक्ट करें (रीडायरेक्ट के लिए पहले छूए गए नाम से मैच करता सर्ट चाहिए)।

४. ग़ड़ी घड़ी

लक्षण: रुक-रुक कर वेरिफ़ाई फेल, "सर्ट अभी वैध नहीं", या आसपास जेडब्ल्यूटी जैसा अराजकता। टीएलएस और सर्ट वैधता समय पर टिके हैं। सर्वर पर एनटीपी ठीक करें; समझें कि कंटेनर होस्ट खराब क्लॉक से बूट हो सकते हैं।

५. बैकएंड क्लाइंट में वेरिफ़िकेशन बंद

# Looks like a temporary local fix. Becomes production.
requests.get(url, verify=False)

// Node: same footgun
process.env.NODE_TLS_REJECT_UNAUTHORIZED = '0';

लक्षण: कोई एरर नहीं, किसी भी अधूरे नियंत्रण वाले नेटवर्क पथ पर चुपचाप एमआईटीएम जोखिम। ठीक: सही सीए बंडल, सही होस्टनेम, या जानबूझकर लाइब्रेरी से पिन। साझा कोड में कभी verify=False न छोड़ें।

६. मिक्स्ड कंटेंट

एचटीटीपीएस पेज स्क्रिप्ट या एक्सएचआर http:// से लाता है। ब्राउज़र सक्रिय मिक्स्ड कंटेंट रोकते हैं। ठीक: सभी एसेट और एपीआई एचटीटीपीएस पर; प्रोटोकॉल-रिलेटिव यूआरएल सिर्फ़ अगर ज़रूरी हो (बेहतर: पूर्ण https:// या उसी होस्ट पर रूट-रिलेटिव पथ)।

७. सिर्फ़ एज पर टीएलएस, अंदर क्लियरटेक्स्ट और होस्टाइल नेटवर्क मान्यता

लक्षण: कम्प्लायंस रिव्यू या लेटरल मूवमेंट पॉड ट्रैफ़िक पढ़े। ठीक: ओरिजिन तक फिर एन्क्रिप्ट, मेश एमटीएलएस, या प्राइवेट नेटवर्क को होस्टाइल मानकर डिज़ाइन। कम से कम जानें कौन से सेगमेंट क्लियरटेक्स्ट हैं।

८. पुराने प्रोटोकॉल और सिफ़र

लक्षण: स्कैनर ग्रेड एफ; या पुराने क्लाइंट कमज़ोर सूट से जुड़ें। ठीक: न्यूनतम टीएलएस १.२+ (१.३ पसंद), आधुनिक सिफ़र पॉलिसी, आरसी४/३डीईएस/एक्सपोर्ट बंद। हार्ड कटओवर से पहले लेगेसी पीओएस/हार्डवेयर टेस्ट करें।

९. प्रॉक्सी चेन में ग़लत डिवाइस पर सर्ट

क्लाइंट → सीडीएन → एपीआई गेटवे → इंग्रेस → पॉड। हर हॉप टीएलएस खत्म कर सकता है। लक्षण: इंग्रेस सीक्रेट रिन्यू किया पर सीडीएन पर पुराना सर्ट (या उलटा)। ठीक: हर टर्मिनेटर की सूची; हर पब्लिक एंडपॉइंट के पेश किए सर्ट पर अलर्ट।

१०. एचएसटीएस ग़लतियाँ

एचएसटीएस ब्राउज़र को बताता है डोमेन के लिए सिर्फ़ एचटीटीपीएस (अक्सर सबडोमेन सहित)। एचटीटीपीएस ठोस हो तो अच्छा। दर्द तब जब प्रीलोड या includeSubDomains लगाएँ और कोई भुला एचटीटीपी-ओनली सबडोमेन टूटे। ठीक: नाम स्थान भर एचटीटीपीएस काम करे तब एचएसटीएस; प्रीलोड को व्यावहारिक रूप से स्थायी मानें।

११. यूआरएल में आईपी, सर्ट में सिर्फ़ डीएनएस एसएएन

https://203.0.113.10/ फेल होगा जब तक सर्ट में वह आईपी एसएएन न हो (पब्लिक साइटों पर दुर्लभ)। डीएनएस नाम इस्तेमाल करें।

१२. जीआरपीसी / एचटीटीपी/२ बैकएंड और अधूरी टीएलएस कॉन्फ़िग

जीआरपीसी एचटीटीपी/२ चाहता है। ग़लत एएलपीएन या एचटीटीपी/१.१ पर गिराने वाला प्रॉक्सी अस्पष्ट एरर देता है। ठीक: एंड-टू-एंड एच२, या सिर्फ़ समझे हुए विश्वसनीय लिंक पर स्पष्ट एच२सी।

१३. प्राइवेट की गिट में या डिस्क पर सबके पढ़ने लायक

लक्षण: की पब्लिक; समझौता मानें। ठीक: सर्ट + की रोटेट, ज़रूरत हो तो हिस्ट्री साफ़, सीक्रेट मैनेजर और संभव हो तो छोटे जीवन वाले सर्ट। की मटीरियल पर फ़ाइल सिस्टम अनुमति सख्त रखें।

१४. ओसीएसपी स्टेपलिंग / रिवोकेशन अंधे धब्बे

कुछ क्लाइंट रिवोकेशन चेक सॉफ्ट-फेल करते हैं। चुराई की से हमलावर एक्सपायरी तक इंपर्सनेट कर सकता है अगर आप रिवोकेशन ऑपरेट न करें। छोटे जीवन वाले सर्ट (एसीएमई हर ६० दिन या कम) + ऑटोमेशन बेहतर ताकि रिवोकेशन अकेला नियंत्रण न रहे।

१५. "कर्ल -k से चलता है"

-k / --insecure वेरिफ़ाई छोड़ता है। "टीसीपी और टीएलएस बोलते हैं" को "ट्रस्ट और नाम सही हैं" से अलग करने के लिए उपयोगी। हरे -k रिस्पॉन्स को प्रोडक्शन रेडी न मानें।

डिबग टूलकिट

# What cert is presented? What protocol and cipher?
openssl s_client -connect api.example.com:443 -servername api.example.com </dev/null 2>/dev/null | openssl x509 -noout -dates -subject -ext subjectAltName

# Full handshake chatter (TLS 1.3)
openssl s_client -connect api.example.com:443 -servername api.example.com -tls1_3

# curl details: verify result, HTTP version
curl -vI https://api.example.com/

# From another network path (user-like)
# Use an external checker or a probe in a different cloud region

ऐप लॉग में एरर क्लास लिखें (हैंडशेक फेल, सर्ट वेरिफ़ाई फेल, होस्टनेम मिसमैच) बिना सीक्रेट लॉग किए। सर्वर एक्सेस लॉग शायद ही क्लाइंट-साइड टीएलएस वेरिफ़ाई फेल दिखाएँ; क्लाइंट मीट्रिक और सिंथेटिक प्रोब चाहिए।

ब्राउज़र डेवटूल्स → सिक्योरिटी पैनल वह सर्ट चेन दिखाता है जो ब्राउज़र ने स्वीकार की। अलग पीओपी या मिडलबॉक्स पर openssl से अलग दिख सकता है।

शिप करने वालों की कॉन्फ़िग चेकलिस्ट

पब्लिक एज

  • टीएलएस १.२+ (१.३ पसंद), आधुनिक सिफ़र
  • पूरी चेन सर्व (लीफ़ + इंटरमीडिएट)
  • एसएएन हर उस होस्टनेम को ढकें जो यूज़र टाइप करे
  • ऑटो रिन्यूअल + एक्सपायरी अलर्ट (बाहरी प्रोब)
  • होस्टनेम के हिसाब से एसएनआई और रूटिंग संरेखित
  • उस नाम स्थान पर एचटीटीपीएस पूरा हो तब ही एचएसटीएस
  • उन्हीं नामों पर एचटीटीपी→एचटीटीपीएस रीडायरेक्ट, लूप बिना

सर्विस क्लाइंट (बैकएंड, मोबाइल, बैच)

  • वेरिफ़िकेशन चालू; पब्लिक या प्राइवेट पीकेआई के लिए सही सीए बंडल
  • होस्टनेम वेरिफ़िकेशन चालू; यूआरएल होस्ट सर्ट से मैच
  • होस्ट पर समय सिंक
  • डिप्लॉय कॉन्फ़िग में verify=False / NODE_TLS_REJECT_UNAUTHORIZED=0 नहीं
  • टाइमआउट और रीट्राई जो हैंडशेक फेल पर आउटेज न बढ़ाएँ

एमटीएलएस / इंटरनल

  • रोटेशन रनबुक टेस्टेड
  • ट्रस्ट बंडल वितरण परिभाषित
  • आइडेंटिटी मॉडल दस्तावेज़ (स्पिफ़े यूआरआई, एसएएन, आदि)
  • फेल मोड: सर्ट गायब हो तो डिफ़ॉल्ट में अस्वीकार

समापन

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

जब कुछ लाल हो, क्रम से पूछें: टीसीपी कनेक्ट होता है? हैंडशेक पूरा होता है? इस एसएनआई नाम के लिए कौन सा सर्ट दिखता है? साफ़ क्लाइंट पर चेन और होस्टनेम वेरिफ़ाई होते हैं? रास्ते में किस डिवाइस ने टीएलएस खत्म किया? यह क्रम रैंडम कॉन्फ़िग छेड़छाड़ से बेहतर है और उबाऊ हरे ताले तक जल्दी पहुँचाता है।