HTTPS ट्राफिकमा डोमेन लुकाउन Firefox र Cloudflare ले ECH समर्थन सक्षम पार्छ

मोजिलाले घोषणा गरेको छ कि यसले फायरफक्स स्थिर प्रयोगकर्ताहरूको लागि ECH (इन्क्रिप्टेड क्लाइन्ट हेलो) संयन्त्रको लागि समर्थन सक्षम गर्दैछ। यो ESNI (इन्क्रिप्टेड सर्भर नाम संकेत) प्रविधिको निरन्तरता हो र अनुरोध गरिएको डोमेन नाम जस्ता TLS सत्र प्यारामिटरहरूको बारेमा जानकारी इन्क्रिप्ट गर्न डिजाइन गरिएको हो। सुरुमा, ECH सँग काम गर्ने कोड फायरफक्स 85 को रिलीजमा थपिएको थियो, तर पूर्वनिर्धारित रूपमा असक्षम पारिएको थियो। क्रोममा, क्रोम 115 को रिलीजबाट सुरु गर्दै, ECH समर्थन बिस्तारै समावेश गरिएको छ।

जडान हुनुको साथै सर्भर अनुरोध गरिएको डोमेन जानकारी DNS मार्फत चुहावट हुन्छ। पूर्ण सुरक्षाको लागि, ECH को अतिरिक्त, तपाईंले DNS ट्राफिक इन्क्रिप्ट गर्न HTTPS मा DNS वा TLS मा DNS प्रयोग गर्नुपर्छ। सेटिङहरूमा HTTPS मा DNS सक्षम नगरी Firefox ले ECH प्रयोग गर्दैन। तपाईं यस पृष्ठमा आफ्नो ब्राउजरमा ECH समर्थन जाँच गर्न सक्नुहुन्छ।

फायरफक्सले पूर्वनिर्धारित रूपमा ECH समर्थन सक्षम पार्ने एउटा कारक भनेको क्लाउडफ्लेयरले केही दिन अघि यसको सामग्री डेलिभरी नेटवर्कमा ECH समर्थन सक्षम गर्नु थियो। व्यावहारिक रूपमा, ECH प्रयोग गर्दा अनुरोध गरिएको होस्टहरूको बारेमा डेटा विश्लेषणबाट लुकाइएको हुनाले, क्लाउडफ्लेयरको CDN प्रयोग गरेर अनावश्यक साइटहरूलाई फिल्टर र ब्लक गर्न अब सम्पूर्ण क्लाउडफ्लेयर नेटवर्क ब्लक गर्न, ECH मार्फत सबै अनुरोधहरू ब्लक गर्न, वा प्रयोगकर्ताको प्रणालीमा नक्कली रूट प्रमाणपत्रहरू प्रयोग गरेर HTTPS अवरोध व्यवस्थित गर्न आवश्यक पर्नेछ।

सुरुमा, SNI TLS एक्सटेन्सन धेरै HTTPS साइटहरूको एउटै IP ठेगानामा काम व्यवस्थित गर्न प्रयोग गरिएको थियो, जसमा अनुरोध गरिएको होस्टको नाम एन्क्रिप्टेड सञ्चार च्यानल स्थापना गर्नु अघि प्रसारित ClientHello सन्देशमा निर्दिष्ट गरिएको थियो। यो सुविधाले जडान प्रशोधनको प्रारम्भिक चरणमा भर्चुअल होस्टहरू बीच अनुरोधहरू वितरण गर्न सम्भव बनायो, तर इन्टरनेट प्रदायकलाई HTTPS ट्राफिकलाई छनौट रूपमा फिल्टर गर्न र प्रयोगकर्ताले कुन साइटहरू खोल्छन् भनेर विश्लेषण गर्न अनुमति दियो, जसले HTTPS प्रयोग गर्दा पूर्ण गोपनीयता प्राप्त गर्न अनुमति दिँदैनथ्यो।

