सामान्य साक्षात्कार: आप TLS Encrypted ClientHello को सुरक्षित रूप से कैसे तैनात करेंगे?

प्रश्न और कार्यक्षेत्र (Scope)

एक एंटरप्राइज़ नेटवर्क मध्यस्थों को दिखाई देने वाले लक्षित साइट के नाम को कम करना चाहता है, लेकिन लेगेसी क्लाइंट्स, TLS-निरीक्षण करने वाले प्रॉक्सी और पुराने कॉन्फ़िगरेशन को लेकर चिंतित है। ClientHelloInner, ClientHelloOuter, ECHConfig, DNS प्रकाशन, shared या split टोपोलॉजी, की रोटेशन, और डाउनग्रेड सुरक्षा को कवर करते हुए एक ECH रोलआउट, मॉनिटरिंग और फ़ॉलबैक योजना डिज़ाइन करें।

RFC 9849, ECH को सर्वर की पब्लिक की के तहत ClientHello को एन्क्रिप्ट करने के रूप में परिभाषित करता है; RFC 9848, SVCB और HTTPS रिकॉर्ड्स के माध्यम से कॉन्फ़िगरेशन प्रकाशन को परिभाषित करता है। ECH चुनिंदा हैंडशेक मेटाडेटा की सुरक्षा करता है। यह IP पते, ट्रैफ़िक पैटर्न या स्वयं एंडपॉइंट्स को नहीं छिपाता है।

साक्षात्कारकर्ता क्या परख रहा है

• सार्वजनिक outer लिफाफे (envelope), वास्तविक inner हैंडशेक, और इसे कौन डिक्रिप्ट और फ़ॉरवर्ड करता है, इसकी व्याख्या।
• ECHConfig स्रोत, कॉन्फ़िगरेशन पहचानकर्ता, की रोटेशन और DNS-कैश संगति का विवरण।
• स्पष्ट विश्वास और प्रमाणपत्र सीमाओं के साथ shared और split मोड की तुलना।
• यह दावा करने से बचना कि ECH सभी ट्रैफ़िक को अज्ञात (anonymous) बना देता है; IP, DNS, ट्रैफ़िक विश्लेषण और एंडपॉइंट्स पर चर्चा करना।
• लेगेसी क्लाइंट्स, मिडिलबॉक्स, निरीक्षण, retry_configs और असुरक्षित डाउनग्रेड पाथ को संभालना।
• स्वीकृति, पुनः प्रयास (retries), हैंडशेक त्रुटियों और पॉलिसी-हिट मेट्रिक्स के साथ रोलआउट को सत्यापित करना।

पहले स्पष्ट करने योग्य प्रश्न

1. क्या लक्ष्य सार्वजनिक पर्यवेक्षकों से SNI छिपाना है, या एंटरप्राइज़ निरीक्षण, क्षेत्रीय नीति या अनुपालन प्रतिधारण (compliance retention) को भी संतुष्ट करना है?
2. क्लाइंट DNS रिज़ॉल्वर और ब्राउज़र नीति को कौन नियंत्रित करता है? लेगेसी-क्लाइंट, मोबाइल-नेटवर्क और एंटरप्राइज़-प्रॉक्सी का हिस्सा क्या है?
3. क्या कोई एक सेवा TLS को समाप्त (terminate) करती है, या कोई एज प्रदाता डिक्रिप्ट करके बैकएंड पर फ़ॉरवर्ड करता है?
4. कौन सा DNS TTL और की-ओवरलैप विंडो स्वीकार्य है, और क्या किसी घटना के दौरान ECH को अस्थायी रूप से अक्षम किया जा सकता है?
5. किन मेट्रिक्स में वास्तविक डोमेन या उपयोगकर्ता पहचान को बाहर रखा जाना चाहिए, और लॉग कितने समय तक रखे जाते हैं?

30-सेकंड का उत्तर

