eMudhra के CA में सेंध दिखाती है कि डोमेन सुरक्षा को HTTPS से अधिक चाहिए

कोई वेबसाइट किसी प्रतिरूपण करने वाले व्यक्ति के साथ बने कनेक्शन को भी एन्क्रिप्ट कर सकती है। केवल एन्क्रिप्शन से दूसरे छोर को नियंत्रित करने वाले की पहचान नहीं होती।

eMudhra की घटना ने डोमेन मालिकों, संस्थापकों और Web3 टीमों के लिए यह अंतर समझना तत्काल आवश्यक बना दिया है। 20 अक्टूबर 2026 को Google और Mozilla ने मध्यवर्ती प्रमाणपत्र प्राधिकरणों की कुंजियों में सेंध के बाद आपात उपायों की घोषणा की। कमजोर कुंजी निर्माण ने वेबसाइट के जाली प्रमाणपत्र बनाने का रास्ता खोल दिया। उन कुंजियों पर अभी भी भरोसा करने वाले क्लाइंट पहचान के दुरुपयोग के जोखिम में थे। Google ने खामी और अवरोधन की कार्रवाई समझाई है।

स्थिति की जाँच 22 अक्टूबर 2026 को हुई। जाँच जारी है। कुंजियों में सेंध की पुष्टि यह सिद्ध नहीं करती कि हमलावरों ने ग्राहकों का डेटा यातायात बीच में पकड़ा था।

घटना ने अलग-अलग वेबसाइटों से ऊपर की हस्ताक्षर क्षमता का जोखिम उजागर किया

प्रमाणपत्र प्राधिकरण, यानी CA, डिजिटल प्रमाणपत्र जारी करता है जो पहचानों को सार्वजनिक कुंजियों से जोड़ते हैं। HTTPS में प्रमाणपत्र उन डोमेन नामों को बताता है जिनके लिए सर्वर अपनी पहचान प्रमाणित कर सकता है। CA प्रमाणपत्र पर हस्ताक्षर करने से पहले लागू पहचान आवश्यकताओं की जाँच करता है। ब्राउज़र प्रमाणपत्र शृंखला और उससे संबंधित निजी कुंजी रखने के सर्वर के प्रमाण की जाँच करता है। RFC 5280 प्रमाणपत्र मॉडल का वर्णन करता है।

मूल CA एक विश्वास आधार प्रदान करता है। मध्यवर्ती CA मूल CA के नीचे प्रत्यायोजित हस्ताक्षर अधिकार रखता है। वेबसाइट प्रमाणपत्र आम तौर पर मध्यवर्ती CA के नीचे होते हैं। वेबसाइट की कुंजी में सेंध उस प्रमाणपत्र की पहचानों को खतरे में डालती है। मध्यवर्ती कुंजी में सेंध कई असंबंधित डोमेन को खतरे में डाल सकती है। जोखिम प्रमाणपत्र की सीमाओं और क्लाइंट की जाँच पर निर्भर करता है।

Mozilla के घटना अभिलेख में आठ प्रभावित मध्यवर्ती प्रमाणपत्र हैं: छह TLS के लिए और दो कोड हस्ताक्षर के लिए। Mozilla ने कमजोर निजी कुंजियाँ स्वतंत्र रूप से पुनर्प्राप्त कीं। eMudhra ने 18 अक्टूबर को प्रमाणपत्रों को निरस्त चिह्नित किया। ये तथ्य कुंजी निर्माण की विफलता बताते हैं। ये तथ्य यह प्रमाण नहीं हैं कि किसी ने हर ग्राहक की निजी कुंजी चुरा ली।

अपने 21 अक्टूबर के वक्तव्य में eMudhra ने कमजोर कुंजियों का कारण 30 अप्रैल 2025 के कुंजी निर्माण समारोह के दौरान रैप/अनरैप चरण को बताया। eMudhra ने कहा कि प्रभावित मध्यवर्ती प्राधिकरणों ने कोई अंतिम इकाई प्रमाणपत्र जारी नहीं किया था। कंपनी ने खुलासे से पहले दुरुपयोग का कोई प्रमाण नहीं मिलने की बात भी कही। कंपनी ने यह भी कहा कि सटीक मूल कारण की जाँच अधूरी थी। ये वक्तव्य eMudhra के निष्कर्ष हैं। ये पूरे पुराने डेटा यातायात के बारे में स्वतंत्र गारंटी नहीं हैं।