यो समस्या समाधान गर्न र अनुरोध गरिएको साइटको बारेमा जानकारी चुहावट रोक्नको लागि, पछि ESNI विस्तार प्रस्ताव गरिएको थियो, होस्ट नामको साथ डेटाको इन्क्रिप्शन लागू गर्दै। ESNI को कार्यान्वयनको क्रममा, यो पत्ता लाग्यो कि प्रस्तावित संयन्त्रले होस्ट डेटा चुहावटका सबै सम्भावित स्रोतहरूलाई समेट्दैन र HTTPS सत्रहरूको पूर्ण गोपनीयता सुनिश्चित गर्न यसको प्रयोग अपर्याप्त छ। विशेष गरी, पहिले स्थापित सत्र पुन: सुरु गर्दा, PSK (पूर्व-साझेदारी कुञ्जी) TLS विस्तारको प्यारामिटरहरू बीच स्पष्ट पाठमा डोमेन नाम निर्दिष्ट गरिन्थ्यो। थप रूपमा, ESNI कार्यान्वयन गर्ने प्रयासहरूले ESNI को व्यापक वितरणलाई रोक्ने अनुकूलता र स्केलिंग समस्याहरू प्रकट गरे।

ESNI का पहिचान गरिएका कमजोरीहरूलाई ध्यानमा राख्दै, एउटा नयाँ विश्वव्यापी संयन्त्र ECH विकास गरिएको थियो, जसले कुनै पनि TLS एक्सटेन्सनहरूको प्यारामिटरहरूको इन्क्रिप्शनलाई अनुमति दिन्छ। प्राविधिक रूपमा, ECH र ESNI बीचको मुख्य भिन्नता भनेको व्यक्तिगत क्षेत्रहरूको सट्टा, सम्पूर्ण ClientHello सन्देश एकैचोटि इन्क्रिप्ट गरिएको छ। ECH मा ClientHello लाई दुई अलग सन्देशहरूमा विभाजन गर्ने समावेश छ - एक एन्क्रिप्टेड ClientHelloInner (SNI इनर) सन्देश र एक अनइन्क्रिप्टेड आधार ClientHelloOuter (SNI आउटर) सन्देश। अनइन्क्रिप्टेड SNI आउटरले गैर-संवेदनशील डेटा प्रसारण गर्दछ, जस्तै TLS संस्करण र प्रयोग गरिएका साइफरहरूको सूची, साथै अनुरोध गरिएको डोमेनको वास्तविक नामसँग ओभरल्याप नहुने साझा डोमेन नाम। उदाहरणका लागि, सबै Cloudflare क्लाइन्टहरूको लागि, अनइन्क्रिप्टेड SNI आउटरले सामान्य होस्ट "cloudflare-ech.com" निर्दिष्ट गर्दछ, र अनुरोध गरिएको होस्टको वास्तविक नाम इन्क्रिप्टेड SNI इनरमा प्रसारित हुन्छ र विश्लेषणको लागि उपलब्ध हुँदैन।

ECH ले फरक इन्क्रिप्शन कुञ्जी वितरण योजना पनि प्रयोग गर्दछ: सार्वजनिक कुञ्जी जानकारी TXT रेकर्डहरूको सट्टा HTTPSSVC DNS रेकर्डहरूमा प्रसारित हुन्छ। HPKE (हाइब्रिड पब्लिक कुञ्जी इन्क्रिप्शन) संयन्त्रमा आधारित प्रमाणित एन्ड-टु-एन्ड इन्क्रिप्शन कुञ्जी प्राप्त गर्न र इन्क्रिप्ट गर्न प्रयोग गरिन्छ। ECH ले सर्भरबाट सुरक्षित कुञ्जी पुन: प्रसारणलाई पनि समर्थन गर्दछ, जुन कुञ्जी घुमाउने घटनामा प्रयोग गर्न सकिन्छ। सर्भर र DNS क्यासबाट पुराना कुञ्जीहरू पुन: प्राप्त गर्ने समस्याहरू समाधान गर्न।

स्रोत: opennet.ru