मैं पहले खतरे के मॉडल (threat model) को परिभाषित करूँगा: ECH, ClientHello में वास्तविक साइट के नाम को छिपाता है, न कि IP पते या ट्रैफ़िक पैटर्न को। सर्वर ECHConfig प्रकाशित करता है; क्लाइंट एक एन्क्रिप्टेड inner और एक सार्वजनिक outer बनाता है; एज डिक्रिप्ट करता है और inner को बैकएंड को सौंप देता है। मैं इसे कैनरी (canary) के रूप में जारी करूँगा, स्वीकृति, पुनः प्रयास और हैंडशेक त्रुटियों को मापूँगा, और एक ओवरलैप विंडो के साथ कीज़ को रोटेट करूँगा। लेगेसी क्लाइंट सामान्य TLS का उपयोग कर सकते हैं, लेकिन ECH विफलता से वास्तविक SNI आँख मूंदकर उजागर नहीं होना चाहिए। एंटरप्राइज़ नीति को नियंत्रित DNS या एक स्पष्ट प्रॉक्सी सीमा पर ले जाना चाहिए, जिसमें एक परीक्षित सुरक्षित फ़ॉलबैक हो।

चरण-दर-चरण गहन विश्लेषण

1. सुरक्षा सीमा को परिभाषित करें

ECH एक पर्यवेक्षक को वास्तविक SNI के बजाय एक सार्वजनिक नाम या एज सेवा देखने की अनुमति देता है। IP पता, समय (timing), पैकेट आकार, DNS एन्क्रिप्ट न होने पर DNS प्रश्न, और एंडपॉइंट प्रमाणपत्र नीति अभी भी जानकारी लीक कर सकती है। लक्ष्य को हैंडशेक मेटाडेटा को कम करना बताएं, न कि कनेक्शन को पूरी तरह से अज्ञात बनाना।

2. inner और outer प्रवाह को समझाएं

क्लाइंट ECHConfig से एक की और पैरामीटर चुनता है, वास्तविक ClientHello को ClientHelloInner में रखता है, और encrypted_client_hello एक्सटेंशन के साथ ClientHelloOuter का निर्माण करता है। Outer एक सार्वजनिक नाम का उपयोग करता है। एज इसे प्रमाणित और डिक्रिप्ट करता है, फिर inner को बैकएंड पर भेजता है। सर्वर outer से जुड़े डेटा को प्रमाणित करता है ताकि कोई हमलावर outer फ़ील्ड को संशोधित न कर सके।

DNS HTTPS/SVCB -> ECHConfig(public name, key, config_id)
client -> encrypt(ClientHelloInner) -> ClientHelloOuter
edge -> decrypt and validate -> backend handles ClientHelloInner

3. shared या split टोपोलॉजी चुनें

Shared मोड में एक ही सेवा क्लाइंट का सामना करती है और बैकएंड TLS को समाप्त करती है। Split मोड में एज ECH को डिक्रिप्ट करता है और inner को एक स्वतंत्र बैकएंड पर फ़ॉरवर्ड करता है। Split मोड के लिए स्पष्ट एज-टू-बैकएंड विश्वास, प्रमाणपत्र, कनेक्शन सुरक्षा और विफलता के स्वामित्व की आवश्यकता होती है; एज स्वचालित रूप से कोई हानिरहित प्लेनटेक्स्ट पर्यवेक्षक नहीं होता है।

4. कॉन्फ़िगरेशन प्रकाशित करें और कीज़ रोटेट करें

नियंत्रित TTL के साथ HTTPS/SVCB रिकॉर्ड्स में ECHConfig प्रकाशित करें, और रोटेशन के दौरान पुराने और नए दोनों कॉन्फ़िगरेशन परोसें। प्रत्येक कॉन्फ़िगरेशन में एक पब्लिक की, संस्करण और पहचानकर्ता होता है। DNS कैशिंग, कॉन्फ़िगरेशन चयन और डिक्रिप्शन विफलताओं की निगरानी करें। पुरानी प्राइवेट की को कैश, कनेक्शन और पुनः प्रयास विंडो समाप्त होने के बाद ही रिटायर करें।

5. विफलता और लेगेसी क्लाइंट्स को संभालना

