प्रश्न और कार्यक्षेत्र
एक ग्लोबल API TLS 1.3 का उपयोग करती है। एक पूर्ण हैंडशेक और एक फिर से शुरू किए गए (resumed) हैंडशेक की प्रक्रिया समझाएं। स्पष्ट करें कि प्रत्येक चरण में क्या एन्क्रिप्ट किया जाता है, प्रमाणपत्र सर्वर को कैसे प्रमाणित करता है, कुंजियाँ (keys) कैसे बनाई जाती हैं, और क्या GET /rates तथा POST /transfers को 0-RTT का उपयोग करना चाहिए।
एक स्पष्ट आधार रेखा (baseline) का उपयोग करें: क्लाइंट TCP पर HTTPS सेवा से कनेक्ट होता है; सर्वर एक X.509 प्रमाणपत्र के साथ प्रमाणित करता है; एक पूर्ण हैंडशेक अल्पकालिक (ephemeral) ECDHE का उपयोग करता है; एक फिर से शुरू किया गया कनेक्शन पहले के कनेक्शन पर जारी किए गए सत्र टिकट (session ticket) का उपयोग करता है; और API प्रवेश बिंदु एक लोड बैलेंसर या CDN हो सकता है। HTTP/3 TLS 1.3 को QUIC कनेक्शन स्थापना में एकीकृत करता है, लेकिन यह आधार रेखा संदेश क्रम और सुरक्षा गुणों को ठोस बनाने के लिए TCP पर TLS रिकॉर्ड का उपयोग करती है।
यह प्रश्न बैकएंड, क्लाइंट, इन्फ्रास्ट्रक्चर, SRE, सुरक्षा और सामान्य सॉफ्टवेयर इंजीनियरिंग साक्षात्कारों के लिए उपयुक्त है। साक्षात्कारकर्ता केवल ClientHello से Finished तक का पाठ मात्र नहीं सुनना चाहता। उम्मीदवार को यह बताना होगा कि पहचान इस हैंडशेक से कैसे जुड़ती है, कौन सी कुंजियाँ किन चरणों की रक्षा करती हैं, और नेटवर्क राउंड ट्रिप को हटाने से रीप्ले की समस्या क्यों पैदा होती है जिसे एप्लिकेशन को संभालना चाहिए।
साक्षात्कारकर्ता क्या जांच रहा है
पहला, क्या उम्मीदवार की-एक्सचेंज, प्रमाणीकरण और बल्क एन्क्रिप्शन को अलग कर सकता है? प्रमाणपत्र में सार्वजनिक कुंजी (public key) आमतौर पर हैंडशेक ट्रांसक्रिप्ट पर CertificateVerify हस्ताक्षर को सत्यापित करती है। यह बाद के सभी व्यावसायिक ट्रैफ़िक को एन्क्रिप्ट नहीं करती है। सिमेट्रिक ट्रैफ़िक कुंजियाँ ECDHE, एक PSK, और HKDF-आधारित की-शेड्यूल से आती हैं।
दूसरा, क्या उम्मीदवार एन्क्रिप्शन सीमा को सटीक रूप से रख सकता है? प्रारंभिक ClientHello और ServerHello बातचीत (negotiation) के लिए आवश्यक जानकारी को उजागर करते हैं। ServerHello को संसाधित करने के बाद, दोनों सहकर्मी (peers) हैंडशेक ट्रैफ़िक कुंजियाँ प्राप्त कर सकते हैं। वे कुंजियाँ EncryptedExtensions, Certificate, CertificateVerify, और Finished की सुरक्षा करती हैं। फिर अलग एप्लिकेशन ट्रैफ़िक कुंजियाँ एप्लिकेशन डेटा की सुरक्षा करती हैं।
तीसरा, क्या उम्मीदवार रेज़्यूम्प्शन (resumption) और 0-RTT के बीच अंतर कर सकता है? सत्र पुनः आरंभीकरण 1-RTT हैंडशेक को पूरा करते हुए प्रमाणीकरण को छोटा कर सकता है। 0-RTT के साथ, क्लाइंट अपनी पहली उड़ान (first flight) में अर्ली डेटा (early data) भेजता है। दोनों में PSK शामिल हो सकता है, लेकिन केवल अर्ली डेटा में वर्तमान ServerHello से प्राप्त ताजगी (freshness) की कमी होती है।
चौथा, क्या उम्मीदवार प्रोटोकॉल जोखिम को व्यावसायिक अर्थ विज्ञान (business semantics) में बदल सकता है? TLS 1.3 अर्ली डेटा को कमजोर गुण देता है: यह फ़ॉरवर्ड सीक्रेट नहीं है और कनेक्शनों के बीच गैर-रीप्ले की कोई गारंटी नहीं है। इसे सक्षम करने का निर्णय केवल HTTP विधि से नहीं लिया जा सकता। पैसे काटना, सत्र बनाना, काउंटर बढ़ाना, इनाम जारी करना, या वन-टाइम टोकन का उपयोग करना उत्तर को बदल देता है।
पांचवां, क्या उम्मीदवार एक अवलोकन योग्य रोलआउट और डिबगिंग योजना का प्रस्ताव कर सकता है? एक मजबूत उत्तर एक पूर्ण हैंडशेक, 1-RTT रेज़्यूम्प्शन और 0-RTT में अंतर करता है; टिकट, ALPN, HelloRetryRequest, अर्ली-डेटा स्वीकृति या अस्वीकृति, और HTTP 425 Too Early की जांच करता है; और एज TLS टर्मिनेटर से मूल (origin) तक अलग सुरक्षा चैनल को सत्यापित करता है।
पहले स्पष्ट करने योग्य प्रश्न
- कौन सा ट्रांसपोर्ट उपयोग में है? TCP पर HTTPS और QUIC/HTTP/3 दोनों TLS 1.3 क्रिप्टोग्राफी का उपयोग करते हैं, लेकिन संदेशों को अलग तरह से ले जाते हैं और कनेक्शन स्थापित करते हैं। आधार रेखा TCP का उपयोग करती है।
- क्या यह पहला या फिर से शुरू किया गया कनेक्शन है? पहले कनेक्शन में कोई प्रयोग करने योग्य PSK नहीं होता है और इसे प्रमाणपत्र प्रमाणीकरण की आवश्यकता होती है। फिर से शुरू किया गया कनेक्शन पिछले टिकट की पेशकश कर सकता है, लेकिन आवश्यक रूप से 0-RTT नहीं भेजता है।
- क्या सर्वर क्लाइंट प्रमाणपत्र का अनुरोध करता है? अधिकांश वेब API केवल सर्वर को प्रमाणित करती हैं। mTLS क्लाइंट के
CertificateऔरCertificateVerifyको जोड़ता है। - TLS कहाँ समाप्त (terminate) होता है? यदि यह CDN या लोड बैलेंसर पर समाप्त होता है, तो क्लाइंट उस एज एंडपॉइंट को प्रमाणित करता है। एज-टू-ओरिजिन ट्रैफ़िक अपने स्वयं के एन्क्रिप्शन और पहचान निर्णयों के साथ एक अलग कनेक्शन है।
- ऑपरेशन के रीप्ले सेमेंटिक्स क्या हैं? क्या
GET /ratesवास्तव में केवल-पढ़ने योग्य (read-only) है? क्या यह वन-टाइम टोकन का उपभोग करता है, बिल योग्य काउंटर बढ़ाता है, या महंगा कार्य ट्रिगर करता है?POST /transfersपर एक इडेम्पोटेंसी कुंजी (idempotency key) स्वचालित रूप से हर अर्ली-डेटा जोखिम को समाप्त नहीं करती है। - क्या दोनों पक्ष HTTP अर्ली डेटा को सही ढंग से लागू करते हैं? यदि TLS लेयर अर्ली डेटा को अस्वीकार करती है या सर्वर
425लौटाता है, तो क्लाइंट को स्थापित कनेक्शन पर सुरक्षित रूप से पुनः प्रयास (retry) करना चाहिए।
30-सेकंड उत्तर रूपरेखा
"एक पूर्ण TLS 1.3 हैंडशेक में, क्लाइंट संस्करणों, सिफर सुइट्स और एक ECDHE की-शेयर के साथ एक ClientHello भेजता है। सर्वर ServerHello में पैरामीटर चुनता है और अपना शेयर लौटाता है। दोनों सहकर्मी हैंडशेक कुंजियाँ प्राप्त करने के लिए ECDHE परिणाम और ट्रांसक्रिप्ट को HKDF में डालते हैं, इसलिए ServerHello के बाद एक्सटेंशन, प्रमाणपत्र, हस्ताक्षर और Finished एन्क्रिप्ट किए जाते हैं। क्लाइंट चेन, होस्टनाम, CertificateVerify और Finished को मान्य करता है, फिर अपना स्वयं का Finished भेजता है। अलग एप्लिकेशन ट्रैफ़िक कुंजियाँ बाद के डेटा की सुरक्षा करती हैं।
रेज़्यूम्प्शन पिछले टिकट से जुड़े एक PSK का उपयोग करता है और पूर्ण प्रमाणपत्र प्रमाणीकरण से बच सकता है। यदि 0-RTT भी सक्षम है, तो क्लाइंट ClientHello के साथ अर्ली डेटा भेजता है। वह डेटा केवल PSK पर निर्भर करता है, फ़ॉरवर्ड सीक्रेट नहीं है, और कनेक्शनों में रीप्ले किया जा सकता है। मैं केवल स्पष्ट रूप से पुनः प्रयास-सुरक्षित (retry-safe), दुष्प्रभाव-मुक्त (side-effect-free) रीड्स की अनुमति दूंगा। एक ट्रांसफ़र को लगातार गेटवे नीति, 425 Too Early और सामान्य पुनः प्रयास समर्थन के साथ हैंडशेक पूरा होने तक प्रतीक्षा करनी चाहिए।"
चरण-दर-चरण गहन विश्लेषण
चरण 1: ClientHello बातचीत सामग्री की आपूर्ति करता है
क्लाइंट ClientHello से शुरुआत करता है। इसमें आमतौर पर एक नॉन्स (nonce), समर्थित TLS संस्करण, TLS 1.3 सिफर सुइट्स, हस्ताक्षर एल्गोरिदम, समर्थित की-एक्सचेंज समूह, एक या अधिक key_share मान, और SNI तथा ALPN जैसे एक्सटेंशन शामिल होते हैं। एक TLS 1.3 सिफर सुइट मुख्य रूप से एक AEAD एल्गोरिदम और HKDF द्वारा उपयोग किए जाने वाले हैश का चयन करता है। अन्य एक्सटेंशन प्रमाणपत्र हस्ताक्षर एल्गोरिदम और की-एक्सचेंज समूहों पर बातचीत करते हैं।
यह संदेश सामान्य TLS 1.3 में हैंडशेक ट्रैफ़िक कुंजियों द्वारा अभी तक सुरक्षित नहीं है। SNI भी आमतौर पर तब तक दिखाई देता है जब तक कि सहकर्मी सफलतापूर्वक ECH का उपयोग नहीं करते हैं। यह कहना कि TLS पहले बाइट से हर फ़ील्ड को एन्क्रिप्ट करता है, इस तथ्य की उपेक्षा करता है कि साथियों ने अभी तक इस कनेक्शन के लिए साझा ट्रैफ़िक कुंजियाँ प्राप्त नहीं की हैं।
क्लाइंट का की-शेयर एक अल्पकालिक ECDHE सार्वजनिक मान (public value) है। इसका संबंधित निजी मान (private value) स्थानीय रहता है। सार्वजनिक मान स्वयं साझा रहस्य (shared secret) नहीं है। प्रत्येक सहकर्मी समान ECDHE रहस्य की गणना करने के लिए अपने निजी मान को दूसरे साथी के सार्वजनिक मान के साथ जोड़ता है।
चरण 2: ServerHello पैरामीटर चुनता है और नए की-एक्सचेंज को पूरा करता है
सर्वर TLS संस्करण, सिफर सुइट और स्वीकार्य की-शेयर का चयन करता है, फिर ServerHello भेजता है। ECDHE के साथ, यह अपना अल्पकालिक सार्वजनिक मान भी प्रदान करता है। ClientHello और ServerHello मिलकर क्रिप्टोग्राफ़िक पैरामीटर निर्धारित करते हैं, और दोनों सहकर्मी अब ECDHE रहस्य को TLS 1.3 HKDF की-शेड्यूल में फीड कर सकते हैं।
यदि क्लाइंट ने ऐसे समूह में शेयर की पेशकश नहीं की जिसे सर्वर स्वीकार करता है, तो सर्वर HelloRetryRequest भेज सकता है और चयनित समूह के साथ एक और ClientHello की मांग कर सकता है। इसमें एक और राउंड ट्रिप की लागत आती है, और एक मूल अर्ली-डेटा प्रयास केवल सामान्य सफल पथ के रूप में जारी नहीं रह सकता है। उत्पादन में एक आंतरायिक (intermittent) अतिरिक्त RTT को नेटवर्क जिटर की स्वचालित धारणा के बजाय HRR जांच को प्रेरित करना चाहिए।
ServerHello के बाद, दोनों सहकर्मी क्लाइंट और सर्वर हैंडशेक ट्रैफ़िक रहस्य प्राप्त कर सकते हैं। प्रोटोकॉल बाद के हैंडशेक संदेशों को उन कुंजियों से सुरक्षित करता है। एक निष्क्रिय पर्यवेक्षक प्रमाणपत्र या अधिकांश बाद के एक्सटेंशन को नहीं पढ़ सकता है, हालांकि रिकॉर्ड आकार, समय और प्रारंभिक जानकारी जो ECH द्वारा छिपाई नहीं गई है, वे अवलोकन योग्य रहती हैं।
चरण 3: सर्वर पैरामीटर, प्रमाणपत्र और ट्रांसक्रिप्ट हस्ताक्षर पहचान स्थापित करते हैं
सर्वर अगला एन्क्रिप्टेड EncryptedExtensions भेजता है, जिसमें ALPN जैसे एक्सटेंशन के चयन होते हैं। यदि वह क्लाइंट प्रमाणीकरण चाहता है तो वह CertificateRequest भेजता है। एक विशिष्ट एकतरफा HTTPS हैंडशेक फिर सर्वर के Certificate, CertificateVerify, और Finished को भेजता है।
उन संदेशों के अलग-अलग कार्य हैं:
| संदेश | प्राथमिक उद्देश्य | सामान्य गलत धारणा |
|---|---|---|
Certificate | सर्वर प्रमाणपत्र श्रृंखला और संबंधित एक्सटेंशन की आपूर्ति करता है | केवल प्रमाणपत्र ही हैंडशेक को विश्वसनीय बनाता है |
CertificateVerify | प्रमाणपत्र की निजी कुंजी के साथ वर्तमान हैंडशेक ट्रांसक्रिप्ट पर हस्ताक्षर करता है | प्रमाणपत्र की सार्वजनिक कुंजी सभी व्यावसायिक डेटा को एन्क्रिप्ट करती है |
Finished | हैंडशेक-प्राप्त कुंजी के साथ ट्रांसक्रिप्ट अखंडता को प्रमाणित करता है और कुंजी पुष्टि प्रदान करता है | यह केवल प्रमाणपत्र को मान्य करता है |
क्लाइंट अपनी PKI नीति के अनुसार चेन, वैधता अंतराल, होस्टनाम और अनुमत हस्ताक्षर एल्गोरिदम को मान्य करता है, फिर ट्रांसक्रिप्ट पर CertificateVerify हस्ताक्षर को सत्यापित करता है। यह प्रमाणपत्र की निजी कुंजी के नियंत्रण को इस ClientHello, ServerHello, और बातचीत किए गए पैरामीटर सेट से बांधता है। कोई हमलावर किसी असंबंधित हैंडशेक से हस्ताक्षर को ट्रांसप्लांट नहीं कर सकता है।
चरण 4: Finished हैंडशेक पूरा करता है और एप्लिकेशन कुंजियों को अलग करता है
सर्वर का Finished ट्रांसक्रिप्ट और एक हैंडशेक रहस्य से प्राप्त एक सत्यापन मान है। एक सफल जांच क्लाइंट को बताती है कि देखे गए नेगोशिएशन को संशोधित नहीं किया गया था और सहकर्मी के पास संबंधित हैंडशेक की-मटीरियल मौजूद है। प्रमाणपत्र प्रमाणीकरण या Finished सत्यापन के बिना डेटा स्वीकार करना TLS पहचान और अखंडता की गारंटी को त्याग देगा।
क्लाइंट तब अपना स्वयं का Finished भेजता है। यदि सर्वर ने mTLS का अनुरोध किया है, तो क्लाइंट पहले अपना प्रमाणपत्र और CertificateVerify भेजता है। सहकर्मी हैंडशेक कुंजियों का पुन: उपयोग जारी रखने के बजाय एप्लिकेशन ट्रैफ़िक रहस्यों के साथ एप्लिकेशन डेटा की रक्षा करते हैं। TLS 1.3 बाद में नई एप्लिकेशन ट्रैफ़िक कुंजियों पर जाने के लिए KeyUpdate का उपयोग कर सकता है।
फ़ॉरवर्ड सीक्रेसी अल्पकालिक (EC)DHE से आती है। यदि सहकर्मी अल्पकालिक निजी मूल्यों और अप्रचलित ट्रैफ़िक रहस्यों को मिटा देते हैं, तो सर्वर की दीर्घकालिक प्रमाणपत्र निजी कुंजी का भविष्य में लीक होना उन पूर्ण हैंडशेक से कैप्चर किए गए एप्लिकेशन ट्रैफ़िक को डिक्रिप्ट नहीं कर सकता। प्रमाणपत्र कुंजी प्रमाणित करती है; यह फ़ॉरवर्ड सीक्रेसी का एकमात्र स्रोत नहीं है।
चरण 5: सत्र टिकट बाद के कनेक्शनों को PSK रेज़्यूम्प्शन में बदलते हैं
एक पूर्ण हैंडशेक के बाद, सर्वर NewSessionTicket भेज सकता है। क्लाइंट टिकट और संबद्ध रेज़्यूम्प्शन रहस्य को संग्रहीत करता है। बाद के कनेक्शन पर, यह pre_shared_key में टिकट पहचान प्रदान करता है और संबंधित PSK के कब्जे को साबित करने के लिए एक बाइंडर का उपयोग करता है। यदि सर्वर इसे स्वीकार करता है, तो PSK फिर से शुरू किए गए कनेक्शन को प्रमाणित करता है, आमतौर पर प्रमाणपत्र श्रृंखला और CertificateVerify को फिर से भेजने की आवश्यकता को समाप्त कर देता है।
रेज़्यूम्प्शन के लिए नए ECDHE को छोड़ने की आवश्यकता नहीं है। TLS 1.3 PSK-ओनली और ECDHE के साथ संयुक्त PSK का समर्थन करता है। प्रोडक्शन डिज़ाइनों में आमतौर पर PSK+DHE की परवाह की जाती है क्योंकि यह सामान्य 1-RTT एप्लिकेशन ट्रैफ़िक में नए डिफी-हेलमैन मटीरियल को शामिल करते हुए रेज़्यूम्प्शन के प्रमाणीकरण और गणना लाभों को सुरक्षित रखता है। PSK-ओनली के गुण भिन्न होते हैं, इसलिए उत्तर में चयनित मोड का नाम होना चाहिए।
टिकट कोई स्थायी लॉगिन क्रेडेंशियल नहीं है। इसका एक जीवनकाल, बाध्य क्रिप्टोग्राफ़िक पैरामीटर, सर्वर कुंजी रोटेशन और क्लस्टर-साझाकरण नीति होती है। यदि कोई बहु-क्षेत्रीय (multi-region) सेवा लगातार किसी टिकट को डिक्रिप्ट या मान्य नहीं कर सकती है, तो पूर्ण हैंडशेक पर वापस जाना या रेज़्यूम्प्शन को अस्वीकार करना एक वैध अनुकूलता शाखा है। उच्च रेज़्यूम्प्शन दर का पीछा करना असीमित टिकट-कुंजी जीवनकाल को सही नहीं ठहराता है।
चरण 6: 0-RTT अर्ली डेटा को पहली उड़ान में रखता है
यदि कोई टिकट अर्ली डेटा की अनुमति देता है, तो क्लाइंट फिर से शुरू किए गए कनेक्शन की पहली उड़ान में ClientHello और एप्लिकेशन डेटा भेज सकता है। अर्ली डेटा PSK से प्राप्त क्लाइंट अर्ली ट्रैफ़िक रहस्य के साथ एन्क्रिप्ट किया गया है। भेजने के समय, क्लाइंट को इस कनेक्शन का ServerHello प्राप्त नहीं हुआ होता है।
यह विलंबता (latency) को कम करता है लेकिन दो महत्वपूर्ण कमजोरियाँ पैदा करता है:
- अर्ली डेटा इस कनेक्शन के ECDHE एक्सचेंज के बिना PSK से प्राप्त होता है, इसलिए यह फ़ॉरवर्ड सीक्रेट नहीं है।
- यह इस सर्वर नॉन्स और
ServerHelloपर निर्भर नहीं करता है, इसलिए प्रोटोकॉल यह गारंटी नहीं दे सकता कि वही सिफरटेक्स्ट किसी अन्य कनेक्शन पर रीप्ले नहीं किया जाएगा।
सर्वर TLS अर्ली-डेटा बैच को स्वीकार या अस्वीकार कर सकता है। यदि यह इसे अस्वीकार करता है, तो क्लाइंट को उन अनुरोधों को फिर से प्रेषित करना चाहिए जिन्हें सामान्य हैंडशेक पूरा होने के बाद भी निष्पादन की आवश्यकता होती है। एप्लिकेशन पहले से ही अनिश्चितता का सामना करते हैं जब सर्वर ने अनुरोध संसाधित किया हो लेकिन क्लाइंट को परिणाम नहीं मिला हो। 0-RTT इसके अतिरिक्त एक हमलावर को जानबूझकर क्रॉस-कनेक्शन डुप्लिकेट बनाने की अनुमति देता है।
चरण 7: व्यावसायिक दुष्प्रभावों से पात्रता तय करें
अतिरिक्त जानकारी के बिना, RFC 8470 क्लाइंट्स को अर्ली डेटा में सुरक्षित HTTP विधियों का उपयोग करने की अनुमति देता है और असुरक्षित या अज्ञात विधियों को प्रतिबंधित करता है। विधि केवल एक पहला फ़िल्टर है। संसाधन का व्यवहार वास्तविक जोखिम निर्धारित करता है।
| अनुरोध | यहाँ निर्णय | कारण |
|---|---|---|
GET /rates | केवल स्पष्ट समीक्षा के बाद विचार करें | यह केवल-पढ़ने योग्य, दोहराने योग्य, और वन-टाइम टोकन, बिलिंग, या अस्वीकार्य कंप्यूट दुष्प्रभावों से मुक्त होना चाहिए |
POST /transfers | कभी भी 0-RTT का उपयोग न करें | रीप्ले के कारण डुप्लिकेट ट्रांसफ़र, डुप्लिकेट ऑडिट इवेंट, या किसी अलग समय पर प्राधिकरण हो सकता है |
POST /login | आम तौर पर अस्वीकार करें | यह एक सत्र बनाता है, एक चुनौती का उपभोग करता है, या जोखिम काउंटरों को बदलता है |
GET /download?token=once | केवल इसलिए अनुमति न दें क्योंकि यह GET है | वन-टाइम टोकन और एक्सेस अकाउंटिंग रीप्ले को परिणामी बनाते हैं |
एक इडेम्पोटेंसी कुंजी अपने आप में स्थानान्तरण के लिए 0-RTT को सक्षम करने का औचित्य सिद्ध नहीं करती है। इडेम्पोटेंसी रिकॉर्ड हर प्रोसेसिंग नोड पर सुसंगत होना चाहिए, सही लेनदेन सीमा पर परमाणु रूप से (atomically) प्रतिबद्ध होना चाहिए, और ऑडिट, अधिसूचना, सीमा और धोखाधड़ी के दुष्प्रभावों को कवर करना चाहिए। चोरी किए गए अनुरोध को दोबारा चलाने से कुंजी पिन या उपभोग भी हो सकती है। उच्च जोखिम वाले राइट्स (writes) के लिए सुरक्षित नीति अभी भी हैंडशेक पूरा होने की प्रतीक्षा करना है।
चरण 8: गेटवे, मूल (origin) और क्लाइंट नीति को सुसंगत बनाएं
HTTP Early-Data: 1 और 425 Too Early को परिभाषित करता है। जब कोई गेटवे ऐसे अनुरोध को अग्रेषित करता है जो पिछले हॉप पर अर्ली डेटा में आया हो सकता है, तो वह जोखिम संकेत को संरक्षित रखता है। एक मूल जो अनुरोध को सुरक्षित रूप से संसाधित नहीं कर सकता है वह 425 लौटाता है। क्लाइंट हैंडशेक पूरा होने के बाद कनेक्शन पर पुनः प्रयास करता है, और उस पुनः प्रयास को फिर से अर्ली डेटा का उपयोग नहीं करना चाहिए।
प्रत्येक एज इंस्टेंस को एक ही अनुरोध वर्ग को लगातार संभालना चाहिए। यदि एक इंस्टेंस तुरंत निष्पादित होता है जबकि दूसरा हैंडशेक पूरा होने की प्रतीक्षा करता है या अस्वीकार करता है, तो एक हमलावर प्रभावों को डुप्लिकेट करने के लिए बहु-इंस्टेंस अंतरों का फायदा उठा सकता है। नियंत्रणों में शामिल हैं:
- डिफ़ॉल्ट रूप से 0-RTT अक्षम करें और केवल स्पष्ट रूप से पंजीकृत केवल-पढ़ने योग्य संसाधनों की अनुमति दें।
- टिकट के जीवनकाल, अर्ली-डेटा आकार और स्वीकृति विंडो को सीमित करें।
- साझा या सुसंगत रूप से विभाजित एंटी-रीप्ले स्थिति का उपयोग करें, यह पहचानते हुए कि यह एप्लिकेशन सेमेंटिक्स को बदलने के बजाय जोखिम को कम करता है।
- लोड के तहत अर्ली डेटा को पूरी तरह से अस्वीकार करें ताकि रीप्ले महंगे काम को बढ़ा न सके।
- सुनिश्चित करें कि CDN, रिवर्स प्रॉक्सी और ओरिजिन सभी
Early-Dataऔर425को समझते हैं।
मजबूत नमूना उत्तर
"मैं बेसलाइन के रूप में सर्वर प्रमाणपत्र प्रमाणीकरण के साथ TCP पर एक पूर्ण ECDHE हैंडशेक का उपयोग करूंगा।
क्लाइंट समर्थित संस्करणों, TLS 1.3 सिफर सुइट्स, हस्ताक्षर एल्गोरिदम, की-एक्सचेंज समूहों और एक अल्पकालिक की-शेयर के साथ संभावित SNI और ALPN एक्सटेंशन के साथ ClientHello भेजता है। सर्वर ServerHello में पैरामीटर चुनता है और अपना की-शेयर लौटाता है। दोनों सहकर्मी हैंडशेक ट्रैफ़िक कुंजियाँ प्राप्त करने के लिए ECDHE परिणाम और ट्रांसक्रिप्ट को HKDF में डालते हैं। की-एक्सचेंज चरण के बाद, EncryptedExtensions, सर्वर प्रमाणपत्र, CertificateVerify, और Finished एन्क्रिप्ट किए जाते हैं।
प्रमाणपत्र सर्वर पहचान के लिए एक ट्रस्ट चेन की आपूर्ति करता है। CertificateVerify पहचान को इस बातचीत से बांधते हुए, प्रमाणपत्र की निजी कुंजी के साथ इस हैंडशेक ट्रांसक्रिप्ट पर हस्ताक्षर करता है। Finished ट्रांसक्रिप्ट अखंडता को प्रमाणित करता है और हैंडशेक कुंजियों के कब्जे की पुष्टि करता है। क्लाइंट द्वारा चेन, होस्टनाम, हस्ताक्षर और Finished को मान्य करने के बाद, यह अपना स्वयं का Finished भेजता है, और सहकर्मी अलग एप्लिकेशन ट्रैफ़िक कुंजियों पर स्विच करते हैं। प्रमाणपत्र सार्वजनिक कुंजी पहचान की पुष्टि करती है; यह सभी व्यावसायिक डेटा को एन्क्रिप्ट नहीं करती है। फ़ॉरवर्ड सीक्रेसी मुख्य रूप से अल्पकालिक ECDHE और गुप्त विलोपन (secret erasure) से आती है।
बाद का कनेक्शन NewSessionTicket से जुड़े PSK के साथ फिर से शुरू हो सकता है। यह एक सामान्य PSK+DHE 1-RTT हैंडशेक का उपयोग कर सकता है या वैकल्पिक रूप से 0-RTT का उपयोग कर सकता है। 0-RTT के साथ, क्लाइंट ClientHello के साथ अर्ली डेटा भेजता है, लेकिन वे बाइट केवल PSK-प्राप्त कुंजियों द्वारा संरक्षित होते हैं, फ़ॉरवर्ड सीक्रेट नहीं होते हैं, और कनेक्शनों में रीप्ले किए जा सकते हैं।
इसलिए मैं कभी भी POST /transfers को 0-RTT में नहीं भेजूंगा। इडेम्पोटेंसी कुंजी के साथ भी, ट्रांसफ़र, ऑडिट, सीमा और अधिसूचना प्रभाव सभी डुप्लिकेट-सुरक्षित साबित होने चाहिए। GET /rates केवल तभी अनुमति सूची में प्रवेश करता है जब यह विशुद्ध रूप से पढ़ने योग्य हो, सुरक्षित रूप से पुनः प्रयास करने योग्य हो, और इसमें कोई वन-टाइम टोकन या अस्वीकार्य दुष्प्रभाव न हो। गेटवे और मूल Early-Data: 1 का प्रचार करते हैं, असुरक्षित होने पर 425 Too Early लौटाते हैं, और क्लाइंट हैंडशेक पूरा होने के बाद पुनः प्रयास करता है। रोलआउट के दौरान, मैं अलग से पूर्ण हैंडशेक, 1-RTT रेज़्यूम्प्शन और 0-RTT को मापता हूं, फिर टिकट स्वीकृति, HRR, अस्वीकृति पथ और क्रॉस-नोड नीति को सत्यापित करता हूं।"
सामान्य गलतियाँ
- यह कहना कि प्रमाणपत्र सार्वजनिक कुंजी बाद के सभी ट्रैफ़िक को एन्क्रिप्ट करती है → TLS 1.3 व्यावसायिक ट्रैफ़िक सिमेट्रिक ट्रैफ़िक कुंजियों का उपयोग करता है → प्रमाणपत्र हस्ताक्षर सत्यापन को ECDHE/PSK और HKDF से अलग करें।
- यह कहना कि सब कुछ
ClientHelloसे आगे एन्क्रिप्टेड है → प्रारंभिक बातचीत हैंडशेक-की व्युत्पत्ति से पहले होती है → बाद के हैंडशेक संदेशों के लिएServerHelloके बाद सीमा रखें। - केवल श्रृंखला को मान्य करना और ट्रांसक्रिप्ट को छोड़ना → पहचान इस बातचीत से बंधी होनी चाहिए →
CertificateVerifyऔरFinishedकी अलग-अलग भूमिकाओं की व्याख्या करें। - रेज़्यूम्प्शन को 0-RTT के बराबर मानना → फिर से शुरू किया गया कनेक्शन 1-RTT हैंडशेक की प्रतीक्षा कर सकता है → पहले PSK रेज़्यूम्प्शन का वर्णन करें और अर्ली डेटा को वैकल्पिक बताएं।
- 0-RTT को मुफ़्त RTT कमी के रूप में मानना → अर्ली डेटा फ़ॉरवर्ड सीक्रेट नहीं है और इसे रीप्ले किया जा सकता है → जोखिम को एप्लिकेशन प्रभावों से मैप करें।
- स्वचालित रूप से हर GET की अनुमति देना → एक GET टोकन का उपभोग कर सकता है, उपयोग का बिल बना सकता है, या महंगे काम को ट्रिगर कर सकता है → वास्तविक संसाधन सेमेंटिक्स के अनुसार अनुमति दें।
- यह मान लेना कि एक इडेम्पोटेंसी कुंजी ट्रांसफ़र रीप्ले को हल करती है → क्लस्टर संगति और आसपास के प्रभाव अभी भी डुप्लिकेट हो सकते हैं → उच्च जोखिम वाले राइट्स पर हैंडशेक पूरा होने की प्रतीक्षा करें।
- केवल CDN को कॉन्फ़िगर करना और ओरिजिन की उपेक्षा करना → TLS समाप्ति और HTTP अग्रेषण दो सुरक्षा सीमाओं को पार करते हैं → एज, गेटवे, मूल, क्लाइंट और
425व्यवहार को संरेखित करें।
अनुवर्ती प्रश्न
अनुवर्ती 1: TLS 1.3 TLS 1.2 से तेज़ क्यों है?
एक सामान्य पूर्ण TLS 1.3 हैंडशेक पुराने डिज़ाइनों से अप्रचलित एल्गोरिदम और कई अनावश्यक संदेशों को हटाते हुए, एक नेटवर्क राउंड ट्रिप के भीतर पैरामीटर पर बातचीत कर सकता है और सर्वर को प्रमाणित कर सकता है। इसका अधिक एकीकृत की-शेड्यूल और रेज़्यूम्प्शन तंत्र भी मदद करता है। कुल अनुरोध विलंबता में अभी भी DNS, TCP, सर्वर प्रोसेसिंग और एप्लिकेशन डेटा शामिल हैं। "TLS 1.3 1-RTT है" का मतलब यह नहीं है कि पूरे अनुरोध में हमेशा केवल एक RTT खर्च होता है।
अनुवर्ती 2: यदि प्रमाणपत्र की निजी कुंजी लीक हो जाए तो ऐतिहासिक ट्रैफ़िक का क्या होता है?
यदि उन पूर्ण हैंडशेक ने अल्पकालिक ECDHE का उपयोग किया और कार्यान्वयन ने अल्पकालिक निजी मूल्यों और अप्रचलित ट्रैफ़िक रहस्यों को मिटा दिया, तो केवल दीर्घकालिक प्रमाणपत्र कुंजी लीक होने से पहले कैप्चर किए गए एप्लिकेशन ट्रैफ़िक को डिक्रिप्ट नहीं किया जाना चाहिए। यही फ़ॉरवर्ड सीक्रेसी का महत्व है। लीक हुई टिकट एन्क्रिप्शन कुंजी, PSK, सत्र रहस्य, या एंडपॉइंट ट्रैफ़िक रहस्य का एक अलग प्रभाव होता है और टिकट जीवनकाल, लॉग और रोटेशन के विरुद्ध इसका मूल्यांकन किया जाना चाहिए।
अनुवर्ती 3: एंटी-रीप्ले स्टोर 0-RTT के लिए हर अनुरोध को सुरक्षित क्यों नहीं बनाता है?
एक वैश्विक बहु-क्षेत्रीय प्रणाली विलंबता जोड़े बिना आसानी से हर टिकट और अर्ली-डेटा स्वीकृति को दृढ़ता से सुसंगत और एकल-उपयोग नहीं बना सकती है। नेटवर्क विभाजन, नोड स्थिति, टिकट रोटेशन और समवर्ती हमलावर रीप्ले सीमाएं बनाते हैं। प्रोटोकॉल नियंत्रण विंडो या सफल रीप्ले की संख्या को सीमित कर सकते हैं, लेकिन एप्लिकेशन को अभी भी यह मान लेना चाहिए कि डुप्लिकेट अनुरोध हो सकते हैं और अर्ली डेटा को उपयुक्त संचालन तक सीमित करना चाहिए।
अनुवर्ती 4: आप कैसे सत्यापित करते हैं कि प्रोडक्शन ने पूर्ण हैंडशेक, रेज़्यूम्प्शन, या 0-RTT का उपयोग किया है?
एक अधिकृत परीक्षण वातावरण में, संस्करण, प्रमाणपत्र और ALPN का निरीक्षण करने के लिए openssl s_client -connect api.example:443 -servername api.example -tls1_3 -alpn h2 का उपयोग करें। एक सत्र को सहेजें और पुन: उपयोग करें, फिर देखें कि क्या यह फिर से शुरू होता है और क्या अर्ली डेटा स्वीकार किया जाता है। सर्वर टेलीमेट्री को संवेदनशील सामग्री के बिना हैंडशेक मोड और अस्वीकृति कारण रिकॉर्ड करना चाहिए। केवल क्लाइंट-निर्यात सत्र कुंजियों के साथ एक नियंत्रित वातावरण में पैकेट कैप्चर को डिक्रिप्ट करें, फिर उन्हें साफ करें।
अनुवर्ती 5: क्या 425 Too Early एक आउटेज (outage) है?
जरूरी नहीं। इसका मतलब है कि सर्वर रीप्ले जोखिम से इनकार करता है और यह एक सामान्य अर्ली-डेटा नियंत्रण पथ है। क्लाइंट को हैंडशेक पूरा होने के बाद पुनः प्रयास करना चाहिए, और पुनः प्रयास में अर्ली डेटा का उपयोग नहीं किया जाना चाहिए। यदि उपयोगकर्ता बार-बार विफलताएं देखते हैं, तो क्लाइंट के पुनः प्रयास कार्यान्वयन, Early-Data के प्रचार, सर्वर इंस्टेंसेस में संगति, और क्या किसी अनुपयुक्त एंडपॉइंट को गलती से 0-RTT अनुमति सूची में जोड़ा गया था, इसकी पुष्टि करें।