ब्राउज़र की सुरक्षा ने वास्तविक जोखिम का दायरा बदल दिया

Google के अनुसार Chrome ने 17 अक्टूबर को CRLSet अपडेट से प्रभावित कुंजियों को रोक दिया। Google के अनुसार अवरोधन से पहले प्रभावित छह TLS मध्यवर्ती प्राधिकरणों के अंतर्गत कोई TLS प्रमाणपत्र CT में नहीं दिखा। इसलिए संबंधित CT आवश्यकता लागू करने वाले क्लाइंट पर उन मध्यवर्ती प्राधिकरणों के जाली प्रमाणपत्र काम नहीं कर सकते थे। Google के परामर्श में Chrome भी ऐसे क्लाइंट में शामिल है।

Mozilla ने उसी शाम OneCRL अवरोध वितरित किया। Mozilla ने उन विन्यासों के लिए Firefox अपडेट भी जारी किए जिन्हें OneCRL की सुरक्षा शायद न मिले। ब्राउज़र अपडेट यह साबित नहीं करता कि उसी उपकरण के हर अनुप्रयोग को समान सुरक्षा मिली है। Cloudflare स्पष्ट चेतावनी देता है कि अलग अनुप्रयोग अलग प्रमाणपत्र सत्यापक इस्तेमाल कर सकते हैं।

Google के 20 अक्टूबर के परामर्श के अनुसार Chrome Root Store का उपयोग करने वाले क्लाइंट से emSign ECC Root CA - G3 को 27 अक्टूबर 2026, PDT को हटाना निर्धारित है। Google प्रभावित वेबसाइट संचालकों को प्रमाणपत्र दूसरे विश्वसनीय पदानुक्रम में स्थानांतरित करने का निर्देश देता है। संचालकों को तत्काल सुरक्षा अवरोध और बाद में मूल CA पर भरोसा हटने से सेवा बंद होने के बीच अंतर करना होगा।

मध्यस्थ हमलावर को डेटा यातायात तक पहुँच और स्वीकृत पहचान दोनों चाहिए

मध्यस्थ हमला, यानी MITM, संचार करने वाले पक्षों के बीच हमलावर को रखता है। आगे एक काल्पनिक हमला है। यह eMudhra के किसी देखे गए दुरुपयोग का वर्णन नहीं है:

1. हमलावर दुर्भावनापूर्ण DNS उत्तरों या नेटवर्क अवरोधन के किसी दूसरे तरीके से आगंतुक को दूसरी दिशा में भेजता है।
2. हमलावर इच्छित डोमेन का जाली प्रमाणपत्र प्रस्तुत करता है।
3. असुरक्षित क्लाइंट प्रमाणपत्र स्वीकार करके हमलावर से TLS कनेक्शन बनाता है।
4. हमलावर असली सेवा तक डेटा यातायात पहुँचा सकता है और साथ में अनुप्रयोग डेटा पढ़ या बदल सकता है।

CA की कुंजी रखने से डेटा यातायात अपने आप दूसरी दिशा में नहीं जाता। केवल प्रमाणपत्र से पहले रिकॉर्ड किए गए सभी सत्रों का एन्क्रिप्शन भी नहीं खुलता। TLS 1.3 की अग्र गोपनीयता, निर्धारित धारणाओं के अंतर्गत, पुराने सत्रों को दीर्घकालिक प्रमाणीकरण कुंजियों में बाद की सेंध से बचाती है। RFC 8446 यह अंतर समझाता है।

हमारा Fox-IT का अध्ययन समान परिणाम का दूसरा रास्ता जाँचता है: पंजीयक में सेंध ने धोखे से प्रमाणपत्र हासिल करना संभव बनाया। हमारा MyEtherWallet का अध्ययन मार्ग-निर्धारण और DNS में हेरफेर की जाँच करता है। डोमेन सुरक्षा को डेटा यातायात की दिशा और दूसरे छोर के प्रमाणीकरण, दोनों को संभालना चाहिए।

DNSSEC, CA की कुंजियाँ ठीक किए बिना DNS उत्तरों की प्रामाणिकता जाँचता है

DNSSEC (डोमेन नेम सिस्टम सुरक्षा एक्सटेंशन) DNS डेटा में डिजिटल हस्ताक्षर जोड़ता है। सत्यापन करने वाला रिज़ॉल्वर विश्वास शृंखला से उन हस्ताक्षरों की जाँच करता है। सही हस्ताक्षरित ज़ोन और अखंड सत्यापन शृंखला होने पर हमलावर पते का जाली उत्तर बिना पकड़े नहीं डाल सकता। RFC 4033 सुरक्षा और सीमाएँ परिभाषित करता है।