ECH के बिना क्लाइंट सामान्य TLS का उपयोग कर सकते हैं; ECH-सक्षम क्लाइंट retry_configs प्राप्त करने के बाद सेटिंग्स को रीफ़्रेश कर सकते हैं। RFC 9849 क्लाइंट को ECH अस्वीकृति के बाद बस एक अनएन्क्रिप्टेड वास्तविक ClientHello भेजने से रोकता है, क्योंकि एक सक्रिय हमलावर SNI प्रकटीकरण को प्रेरित कर सकता है। सर्वरों को प्रत्येक संभावित एंडपॉइंट को सार्वजनिक नाम के लिए मान्य प्रमाणपत्र के साथ प्रोविज़न करना चाहिए।

6. मिडिलबॉक्स और एंटरप्राइज़ नीति को संभालना

एक TLS-समाप्त करने वाला प्रॉक्सी जो ECH को नहीं समझता है, वह सार्वजनिक outer नाम का उपयोग करके कनेक्ट हो सकता है, इसलिए SNI-आधारित निरीक्षण मेल खाना बंद कर सकता है। नीति को एक नियंत्रित DNS रिज़ॉल्वर, स्पष्ट प्रॉक्सी या प्रबंधित ब्राउज़र सीमा पर ले जाएं, और नीति का संस्करण तैयार करें। यह न मानें कि DNS को संशोधित करना हानिरहित है; DNSSEC, क्षेत्रीय नेटवर्क और आपातकालीन अक्षमता का अभ्यास करें।

7. कैनरी और अवलोकन

पहले एक साइट, क्षेत्र और नियंत्रित क्लाइंट समूह को सक्षम करें। ECH स्वीकृति, ech_required, पुनः प्रयास दर, TLS विफलताएं, DNS-कैश हिट और एंड-टू-एंड विलंबता (latency) की तुलना करें। डिफ़ॉल्ट रूप से वास्तविक inner SNI का उपयोग किए बिना कॉन्फ़िगरेशन पहचानकर्ता, एज स्थान और त्रुटि श्रेणियों को लॉग करें। यदि हैंडशेक, नीति प्रवर्तन या संगतता में गिरावट आती है, तो वैश्विक रूप से डाउनग्रेड करने के बजाय साइट या क्लाइंट द्वारा सीमित रूप से अक्षम करें।

उच्च-गुणवत्ता वाला नमूना उत्तर

मैं ECH को SNI गोपनीयता वृद्धि के रूप में रखूँगा, न कि IP या ट्रैफ़िक-पैटर्न अनामिकता के रूप में। DNS द्वारा ECHConfig प्रकाशित करने के बाद, क्लाइंट वास्तविक ClientHelloInner को एन्क्रिप्ट करता है और सार्वजनिक नाम के साथ एक ClientHelloOuter भेजता है। एज इसे सत्यापित और डिक्रिप्ट करता है, फिर स्पष्ट रूप से प्रलेखित shared या split विश्वास मॉडल के तहत inner को एक TLS बैकएंड को सौंपता है।

मैं पहले कैनरी करूँगा, ओवरलैपिंग कॉन्फ़िगरेशन और TTL विंडो के साथ कीज़ को रोटेट करूँगा, और कॉन्फ़िगरेशन चयन, स्वीकृति, retry_configs, ech_required, हैंडशेक त्रुटियों और विलंबता की निगरानी करूँगा। लेगेसी क्लाइंट सामान्य TLS का उपयोग कर सकते हैं, लेकिन ECH-सक्षम क्लाइंट को किसी प्रेरित विफलता के बाद वास्तविक SNI को उजागर नहीं करना चाहिए। SNI-निर्भर एंटरप्राइज़ नियंत्रण DNS या एक स्पष्ट प्रॉक्सी पर चले जाते हैं। लॉग केवल रिडैक्टेड पहचानकर्ताओं और त्रुटि श्रेणियों को रखते हैं, और रोलबैक और DNSSEC परिदृश्यों का पूर्वाभ्यास किया जाता है।

सामान्य गलतियाँ

