प्रॉम्प्ट और संदर्भ
आप CDN के पीछे एक मल्टी-डोमेन सेवा संचालित करते हैं। सुरक्षा टीम ने देखा कि TLS अभी भी ClientHello में स्पष्ट टेक्स्ट (cleartext) SNI को उजागर करता है और वे Encrypted Client Hello (ECH) का मूल्यांकन करना चाहते हैं। समझाएं कि क्लाइंट ECH कॉन्फ़िगरेशन कैसे प्राप्त करते हैं, बाहरी और आंतरिक ClientHello क्या करते हैं, CDN-से-ओरिजिन सीमा कहाँ होती है, पुराने क्लाइंट कैसे फ़ॉलबैक करते हैं, और कौन से मेट्रिक्स डिप्लॉयमेंट समस्याओं का निदान करते हैं।
साक्षात्कारकर्ता क्या परीक्षण कर रहा है
साक्षात्कारकर्ता चाहता है कि ECH को एक TLS एक्सटेंशन के रूप में वर्णित किया जाए, न कि VPN, एन्क्रिप्टेड DNS, या पूर्ण ट्रैफ़िक गुमनामी के रूप में। क्लाइंट सर्वर द्वारा प्रकाशित पब्लिक की के साथ एक आंतरिक ClientHello को एन्क्रिप्ट करता है और क्लाइंट-फ़ेसिंग सर्वर को एक बाहरी ClientHello भेजता है; बाहरी नाम का उपयोग सार्वजनिक रूटिंग के लिए किया जाता है। एक मजबूत उत्तर में HTTPS/SVCB या समकक्ष कॉन्फ़िगरेशन डिलीवरी, CDN और क्लाइंट समर्थन, और यह तथ्य शामिल होता है कि IP पते, ट्रैफ़िक का आकार, समय (timing) और अन्य साइड चैनल दृश्यमान रहते हैं।
पहले पूछे जाने वाले स्पष्टीकरण प्रश्न
ऑब्ज़र्वर और गोपनीयता लक्ष्य
स्पष्ट करें कि क्या खतरा एक निष्क्रिय ऑब्ज़र्वर (passive observer), एक एंटरप्राइज़ प्रॉक्सी, या एक सक्रिय मैन-इन-द-मिडिल (active man-in-the-middle) है, और क्या गेटवे को अभी भी डोमेन नीति लागू करनी होगी। प्रत्येक ऑब्ज़र्वर IP, DNS, बाहरी नाम और समय का एक अलग संयोजन देखता है।
टोपोलॉजी और की (Key) सीमा
पुष्टि करें कि ECH CDN एज पर समाप्त होता है या स्व-प्रबंधित प्रवेश बिंदु पर और क्या ओरिजिन को अभी भी स्वतंत्र TLS की आवश्यकता है। ECH प्राइवेट-की रोटेशन, वितरण और निरसन (revocation) के लिए स्वामित्व सौंपें; CDN पब्लिक की कोई ओरिजिन प्रमाणपत्र नहीं है।
अनुकूलता और फ़ॉलबैक नीति
लक्षित ब्राउज़र, ऑपरेटिंग सिस्टम, DoH/DoT, HTTP/3 और एंटरप्राइज़ मिडिलबॉक्स की पुष्टि करें। स्पष्ट टेक्स्ट SNI पर फ़ॉलबैक करने से अनुकूलता तो बहाल हो जाती है, लेकिन ऑब्ज़र्वर की दृश्यता भी बहाल हो जाती है, इसलिए नीति और मेट्रिक्स को यह तय करना होगा कि यह कब स्वीकार्य है।
30-सेकंड का उत्तर ढाँचा
"ECH सर्वर द्वारा प्रकाशित ECH पब्लिक की के साथ एक आंतरिक ClientHello को एन्क्रिप्ट करता है, जिससे वास्तविक SNI और संवेदनशील एक्सटेंशन अंदर सुरक्षित हो जाते हैं। बाहरी ClientHello एक सार्वजनिक नाम ले जाता है ताकि क्लाइंट-फ़ेसिंग सर्वर कनेक्शन को रूट कर सके। क्लाइंट आमतौर पर HTTPS/SVCB रिकॉर्ड या ब्राउज़र नीति के माध्यम से कॉन्फ़िगरेशन प्राप्त करते हैं, और एज TLS 1.3 जारी रखने से पहले आंतरिक संदेश को डिक्रिप्ट करता है। विफलता पर, नीति पुनः प्रयास (retry) कर सकती है या निरस्त (abort) कर सकती है; स्पष्ट टेक्स्ट SNI फ़ॉलबैक में गोपनीयता कमजोर होती है। ECH अभी भी IP, DNS, समय या ट्रैफ़िक वॉल्यूम को नहीं छिपाता है, इसलिए इसका मूल्यांकन DNS, CDN, निगरानी और की (key) रोटेशन के साथ किया जाना चाहिए।"
चरण-दर-चरण गहन उत्तर
चरण 1: ECH कॉन्फ़िगरेशन प्रकाशित करें
सेवा एक ECHConfig प्रकाशित करती है जिसमें एक पब्लिक की, संस्करण और एनकैप्सुलेशन मेटाडेटा होता है। एक क्लाइंट इसे विश्वसनीय HTTPS/SVCB रिकॉर्ड या ब्राउज़र कॉन्फ़िगरेशन से प्राप्त करता है और इसके स्रोत को मान्य करता है। कॉन्फ़िगरेशन को वर्ज़निंग और समाप्ति (expiry) की आवश्यकता होती है; पुरानी कीज़ को अनिश्चित काल तक कैश्ड नहीं रहना चाहिए।
चरण 2: बाहरी और आंतरिक हैंडशेक बनाएं
क्लाइंट ECH पब्लिक की के साथ एन्क्रिप्ट किए गए आंतरिक ClientHello में वास्तविक SNI, ALPN और संवेदनशील एक्सटेंशन डालता है। बाहरी ClientHello सार्वजनिक नाम और एन्क्रिप्टेड पेलोड ले जाता है। वह नाम अंतिम सेवा डोमेन को प्रकट करने के बजाय ECH-सक्षम क्लाइंट-फ़ेसिंग सर्वर की ओर इंगित करता है।
चरण 3: एज पर संदेश को प्रोसेस करें
एज बाहरी ClientHello प्राप्त करता है और ECH प्राइवेट की का प्रयास करता है। सफलता पर, यह आंतरिक मापदंडों से प्रमाणपत्र और रूटिंग का चयन करता है; विफलता पर, यह एक पुनः प्रयास (retry) कॉन्फ़िगरेशन भेजता है या TLS नियमों के अनुसार समाप्त करता है। एज से ओरिजिन तक TLS एक स्वतंत्र सुरक्षा सीमा बनी रहती है; ECH ओरिजिन प्रमाणीकरण को प्रतिस्थापित नहीं करता है।
चरण 4: फ़ॉलबैक और अटैक सरफ़ेस को संभालें
समाप्त हो चुका कॉन्फ़िगरेशन, असंगत संस्करण, DNS छेड़छाड़, या अवरोधक मिडिलबॉक्स ECH को रोक सकते हैं। सर्वर एक विश्वसनीय पुनः प्रयास कॉन्फ़िगरेशन प्रकाशित कर सकता है और क्लाइंट को पुनः प्रयास करने दे सकता है। यदि स्पष्ट टेक्स्ट SNI फ़ॉलबैक की अनुमति है, तो इसे सीमित करें और लॉग करें। कभी भी किसी मनमाने पुनः प्रयास कॉन्फ़िगरेशन को सफलता के प्रमाण के रूप में न मानें, क्योंकि डाउनग्रेड और गलत रूटिंग संभव है।
चरण 5: बताएं कि क्या छिपा है और क्या नहीं
ECH मुख्य रूप से ClientHello में साइट का नाम और संबंधित एक्सटेंशन छुपाता है। ऑब्ज़र्वर अभी भी DNS क्वेरीज़, बाहरी नाम, गंतव्य IP, हैंडशेक समय, कनेक्शन गणना, पैकेट आकार और बाद के ट्रैफ़िक पैटर्न देख सकते हैं। एक अद्वितीय बाहरी नाम या एक छोटा डिप्लॉयमेंट गुमनामी सेट (anonymity set) को छोटा कर सकता है।
चरण 6: कीज़ और संचालन का संचालन करें
ECH प्राइवेट कीज़ के लिए रोटेशन, दोहरी स्वीकृति, रोलबैक और आपातकालीन निरसन प्रक्रियाएं प्रदान करें। एज नोड्स में प्रकाशन समय, क्लाइंट स्वीकृति, पुनः प्रयास दर, डिक्रिप्शन विफलताएं, TLS अलर्ट और संस्करण विषमता की निगरानी करें। ऐसे नैदानिक पहचानकर्ताओं का उपयोग करें जिनमें आंतरिक SNI शामिल न हो; लॉग को उस संवेदनशील डेटा को फिर से बनाना नहीं चाहिए जिसे ECH को सुरक्षित रखना था।
चरण 7: धीरे-धीरे रोल आउट और सत्यापित करें
नियंत्रित डोमेन और समर्थित क्लाइंट पर ECH का कैनरी डिप्लॉयमेंट करें। सफलता, फ़ॉलबैक, निरस्त, हैंडशेक विलंबता, HTTP/2 या HTTP/3 नेगोशिएशन और ओरिजिन त्रुटियों की तुलना करें। समाप्त हो चुके कॉन्फ़िगरेशन, गलत प्राइवेट कीज़, मिडिलबॉक्स और मल्टी-नोड रोटेशन का परीक्षण करें, फिर सत्यापित करें कि पुराने क्लाइंट अभी भी घोषित नीति के तहत काम करते हैं।
उच्च गुणवत्ता वाला नमूना उत्तर
ECH एक TLS 1.3 एक्सटेंशन है जो ECHConfig पब्लिक की के साथ एक आंतरिक ClientHello को एन्क्रिप्ट करता है। वास्तविक SNI और ALPN आंतरिक संदेश में रहते हैं; बाहरी ClientHello एक सार्वजनिक नाम और एन्क्रिप्टेड पेलोड ले जाता है। एक ECH-सक्षम CDN एज आंतरिक संदेश को डिक्रिप्ट करता है और प्रमाणपत्र और रूट का चयन करता है। एज-टू-ओरिजिन TLS अलग रहता है, और ECH ओरिजिन प्रमाणीकरण को प्रतिस्थापित नहीं करता है।
मैं पहले थ्रेट मॉडल, DNS/SVCB डिलीवरी, CDN की स्वामित्व और फ़ॉलबैक नीति को परिभाषित करूँगा। समाप्त हो चुका कॉन्फ़िगरेशन, संस्करण बेमेल, या मिडिलबॉक्स हस्तक्षेप एक विश्वसनीय पुनः प्रयास को ट्रिगर कर सकता है; स्पष्ट टेक्स्ट SNI फ़ॉलबैक केवल स्पष्ट नीति द्वारा अनुमत है और इसे मापा जाता है। ECH हैंडशेक फ़ील्ड को छुपाता है, IP, DNS, समय या ट्रैफ़िक वॉल्यूम को नहीं। रोलआउट के दौरान मैं वर्ज़न्ड कॉन्फ़िगरेशन और प्रतिवर्ती (reversible) की रोटेशन का उपयोग करके स्वीकृति, पुनः प्रयास, डिक्रिप्शन विफलता, विलंबता और ओरिजिन त्रुटियों की निगरानी करूँगा।
सामान्य गलतियाँ
- गलती: यह मान लेना कि ECH प्रत्येक विज़िट को गुमनाम बना देता है। → यह क्यों विफल होता है: IP, DNS, समय और वॉल्यूम अभी भी एक कनेक्शन को सहसंबंधित कर सकते हैं। → सुधार: DNS और CDN डिप्लॉयमेंट सहित गुमनामी सेट और शेष साइड चैनलों का वर्णन करें।
- गलती: ECH प्राइवेट की को ओरिजिन प्रमाणपत्र की के रूप में मानना। → यह क्यों विफल होता है: एज डिक्रिप्शन और ओरिजिन प्रमाणीकरण अलग-अलग सीमाएँ हैं। → सुधार: की लाइफ़साइकिल, अनुमतियाँ और रोटेशन को अलग करें।
- गलती: ECH विफल होने के बाद बिना शर्त फ़ॉलबैक करना। → यह क्यों विफल होता है: एक हमलावर विफलता उत्पन्न कर सकता है और गोपनीयता को डाउनग्रेड कर सकता है। → सुधार: अलर्ट के साथ पुनः प्रयास, निरस्त और फ़ॉलबैक नीति को परिभाषित करें।
- गलती: डिबगिंग के लिए पूर्ण आंतरिक ClientHello को लॉग करना। → यह क्यों विफल होता है: लॉग उस साइट नाम को फिर से उजागर करते हैं जिसे ECH को छिपाना था। → सुधार: संवेदनशील फ़ील्ड के बिना कॉन्फ़िगरेशन संस्करण, नोड और त्रुटि वर्ग को लॉग करें।
अनुवर्ती प्रश्न और उत्तर
अनुवर्ती 1: ECH ESNI से कैसे संबंधित है?
ESNI मुख्य रूप से SNI की रक्षा करता था। ECH एक व्यापक आंतरिक ClientHello को एन्क्रिप्ट करता है और बाहरी/आंतरिक समन्वय और कॉन्फ़िगरेशन डिलीवरी को परिभाषित करता है। वर्तमान ECH मानक और डिप्लॉयमेंट दस्तावेज़ीकरण का उपयोग करें; पुरानी ESNI शब्दावली एक पूर्ण कार्यान्वयन योजना नहीं है।
अनुवर्ती 2: जब मिडिलबॉक्स वास्तविक डोमेन को नहीं देख सकता है तो एक एंटरप्राइज़ ट्रैफ़िक का ऑडिट कैसे कर सकता है?
पहले यह निर्धारित करें कि क्या संगठन एंडपॉइंट्स और इग्रेस गेटवे को नियंत्रित करता है। प्रबंधित डिवाइस एक विश्वसनीय एजेंट या प्रॉक्सी को नीति संकेत प्रदान कर सकते हैं। सार्वजनिक नेटवर्क पर, SNI को छिपाना TLS विफलता नहीं है; गोपनीयता और संगठनात्मक दृश्यता को स्पष्ट नीति के माध्यम से समन्वित किया जाना चाहिए।
अनुवर्ती 3: बाहरी नाम गोपनीयता को क्यों प्रभावित करता है?
यदि एक बाहरी नाम केवल एक वास्तविक साइट को सेवा प्रदान करता है, तो IP, DNS और वह नाम अभी भी गंतव्य को संकीर्ण कर सकते हैं। साझा प्रवेश बिंदु और एक बड़ा गुमनामी सेट गोपनीयता में सुधार करते हैं लेकिन रूटिंग, प्रमाणपत्र और परिचालन जटिलता जोड़ते हैं।
अनुवर्ती 4: आप ECH विफलता को सामान्य TLS विफलता से कैसे अलग करते हैं?
सहसंबंधित करें कि क्या क्लाइंट ने ECH भेजा है, कॉन्फ़िगरेशन संस्करण, एज पुनः प्रयास, डिक्रिप्शन-विफलता काउंटर, TLS अलर्ट, नोड और समय विंडो। उसी क्लाइंट पर ECH सक्षम, अक्षम और पुराने कॉन्फ़िगरेशन के साथ पुनरुत्पादन करें ताकि प्रमाणपत्र, ALPN, या ओरिजिन-स्वास्थ्य समस्याओं को ECH विफलताओं के रूप में गलत लेबल न किया जाए।