क्लाइंट को स्थानीय सत्यापन करना होगा। अन्यथा क्लाइंट को सत्यापन करने वाले रिज़ॉल्वर और उस रिज़ॉल्वर तक प्रमाणित कनेक्शन, दोनों पर भरोसा करना होगा। RFC 4033 अंतिम चरण की यह आवश्यकता समझाता है।

इन शर्तों के साथ DNSSEC काल्पनिक हमले के जाली DNS वाले चरण को रोक सकता है। DNSSEC मध्यवर्ती CA को निरस्त नहीं करता, HTTPS प्रमाणपत्र सत्यापित नहीं करता और वेब डेटा यातायात एन्क्रिप्ट नहीं करता। दूसरे रास्ते से डेटा यातायात पकड़ने वाला हमलावर कमजोर क्लाइंट को अभी भी जाली प्रमाणपत्र दे सकता है।

केवल हस्ताक्षर करने से पंजीयक का खाता या प्राधिकृत DNS का नियंत्रण पटल भी सुरक्षित नहीं होता। अधिकृत DNS बदलावों पर नियंत्रण पाने वाला हमलावर हानिकारक रिकॉर्ड प्रकाशित कर सकता है, जिन पर प्रदाता हस्ताक्षर कर देता है। DNSSEC सत्यापन के साथ संचालकों को खाता सुरक्षा, बदलावों की निगरानी और मूल ज़ोन में सही DS रिकॉर्ड चाहिए।

क्लाइंट द्वारा संबंध लागू करने पर DANE सेवा की कुंजी को हस्ताक्षरित DNS से जोड़ सकता है

DANE TLSA रिकॉर्ड के माध्यम से DNSSEC को TLS प्रमाणीकरण से जोड़ता है। डोमेन संचालक अपेक्षित प्रमाणपत्र, कुंजी या विश्वास आधार को हस्ताक्षरित DNS में प्रकाशित करता है। DANE का समर्थन करने वाला क्लाइंट DNSSEC सत्यापित करके TLSA संबंध लागू करता है। RFC 6698 यह संबंध निर्दिष्ट करता है।

उदाहरण के लिए, DANE-EE का उपयोग सेवा को सीधे उसकी सार्वजनिक कुंजी से जोड़ सकता है। असंबंधित CA कुंजी से बनाया गया जाली प्रमाणपत्र उस संबंध की जाँच में विफल होगा। इस लाभ के लिए सुरक्षित DNSSEC सत्यापन, सही TLSA डेटा और क्लाइंट द्वारा वास्तविक प्रवर्तन चाहिए। कुंजी बदलने के लिए TLSA अपडेट का समन्वय भी चाहिए। RFC 7671 संचालन संबंधी मार्गदर्शन देता है।

TLSA रिकॉर्ड प्रकाशित करने से सामान्य ब्राउज़र आगंतुकों को अपने आप सुरक्षा नहीं मिलती। Firefox का DANE कार्यान्वयन अनुरोध अभी भी अस्वीकृत है। संचालकों को ठीक उसी क्लाइंट में समर्थन जाँचना होगा। DANE का SMTP परिवहन सुरक्षा के लिए मानकीकृत उपयोग मौजूद है।

CAA और CT प्रमाणपत्रों पर अलग नियंत्रण देते हैं

CAA अधिकृत जारीकर्ताओं को DNS में प्रकाशित करता है। RFC 8659 जारी करने की अनुमति और क्लाइंट के प्रमाणपत्र सत्यापन में अंतर करता है। चोरी हुई या पुनर्प्राप्त की जा सकने वाली हस्ताक्षर कुंजी जालसाज को CAA जाँच अनदेखी करने देती है।

प्रमाणपत्र पारदर्शिता, यानी CT, प्रमाणपत्र जारी करने को सार्वजनिक लेखापरीक्षा के लिए उपलब्ध बनाती है। निगरानी अप्रत्याशित प्रमाणपत्रों का पता लगा सकती है। क्लाइंट का प्रवर्तन अपेक्षित अभिलेखन प्रमाण के बिना प्रमाणपत्र अस्वीकार कर सकता है। RFC 9162 अभिलेखन की व्यवस्था बताता है। Google के पहले बताए निष्कर्ष समझाते हैं कि CA की घटना में प्रवर्तन क्यों मायने रखता है।