• यह दावा करना कि ECH, IP और सभी ट्रैफ़िक सुविधाओं को छिपाता है → खतरे के मॉडल को बढ़ा-चढ़ाकर पेश किया गया है → बताएं कि यह चुनिंदा ClientHello मेटाडेटा की सुरक्षा करता है।
• DNS-कैश और रोटेशन डिज़ाइन के बिना एक की प्रकाशित करना → क्लाइंट पुरानी सेटिंग्स बनाए रखते हैं → TTL, ओवरलैप और रिटायरमेंट शर्तों को परिभाषित करें।
• ECH विफलता के बाद स्पष्ट पाठ (cleartext) में वास्तविक SNI भेजना → एक सक्रिय हमलावर प्रकटीकरण को प्रेरित कर सकता है → अस्वीकृति, पुनः प्रयास और सुरक्षित समाप्ति नियमों का पालन करें।
• एज डिक्रिप्शन को विश्वास-मुक्त प्लेनटेक्स्ट हैंडलिंग के रूप में मानना → split-मोड सीमाएँ गायब हैं → एज, बैकएंड, प्रमाणपत्र और लिंक-सुरक्षा कर्तव्यों का नाम दें।
• केवल सफल हैंडशेक को मापना → लेगेसी और एंटरप्राइज़ रिग्रेशन अदृश्य हो जाते हैं → क्लाइंट, नेटवर्क, क्षेत्र और त्रुटि वर्ग द्वारा खंडित करें।

अनुवर्ती प्रश्न और उत्तर

क्या ECH DNS लीकेज को रोकता है?

नहीं। ECHConfig आमतौर पर HTTPS/SVCB रिकॉर्ड के माध्यम से प्राप्त किया जाता है; एक अनएन्क्रिप्टेड DNS पाथ अभी भी क्वेरी को प्रकट कर सकता है। ECH, एन्क्रिप्टेड DNS, प्रमाणपत्रों और नेटवर्क नीति का अलग-अलग मूल्यांकन करें।

split मोड में एज क्या देख सकता है?

इसे ECH को डिक्रिप्ट करना होगा और inner को फ़ॉरवर्ड करना होगा, इसलिए यह हैंडशेक प्रोसेसिंग के लिए आवश्यक जानकारी देखता है। एप्लिकेशन दृश्यता इस बात पर निर्भर करती है कि बाद का TLS कहाँ समाप्त होता है। न्यूनतम विश्वास, लिंक सुरक्षा और लॉग सीमाओं का दस्तावेजीकरण करें।

विफलता के बाद सामान्य ClientHello का पुनः प्रयास क्यों नहीं किया जाता?

एक सक्रिय हमलावर ECH विफलता का कारण बन सकता है और वास्तविक-SNI प्रकटीकरण को प्रेरित कर सकता है। एक सुरक्षित कार्यान्वयन क्लाइंट फ़ॉलबैक नियमों के भीतर retry_configs, सार्वजनिक-नाम प्रमाणीकरण, या कनेक्शन समाप्ति का उपयोग करता है।

आप ECH कीज़ को कैसे रोटेट करते हैं?

DNS TTL, कनेक्शन लाइफटाइम और पुनः प्रयास विंडो के माध्यम से पुराने कॉन्फ़िगरेशन को बनाए रखते हुए नया कॉन्फ़िगरेशन प्रकाशित करें। कॉन्फ़िगरेशन पहचानकर्ता द्वारा हिट और डिक्रिप्शन विफलताओं का निरीक्षण करें, फिर ओवरलैप अवधि के बाद पुरानी प्राइवेट की को रिटायर करें।

क्या होगा यदि किसी एंटरप्राइज़ को SNI का निरीक्षण करना ही पड़े?

नीति और कानूनी सीमाओं को स्पष्ट करें, फिर चुनिंदा रूप से एक नियंत्रित DNS रिज़ॉल्वर, स्पष्ट प्रॉक्सी, या एंडपॉइंट-प्रबंधन नीति का उपयोग करें। यह न मानें कि DNS रीराइटिंग की कोई DNSSEC, संगतता या उपलब्धता लागत नहीं है।

TLS सफलता स्थिर रहने के दौरान स्वीकृति दर गिर जाती है। आप क्या निरीक्षण करेंगे?

DNS रिज़ॉल्वर, क्लाइंट संस्करणों, एज स्थानों और कॉन्फ़िगरेशन पहचानकर्ताओं की तुलना करें। HTTPS-रिकॉर्ड कैशिंग, की संस्करणों, सार्वजनिक-नाम प्रमाणपत्रों और retry_configs की जाँच करें; एक कॉन्फ़िगरेशन परिवर्तन को हैंडशेक दोष से अलग करें।