ECH शामिल है, और SNI फिर भी दिखाई दे रहा है: 2026 में कैसे जांचें

```html

ECH — वेबसाइट के नाम का एन्क्रिप्शन TLS-हैंडशेक में — मार्च 2026 में मानक का दर्जा प्राप्त किया (RFC 9849, Standards Track). फ़ायरफ़ॉक्स और क्रोम इसे डिफ़ॉल्ट रूप से शामिल करते हैं, क्लाउडफ़्लेयर लगभग सभी अपने ग्राहकों को कुंजी प्रदान करता है। हालांकि, अधिकांश उपयोगकर्ताओं के लिए ECH चुपचाप काम नहीं करता: ब्राउज़र सामान्य हैंडशेक पर चला जाता है, और प्रदाता अभी भी देखता है कि आप कहाँ जा रहे हैं।

नीचे बताया गया है कि एक मिनट में कैसे जांचें कि क्या SNI आपके लिए एन्क्रिप्ट किया गया है, यह क्यों अक्सर एन्क्रिप्ट नहीं होता है, और किन परिदृश्यों में ECH मौलिक रूप से बेकार है (स्पॉइलर: एंटी-डिटेक्ट और पार्सिंग के लिए — लगभग हमेशा)।

ECH वास्तव में क्या छुपाता है — और क्या नहीं छुपाता

सामान्य TLS 1.3 में सब कुछ एन्क्रिप्टेड होता है, पहले संदेश — ClientHello को छोड़कर। इसमें SNI का फ़ील्ड खुला होता है जिसमें वह डोमेन होता है, जिससे आप कनेक्ट हो रहे हैं। अधिकांश फ़िल्टरिंग सिस्टम SNI पर काम करते हैं: IP एक CDN के लिए हजारों साइटों पर होता है, और डोमेन दिखाई देता है।

ECH ClientHello को दो भागों में विभाजित करता है:

ClientHelloOuter — यह खुला जाता है, लेकिन एक फर्जी डोमेन-लपेट के साथ। क्लाउडफ़्लेयर के लिए यह cloudflare-ech.com है।
ClientHelloInner — असली डोमेन, ALPN और एन्क्रिप्टेड सार्वजनिक कुंजी द्वारा एन्क्रिप्टेड सिफर सूची।

इस एन्क्रिप्शन के लिए कुंजी ब्राउज़र कनेक्शन से नहीं, बल्कि DNS से लेता है — HTTPS-रिकॉर्ड (प्रकार 65), पैरामीटर ech= से। यहाँ से मुख्य निष्कर्ष है, जिसे लोग भूल जाते हैं: एन्क्रिप्टेड DNS के बिना ECH संभव नहीं है. यदि DNS-रिक्वेस्ट खुली UDP/53 पर जाती है, तो पर्यवेक्षक बस डोमेन का नाम हैंडशेक से पहले देखता है, और फ़िल्टरिंग रिज़ॉल्वर उत्तर से पैरामीटर ech= को काट सकता है — और ECH सक्रिय नहीं होगा।

ECH वास्तव में क्या नहीं छुपाता:

गंतव्य IP पता — हमेशा दिखाई देता है;
ट्रैफ़िक की मात्रा और समय;
क्लाइंट का TLS फ़िंगरप्रिंट (JA3/JA4) — सिफरों और एक्सटेंशनों का सेट खुली हिस्से में रहता है;
आपको साइट के लिए — सर्वर डिक्रिप्शन के बाद वही सब कुछ देखता है जो पहले देखा था।

अंतिम बिंदु — कारण है कि ECH एंटी-बॉट सिस्टम को बायपास करने से संबंधित नहीं है। क्लाउडफ़्लेयर, DataDome और Akamai सर्वर की तरफ काम करते हैं: उन्हें यह परवाह नहीं है कि क्या SNI यात्रा के दौरान एन्क्रिप्ट किया गया था। यदि कार्य है कि स्वचालन के दौरान पहचान में न आना है, तो एक पूरी तरह से अलग परत काम करती है: TLS फ़िंगरप्रिंट को बदलना, जिसके बारे में हमने curl-cffi के माध्यम से JA4 फ़िंगरप्रिंट को बायपास करने के सामग्री में चर्चा की।

जांच #1: क्या ECH अभी काम कर रहा है (10 सेकंड)

ब्राउज़र में खोलें:

https://crypto.cloudflare.com/cdn-cgi/trace

पंक्ति sni= खोजें। दो विकल्प हो सकते हैं:

sni=encrypted — ECH काम कर रहा है, साइट का नाम यात्रा के दौरान छिपा हुआ है;
sni=plaintext — ECH लागू नहीं हुआ, डोमेन खुला पाठ में चला गया।

टर्मिनल में curl के माध्यम से वही पता हमेशा sni=plaintext लौटाएगा — सामान्य curl ECH नहीं कर सकता, और यह एक सुविधाजनक संकेतक है: ऐसा दिखता है जब "बंद" होता है।

जांच #2: क्या डोमेन के पास ECH कुंजी है (dig, बिना ब्राउज़र)

ECH केवल तभी सक्रिय होगा जब डोमेन के DNS में ech= पैरामीटर के साथ HTTPS-रिकॉर्ड हो। कच्चे रिकॉर्ड को देखें:

dig +short TYPE65 example.com @1.1.1.1

उत्तर में FE0D बाइट्स की तलाश करें — यह ECH का एक्सटेंशन कोड है, इसके बाद ECHConfig आता है। व्यावहारिक उदाहरण: सामग्री की तैयारी के समय crypto.cloudflare.com और हमारे डोमेन proxycove.com का रिकॉर्ड 133–136 बाइट लंबा है जिसमें FE0D और फर्जी नाम cloudflare-ech.com हेक्स रूप में शामिल है। जबकि cloudflare.com का रिकॉर्ड छोटा है, 61 बाइट: केवल ALPN और IP सुझाव, बिना ECH के। इसका मतलब है कि क्लाउडफ़्लेयर के बुनियादी ढांचे के भीतर भी ECH सभी डोमेन को नहीं दिया जाता है — यदि किसी विशेष साइट पर यह नहीं है तो आश्चर्यचकित न हों।

यदि dig ignoring invalid type HTTPS की शिकायत करता है — आपके पास उपकरण का पुराना संस्करण है, संख्या रूप TYPE65 का उपयोग करें, जैसा कि ऊपर की कमांड में है।

क्यों ECH आपके लिए सक्रिय नहीं होता: क्रम में पाँच कारण

एन्क्रिप्टेड DNS बंद है। DoH के बिना, ब्राउज़र को विश्वसनीय तरीके से ECHConfig नहीं मिलेगा। फ़ायरफ़ॉक्स में: सेटिंग्स → प्राइवेसी → DNS के माध्यम से HTTPS "उच्च" या "अधिकतम सुरक्षा" मोड में। क्रोम में: सेटिंग्स → सुरक्षा → सुरक्षित DNS का उपयोग करें.
डोमेन के पास बस HTTPS-रिकॉर्ड नहीं है जिसमें ech= है — इसे ऊपर के ब्लॉक में कमांड से जांचा जाता है। यहाँ आपसे कुछ नहीं निर्भर करता, यह साइट के मालिक और उसके CDN का निर्णय है।
रिज़ॉल्वर पैरामीटर को काटता है। कॉर्पोरेट और प्रदाता DNS सर्वर सामान्यतः ech= के बिना HTTPS-रिकॉर्ड देने में सक्षम होते हैं। सार्वजनिक रिज़ॉल्वर (@1.1.1.1) से सीधे रिकॉर्ड का अनुरोध करके और सिस्टम के उत्तर की तुलना करके जांचें।
ब्राउज़र के फ़्लैग रीसेट हो गए हैं। फ़ायरफ़ॉक्स में network.dns.echconfig.enabled और network.dns.http3_echconfig.enabled about:config में उत्तर देते हैं — दोनों को true होना चाहिए।
बीच में एक निरीक्षण करने वाला गेटवे है। इस पर अगला खंड है।

कैसे ECH को तोड़ते हैं: दो अलग-अलग योजनाएँ

कॉर्पोरेट फ़ायरवॉल: चुपचाप गिराना

नेटवर्क उपकरण के विक्रेताओं ने ECH के खिलाफ तैयार नुस्खे जारी किए हैं — वे ट्रैफ़िक की दृश्यता खोने के लिए तैयार नहीं हैं। उदाहरण के लिए, सिस्को, अक्टूबर 2025 के VDB 416 एप्लिकेशन बेस से "ECH सर्वर" को एक अलग एप्लिकेशन के रूप में परिभाषित करता है और दो दृष्टिकोण प्रदान करता है: प्रमाणपत्र के पुनर्निर्माण के साथ कनेक्शन को इंटरसेप्ट करना और ClientHello से encrypted_client_hello एक्सटेंशन को काटना, या सरलता से कार्य करना — DNS स्तर पर: ECH-डोमेन के लिए HTTPS-रिकॉर्ड को ब्लॉक करना, DoH/DoT/DoQ को काटना, कैनरी डोमेन use-application-dns.net को ब्लॉक करना और DNS को केवल कॉर्पोरेट सर्वरों पर अनुमति देना।

पहली योजना की चाल यह है कि यह अवरोधन के रूप में नहीं दिखती। सर्वर, ECH-एक्सटेंशन नहीं देखकर, सामान्य रूप से उत्तर देता है, ग्राहक ECH को "सुरक्षित रूप से बंद" मानता है और अब खुले SNI के साथ फिर से कनेक्ट होता है। साइट खुल गई, कोई त्रुटियाँ नहीं हैं — और डोमेन का नाम गेटवे के लॉग में चला गया।

देश स्तर: कनेक्शन बस मर जाता है

रूसी उदाहरण अपनी सटीकता के लिए उल्लेखनीय है। 5 नवंबर 2024 से, फ़िल्टरिंग केवल तभी सक्रिय होती है जब दो संकेत एक साथ मेल खाते हैं: SNI का मान cloudflare-ech.com और ECH-एक्सटेंशन की उपस्थिति। अलग-अलग, न तो एक और न ही दूसरा अवरोधन का कारण बनता है — ECH अन्य लपेटने वाले डोमेन (जैसे, परीक्षण defo.ie या tls-ech.dev) पर चलता है। इसे कनेक्शन को रीसेट करके नहीं, बल्कि चुपचाप पैकेटों को गिराकर लागू किया गया है: पृष्ठ लटकता है और टाइमआउट पर गिरता है। TCP-आधारित HTTP/2 और QUIC/HTTP-3 दोनों प्रभावित होते हैं। उस समय, रोसकोमनाडज़ोर ने सीधे कहा कि TLS ECH का उपयोग रूसी कानून का उल्लंघन करता है, और साइट के मालिकों को क्लाउडफ़्लेयर CDN से हटने की सिफारिश की — एक साथ हजारों पूरी तरह से कानूनी संसाधनों को फ़िल्टर में डाल दिया गया, जो सामान्य लपेट में शामिल थे।

फ़ायरफ़ॉक्स ऐसी स्थिति में लगभग एक मिनट बाद ECH के बिना फिर से प्रयास करता है — यानी अंततः खुला SNI देता है, जिसे सुरक्षा के विचारों के कारण विनिर्देश करने की सिफारिश नहीं की जाती है। यदि आप देखते हैं कि "साइट एक मिनट में लोड होती है, फिर खुलती है" — तो यह लगभग निश्चित रूप से यही है।

जब ECH पर्याप्त नहीं है और इसके बजाय क्या स्थापित करें

आइए कार्यों को ईमानदारी से विभाजित करें।

घर के इंटरनेट पर प्रदाता से गोपनीयता। ECH + DoH — एक अच्छा और मुफ्त सुधार। यह वहाँ काम करता है जहाँ इसे नहीं काटा जाता है।
फ़िल्टरिंग को बायपास करना। ECH इसके लिए डिज़ाइन नहीं किया गया था, और प्रथा ने इसे प्रमाणित किया: जैसे ही यह फ़िल्टरों में बाधा डालने लगा, इसे पहचानने और पूरी तरह से दबाने के लिए सीखा गया। इस पर एक पहुंच के उपकरण के रूप में भरोसा नहीं किया जा सकता।
पार्सिंग, मल्टी-एकाउंटिंग, स्वचालन। ECH कुछ नहीं देता: लक्षित साइट आपके IP, आपके JA4 और आपके अनुरोधों के इतिहास को देखती है। केवल IP स्रोत और फ़िंगरप्रिंट की गुणवत्ता महत्वपूर्ण होती है।

उन सभी मामलों में जहाँ ECH काम नहीं करता, एक अधिक मोटे लेकिन विश्वसनीय परत काम करता है: TLS-हैंडशेक को देखी जाने वाली नेटवर्क से बाहर ले जाना. जब ट्रैफ़िक प्रॉक्सी के माध्यम से जाता है, तो आपके चैनल पर पर्यवेक्षक केवल प्रॉक्सी-नोड के साथ कनेक्शन को देखता है — इसमें लक्षित साइट का कोई SNI बिल्कुल नहीं है, चाहे डोमेन ECH का समर्थन करता हो या नहीं। दैनिक पहुंच और IP की प्रतिष्ठा के प्रति संवेदनशील सेवाओं के साथ काम करने के लिए आवासीय प्रॉक्सी उपयुक्त हैं; मोबाइल ऐप्स और प्लेटफ़ॉर्म के लिए, जो विशेष रूप से कनेक्शन के प्रकार के प्रति संवेदनशील हैं — मोबाइल.

और DNS के बारे में मत भूलिए: ब्राउज़र में प्रॉक्सी यह सुनिश्चित नहीं करता है कि नाम इसके माध्यम से हल हो रहे हैं। DNS लीक ठीक वही देता है जो आप छिपाने की कोशिश कर रहे थे — इसे कैसे जांचें, हम DNS लीक पर प्रॉक्सी की जांच के बारे में एक अलग निर्देश में समझाते हैं। यदि सवाल वास्तव में चैनल पर ट्रैफ़िक के गहरे विश्लेषण का है, तो ECH पर नहीं, बल्कि परिवहन पर ध्यान देना चाहिए।

संक्षिप्त चेकलिस्ट

crypto.cloudflare.com/cdn-cgi/trace खोलें और sni= पंक्ति को देखें।
यदि plaintext है — ब्राउज़र में DoH चालू करें और फिर से जांचें।
यदि मदद नहीं मिली — डोमेन पर कुंजी की उपस्थिति की जांच करें: dig +short TYPE65 डोमेन @1.1.1.1, FE0D की तलाश करें।
कुंजी है, लेकिन ECH लागू नहीं होता — सार्वजनिक और सिस्टम रिज़ॉल्वर के उत्तर की तुलना करें: संभावना है कि पैरामीटर यात्रा के दौरान काटे जा रहे हैं।
कनेक्शन एक मिनट तक लटकता है और खुलता है — ECH नेटवर्क स्तर पर दबाया जा रहा है; ECH यहाँ मदद नहीं करेगा, एक अन्य परिवहन की आवश्यकता है।

निष्कर्ष

ECH — यह TLS में गोपनीयता का सावधानीपूर्वक बंद किया गया अंतिम छिद्र है, न कि पहुंच का साधन और न ही स्वचालन के लिए उपकरण। यह एन्क्रिप्टेड DNS पर निर्भर करता है, बिना किसी त्रुटि के बीच में बंद हो जाता है और जहाँ यह बाधा डालना शुरू करता है, वहाँ पूरी तरह से दबा दिया जाता है। इसकी जांच करना उचित है — ऊपर की दो कमांड एक मिनट लेती हैं। लेकिन इसे अवरोधन या एंटी-बॉट सिस्टम से सुरक्षा के लिए आधार बनाना बेकार है: ये कार्य उस स्तर पर हल होते हैं, जहाँ सर्वर दूसरी तरफ किसका IP और किसका TLS फ़िंगरप्रिंट देखता है।