डोमेन संचालकों को अभी क्लाइंट का भरोसा और प्रमाणपत्रों पर निर्भरताएँ जाँचनी चाहिए

• ब्राउज़र, संचालन तंत्र, रनटाइम और CA पैकेज के वर्तमान सुरक्षा अपडेट स्थापित करें।
• वेबसाइटों, API, मोबाइल अनुप्रयोगों, कंटेनरों और TLS निरीक्षण गेटवे की प्रमाणपत्र शृंखलाओं की सूची बनाएँ।
• प्रभावित मध्यवर्ती प्राधिकरणों और मूल CA हटाने पर विक्रेता के निर्देश मानें। वैकल्पिक प्रमाणपत्र पथ भी जाँचें।
• संबंधित क्लाइंट की समयसीमा से पहले अविश्वसनीय पदानुक्रम से जुड़ने वाले प्रमाणपत्र बदलें।
• सुधार के बाद हर अनुप्रयोग का वास्तविक TLS सत्यापक जाँचें।
• प्रमाणपत्र सत्यापन चालू रखें और प्रमाणपत्र त्रुटि पर रुकें।
• सही DS प्रत्यायोजन के साथ DNSSEC चालू करें और सत्यापन करने वाला नाम समाधान इस्तेमाल करें।
• CAA से अधिकृत जारीकर्ता सीमित करें, CT की निगरानी करें और पंजीयक तथा DNS खाते सुरक्षित करें।

VPN डेटा यातायात का रास्ता बदल सकता है। VPN क्लाइंट के प्रमाणपत्र पर भरोसे के निर्णय ठीक नहीं करता। HSTS, HTTPS अनिवार्य करता है, लेकिन स्वीकृत जाली HTTPS पहचान फिर भी इस सुरक्षा को हरा देती है। RFC 6797 HSTS की सुरक्षा सीमाएँ बताता है।

Namefi के पाठकों के लिए डोमेन स्वामित्व, DNS प्रशासन, TLS प्रमाणीकरण और वॉलेट प्राधिकरण को अलग नियंत्रण चाहिए। डोमेन का टोकनीकरण ब्राउज़र के CA पर भरोसे को अपने आप नहीं बदलता और DNSSEC चालू नहीं करता। हमारी टोकनीकृत डोमेन की DNS मार्गदर्शिका संचालन संबंध समझाती है। हमारा Curve Finance का अध्ययन दिखाता है कि Web3 टीम को अपना इंटरफ़ेस देने वाला डोमेन क्यों सुरक्षित करना चाहिए।

ये प्राथमिक स्रोत घटना और उसके प्रतिरक्षा उपाय दर्ज करते हैं

नीचे के सभी स्रोत 22 अक्टूबर 2026 को प्राप्त किए गए। जाँच आगे बढ़ने पर घटना के वक्तव्य बदल सकते हैं।

• Google: Chrome और Android की प्रतिक्रिया, 20 अक्टूबर 2026। एन्ट्रॉपी, CT, अवरोधन और मूल CA हटाने के खंड।
• Mozilla: Firefox की प्रतिक्रिया, 20 अक्टूबर 2026। OneCRL वितरण और अतिरिक्त अपडेट।
• Mozilla समस्या 2083449, विवरण और टिप्पणी 1। प्रमाणपत्रों का दायरा, स्वतंत्र कुंजी पुनर्प्राप्ति और निरस्तीकरण।
• eMudhra का घटना वक्तव्य, अपडेट 2–4। कंपनी के निष्कर्ष और ग्राहकों के स्थानांतरण विकल्प।
• Cloudflare का घटना मार्गदर्शन, अनुप्रयोग के अनुसार सत्यापन निर्देश।
• RFC 5280, प्रमाणपत्र और विश्वास पथ मॉडल।
• RFC 8446, TLS 1.3 की अग्र गोपनीयता।
• RFC 4033, DNSSEC की सेवाएँ, सीमाएँ और सत्यापन।
• RFC 6698 और RFC 7671, DANE संबंध और संचालन।
• Mozilla समस्या 1994924, Firefox में DANE कार्यान्वयन की स्थिति।
• RFC 7672, SMTP के लिए DANE।
• RFC 8659, CAA प्राधिकरण और सत्यापन का अंतर।
• RFC 9162, CT अभिलेखन और निगरानी।
• RFC 6797, HSTS के सुरक्षा विचार।