प्रॉम्प्ट और संदर्भ
CDN edge nodes बहुत अधिक संख्या में होते हैं और उजागर (exposed) होते हैं, इसलिए long-lived certificate key को वितरित करने से compromise का प्रभाव बढ़ जाता है। RFC 9345 का उपयोग करते हुए, Delegated Credentials (DC) डिज़ाइन करें: certificate holder एक short-lived credential जारी करता है, edge इसका उपयोग TLS authentication के लिए करता है, और यह कोई अन्य DC जारी नहीं कर सकता है। Handshake validation, expiry, rotation, revocation limits और fallback को कवर करें।
इंटरव्यूअर क्या टेस्ट कर रहा है
मुख्य संकेत एक DC और एक X.509 end-entity certificate के बीच binding, short-lived key की authority boundary, TLS extension negotiation, time windows और compromise impact को समझना हैं। मजबूत उत्तर exposure time को कम करने और instant revocation के बीच अंतर स्पष्ट करते हैं और DC support के बिना clients के लिए सुरक्षित fallback की व्याख्या करते हैं।
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
ट्रैफिक और टर्मिनेशन पॉइंट
पुष्टि करें कि TLS, CDN पर, regional gateway पर, या origin पर समाप्त होता है, क्या edges प्रशासनिक डोमेन में फैले हैं, और क्या DTLS या QUIC शामिल हैं। Termination point issuance और distribution paths को निर्धारित करता है।
क्लाइंट कम्पैटिबिलिटी मैट्रिक्स
Browser, mobile, IoT और आंतरिक client versions की पहचान करें और क्या उनके TLS stacks को अपग्रेड किया जा सकता है। DC के लिए extension negotiation और नए validation की आवश्यकता होती है, इसलिए support मानकर नहीं चला जा सकता है।
कॉम्प्रोमाइज का उद्देश्य
स्पष्ट करें कि लक्ष्य long-lived key exposure को सीमित करना है, edge-key lifetime को सीमित करना है, या दोनों को। जांचें कि क्या compliance के लिए एक अलग revocation list या forced withdrawal की आवश्यकता है।
30-सेकंड उत्तर ढांचा
“Certificate holder एक short-lived DC जारी करता है, जिसके signature, usage और lifetime को end-entity certificate key के साथ मान्य (validate) किया जाता है। Edges को केवल DC private key प्राप्त होती है और वे कोई अन्य DC नहीं बना सकते; clients TLS extension flow के दौरान binding को validate करते हैं। Long-lived key की सुरक्षा करते हुए short lifetimes, overlapping rotation और key isolation का उपयोग करें। असमर्थित clients एक स्पष्ट ordinary-certificate path का उपयोग करते हैं; validation विफलताओं को कभी भी चुपचाप डाउनग्रेड नहीं किया जाता है। Compromise response अल्प समाप्ति, issuance रोकने और आवश्यकता पड़ने पर parent certificate को revoke करने पर निर्भर करता है—न कि instant DC revocation मान लेने पर।”
गहराई से उत्तर देने के चरण
चरण 1: जारी करने के संबंध (issuance relationship) को परिभाषित करें
End-entity certificate के अनुरूप long-lived private key रखने वाला एक issuer, DC public key, lifetime, signature algorithm और TLS/DTLS usage information बनाता है। End-entity public key हस्ताक्षर की पुष्टि करती है। Edges को DC private key और public credential प्राप्त होते हैं, कभी भी parent private key नहीं मिलती।
चरण 2: अथॉरिटी और उपयोग को सीमित करें
DC private key सहमत TLS authentication भूमिका तक सीमित है और अन्य DC जारी नहीं कर सकती। DelegationUsage, algorithm compatibility और protocol context को validate करें ताकि केवल TLS-only credential को सामान्य signing key के रूप में न माना जाए।
चरण 3: हैंडशेक के दौरान मान्य करें
Client पारंपरिक X.509 chain, फिर DC signature, lifetime, parent binding और handshake context को validate करता है। यदि extension negotiation विफल हो जाता है, तो एक स्पष्ट ordinary-certificate path का उपयोग करें। अज्ञात या असंगत सुरक्षा फ़ील्ड्स को अनदेखा करने के बजाय validation fail होना चाहिए।
चरण 4: रोटेशन विंडो डिज़ाइन करें
Edge clock skew, propagation delay और अधिकतम handshake duration के लिए overlap सेट करें। पुराने क्रेडेंशियल के वैध रहते हुए स्विच करने से पहले नया DC लोड करें; वितरण की पुष्टि होने के बाद ही पुराने क्रेडेंशियल को बंद करें। Time synchronization और monitoring सीमा (boundary) को कवर करते हैं।
चरण 5: कॉम्प्रोमाइज और रिवोकेशन को संभालें
DC private key वाला एक हमलावर उस DC के समाप्त होने तक नए कनेक्शनों में पार्टी का प्रतिरूपण (impersonate) कर सकता है, लेकिन वह दूसरा DC जारी नहीं कर सकता। प्रतिक्रिया में issuance रोकना, lifetimes छोटा करना, edge credentials वापस लेना और, यदि आवश्यक हो, parent को revoke करना या ordinary certificate पर स्विच करना शामिल है। DC कोई instant-revocation तंत्र नहीं है।
चरण 6: कम्पैटिबिलिटी और फॉलबैक की योजना बनाएं
Extension support सत्यापित करने के लिए client matrix और staged traffic का उपयोग करें। असमर्थित clients long-lived-certificate termination path का पालन करते हैं जबकि parent key अलग (isolated) रहती है। “Peer lacks support” को “validation failed” से अलग पहचानें; validation विफलता को कभी भी plaintext या किसी मनमाने certificate पर डाउनग्रेड न करें।
चरण 7: निरीक्षण और अभ्यास करें
Private keys को लॉग किए बिना issuance, distribution, loading, handshake failures, clock skew और fallback rates रिकॉर्ड करें। कम जीवनकाल के भीतर रिकवरी सत्यापित करने के लिए edge compromise, issuer outage, parent revocation और पूर्ण fallback का अभ्यास (rehearse) करें।
उच्च गुणवत्ता वाला नमूना उत्तर
मैं long-lived certificate key को एक issuer में रखूँगा और इसका उपयोग short-lived DCs पर हस्ताक्षर करने के लिए करूँगा; edges को केवल प्रत्येक DC private key प्राप्त होगी। Handshake के दौरान, X.509 chain, फिर DC binding, usage, algorithm, lifetime और handshake context को validate करें। Overlap के साथ rotate करें, clocks की निगरानी करें, compatibility को चरणबद्ध करें, और पुराने clients के लिए एक स्पष्ट fallback प्रदान करें। यदि कोई DC लीक हो जाता है, तो issuance रोकें, edge credentials वापस लें, expiry की प्रतीक्षा करें, और आवश्यकता पड़ने पर parent को revoke करें। Validation failures और fallback rates की निगरानी करें; DC कोई त्वरित निरस्तीकरण (instant revocation) नहीं है।
सामान्य गलतियाँ
- गलती: यह मान लेना कि लीक हुए DC को OAuth token की तरह तुरंत revoke किया जा सकता है। → कारण: RFC अल्पकालिक जीवनकाल और parent binding पर केंद्रित है। → सुधार: Lifetime छोटा करें और parent revocation और withdrawal की तैयारी करें।
- गलती: DC private key वाले edge को और अधिक DCs जारी करने की अनुमति देना। → कारण: यह delegation chain और authority का विस्तार करता है। → सुधार: Parent key को एक नियंत्रित issuer में रखें।
- गलती: Extension support न होने पर फ़ील्ड्स को अनदेखा करना। → कारण: Negotiation compatibility का अर्थ validation success नहीं है। → सुधार: Unsupported, validation failure और ordinary fallback को अलग रखें।
- गलती: केवल issuance timestamp के आधार पर rotate करना। → कारण: Propagation और clock skew के कारण edges बहुत जल्दी या बहुत देर से credential का उपयोग कर सकते हैं। → सुधार: Overlap का उपयोग करें और time synchronization की निगरानी करें।
फॉलो-अप प्रश्न और उत्तर
फॉलो-अप 1: DC एक साधारण short-lived X.509 certificate से कैसे भिन्न है?
एक DC मौजूदा end-entity certificate से बंधा होता है और TLS handshake में उपयोग किया जाता है, इसलिए edge को parent private key रखने की आवश्यकता नहीं होती है। एक साधारण short-lived certificate के लिए आमतौर पर अभी भी CA या certificate system को एक पूरी श्रृंखला जारी करने की आवश्यकता होती है। उनकी डिप्लॉयमेंट और वैलिडेशन सीमाएं भिन्न हैं।
फॉलो-अप 2: एक हमलावर DC private key के साथ क्या कर सकता है?
वे DC समाप्त होने तक नए TLS कनेक्शनों में उस पार्टी का प्रतिरूपण कर सकते हैं, लेकिन वे इसका उपयोग दूसरा DC जारी करने के लिए नहीं कर सकते। यह विंडो lifetime, parent की स्थिति, और detection व response की गति पर निर्भर करती है।
फॉलो-अप 3: DelegationUsage की आवश्यकता क्यों है?
यह सीमित करता है कि कौन से certificates स्पष्ट रूप से DC भागीदारी की अनुमति देते हैं, जिससे बिना डेलिगेशन सेमांटिक्स वाले प्रमाणपत्र को DC validation में भेजने से होने वाले क्रॉस-प्रोटोकॉल जोखिम को कम किया जा सके।
फॉलो-अप 4: क्या QUIC या DTLS के लिए एक अलग trust root की आवश्यकता होती है?
किसी नए trust root की आवश्यकता नहीं है, लेकिन usage, handshake fields और algorithms को validate करने के लिए RFC 9345 के protocol context और extension rules का पालन करना चाहिए। उस समीक्षा के बिना TLS पार्सिंग को किसी अन्य प्रोटोकॉल के लिए पुन: उपयोग नहीं किया जा सकता है।