इंटरमीडिएट CA समझौता: जब ट्रस्ट चेन टूटती है

यह बात उल्टी लग सकती है: सबसे बुरी certificate authority घटनाएँ वे नहीं होतीं जहाँ हमलावर सेंध लगाता है। हाल में eMudhra के इंटरमीडिएट CA समझौते से यही साबित होता है। आठ इंटरमीडिएट CA keys सिर्फ़ सर्टिफिकेट्स में मौजूद डेटा से निकाली जा सकती थीं, किसी घुसपैठ की ज़रूरत नहीं पड़ी, क्योंकि CA की अपनी key generation प्रक्रिया ने इतनी कमज़ोर private keys बनाईं कि उनमें से एक असल में संख्या 4 थी। किसी ने वे keys चुराई नहीं थीं। वे पैदाइश से ही compromised थीं। और यह किसी भी breach से ज़्यादा डरावनी failure mode है, क्योंकि इसे credentials बदलकर या कोई छेद पैच करके ठीक नहीं किया जा सकता। भरोसे की नींव ही पहले दिन से खराब थी।

अगर आप ब्राउज़र के बाहर TLS connections बनाने वाली कोई भी चीज़ चलाते हैं, और आप चलाते ही हैं, तो इस पर ध्यान देना ज़रूरी है। ब्राउज़र कुछ ही दिनों में सुरक्षित कर दिए गए। बाकी इकोसिस्टम, यानी आपके cron jobs में चलने वाली curl कॉल्स, certifi को pin करने वाली Python services, और बने-बनाए root stores वाली Go binaries, अभी भी पकड़ने की कोशिश में हैं। आइए समझते हैं कि असल में क्या हुआ, इंटरमीडिएट समझौता leaf समझौते से मूल रूप से बुरा क्यों है, और असमान remediation हमें आज के इंटरनेट पर revocation की हालत के बारे में क्या बताता है।

eMudhra के साथ असल में क्या गड़बड़ हुई

Mozilla के incident tracker में CA के अपने प्रारंभिक आकलन के अनुसार, कहानी लगभग दर्दनाक रूप से साधारण है। एक key generation ceremony script, यानी वह नियंत्रित और audited प्रक्रिया जिससे CA अपनी सबसे संवेदनशील keys बनाता है, को एक स्वीकृत deviation के साथ बदला गया था ताकि export के लिए key wrap/unwrap procedure को परखा जा सके। उस बदले हुए code में एक खामी ने HSM पर ECC keys का एक दूसरा सेट बना दिया, और वे keys कमज़ोर थीं। “entropy कम” वाली कमज़ोरी नहीं। ऐसी कमज़ोरी जिसे सार्वजनिक certificate से ही आसानी से निकाला जा सकता था।

सोचिए इसका मतलब क्या है। ECC private key को एक random 256-bit संख्या होना चाहिए। पूरी योजना की सुरक्षा discrete logarithm problem पर टिकी है: public key दिए जाने पर private scalar निकालना कम्प्यूटेशनल रूप से असंभव होना चाहिए। लेकिन अगर आपका “random” scalar सिर्फ़ एक byte का है, तो public key बस generator point को उस byte से गुणा करने का नतीजा होती है, और कोई भी लैपटॉप पर माइक्रोसेकंड में सभी 256 संभावनाएँ brute-force कर सकता है। आठ में से एक key, कहा जाता है, पूर्णांक 4 थी। यह पारंपरिक अर्थ में समझौता नहीं है; यह ऐसा certificate है जो कभी असल में सुरक्षित था ही नहीं, और वह उस root के तहत जारी हुआ था जिस पर Mozilla, Microsoft, Apple और Chrome भरोसा करते हैं।

जिस researcher ने इसकी रिपोर्ट की, जिसकी पहचान Wayne के रूप में बताई गई, उसने आठों private keys से एक message sign करके signatures root programs को भेजे और इस तरह key के अपने पास होने का सबूत दिया। कोई भी दो OpenSSL commands से इस proof को verify कर सकता था: हर इंटरमीडिएट certificate से public key निकालें, फिर check करें कि message पर signature उसके against verify होता है या नहीं। क्रिप्टोग्राफ़िक key possession proof की यही खूबसूरत और डरावनी बात है: कोई अस्पष्टता नहीं, “हम security को गंभीरता से लेते हैं” वाला PR धुंआ नहीं। गणित या तो मिलता है या नहीं मिलता। यहाँ यह मिल गया।

इंटरमीडिएट CA समझौता leaf से ज़्यादा बुरा क्यों है

जब किसी leaf certificate की private key लीक होती है, मान लीजिए आपकी api.example.com की key किसी public GitHub repo में पहुँच जाती है, तो नुकसान का दायरा एक hostname भर होता है, wildcard हो तो शायद कुछ और। आप certificate revoke करते हैं, नया जारी करते हैं और आगे बढ़ जाते हैं। परेशानी ज़रूर है, पर अस्तित्व का संकट नहीं।

इंटरमीडिएट CA की key बिल्कुल अलग जानवर है। Web PKI हस्ताक्षरों की एक चेन की तरह काम करता है: एक root CA (जो offline रखा जाता है और परमाणु सामग्री की तरह सुरक्षित रहता है) intermediates पर हस्ताक्षर करता है, और intermediates उन leaf certificates पर हस्ताक्षर करते हैं जिन्हें servers असल में पेश करते हैं। जिसके पास किसी इंटरमीडिएट की private key है, वह सभी क्रिप्टोग्राफ़िक उद्देश्यों के लिए वही CA है। वह google.com के लिए, आपके bank के लिए, आपके internal SSO domain के लिए, valid certificate बना सकता है, और चेन पर भरोसा करने वाला हर client बिना सवाल किए उसे स्वीकार कर लेगा। कोई rate limit नहीं, कोई केंद्रीय प्राधिकरण नहीं जिसे फोन किया जा सके, और धोखाधड़ी से बने पर valid हस्ताक्षर को असली से अलग पहचानने का कोई तरीका नहीं।

eMudhra की घटना में यह आठ इंटरमीडिएट्स तक फैला हुआ था, जिनमें से कुछ Sectigo roots के through cross-signed थे, और ये चेन अरबों डिवाइसों में भेजे गए trust stores तक पहुँचती थीं। लगभग डेढ़ साल तक, जब से खराब certificates बने थे और खुलासा होने तक, जो भी client इन इंटरमीडिएट्स पर भरोसा करता था और Certificate Transparency लागू नहीं करता था, उसे कोई भी व्यक्ति impersonate कर सकता था, बशर्ते वह keys निकालने की ज़हमत उठाए। यही वह खिड़की है। हम नहीं जानते कि किसी ने इसका फायदा उठाया या नहीं, और किसी लकी CT log catch या देखे गए हमले के बिना शायद हम कभी न जान पाएँ।

इसीलिए root programs इंटरमीडिएट घटनाओं को उस गंभीरता से लेते हैं जो leaf घटनाओं को कभी नहीं मिलती। किसी इंटरमीडिएट पर से भरोसा हटाने का मतलब है कि उसके जारी किए हर certificate अमान्य हो जाते हैं, यानी हज़ारों वेबसाइटें एक साथ टूटती हैं। Symantec distrust का मामला, जो सालों तक चला, इसका सबसे प्रसिद्ध उदाहरण है कि जब किसी CA के operations को अविश्वसनीय माना जाता है तो पूरा remediation कितना दर्दनाक हो जाता है। सिस्टम काम करता है, पर वह सर्जरी की तरह नहीं, विच्छेदन की तरह काम करता है।

Certificate Transparency अनजाने में हीरो बनी

कहानी का वह हिस्सा जिस पर ज़्यादा ध्यान मिलना चाहिए: Chrome, Safari, Firefox और Edge शायद किसी समस्या के पता चलने से पहले ही सुरक्षित थे। revocation की वजह से नहीं, बल्कि Certificate Transparency की वजह से।

CT लागू करने वाले ब्राउज़र माँग करते हैं कि वे जो भी सार्वजनिक रूप से भरोसेमंद certificate स्वीकार करें, वह सार्वजनिक, केवल-जोड़ने-योग्य CT logs में दर्ज हो। समझौता हुए eMudhra इंटरमीडिएट्स की उस अवधि के लिए कोई CT log प्रविष्टि नहीं है, यानी उन keys से हमलावर द्वारा बनाया गया कोई भी leaf certificate CT लागू करने वाले clients द्वारा वैसे भी ठुकरा दिया जाता, क्योंकि वह बिना valid signed certificate timestamps के पहुँचता। धोखाधड़ी पर भरोसा किए जाने के लिए उसे प्रकाशित होना पड़ता, और प्रकाशित करते ही वह तुरंत उजागर हो जाती।

CT को बाद में गलत जारी किए गए certificates पकड़ने के लिए बनाया गया था, ताकि नकली certificates का पता लगाया जा सके। इस घटना में यह एक निवारक नियंत्रण की तरह काम किया: इसने समझौता हुई keys को ब्राउज़र आबादी के खिलाफ लगभग बेकार कर दिया, जो बड़े पैमाने पर interception के लिए सबसे कीमती लक्ष्य है। यह उस infrastructure के लिए सचमुच अच्छी खबर है जिसके बारे में ज़्यादातर engineers कभी सोचते ही नहीं।

लेकिन, और यहीं मैं अपने आशावाद की सीमाएँ स्वीकार करता हूँ, CT लागू करना मूलतः ब्राउज़र की सुविधा है। इंटरनेट पर TLS clients की बड़ी बहुमत SCTs जाँचती ही नहीं। आपकी curl कॉल नहीं जाँचती। आपकी Python requests कॉल नहीं जाँचती। किसी vendor cloud को फोन करने वाला IoT fleet नहीं जाँचता। इन सभी के लिए एकमात्र सुरक्षा यह थी कि revocation data समय पर trust store तक पहुँचे, और यहीं कहानी बदसूरत हो जाती है।

Revocation का अंतर: ब्राउज़र बनाम बाकी सब

ब्राउज़र vendors ने इसे अच्छी तरह संभाला, और एक दशक पहले बने infrastructure के लिए उन्हें श्रेय मिलना चाहिए। Mozilla दस साल से ज़्यादा समय से OneCRL भेज रहा है, एक push mechanism जो इंटरमीडिएट और root certificates पर से भरोसा हटाता है, और उसने Firefox उपयोगकर्ताओं के लिए इस घटना का समाधान घंटों के भीतर कर दिया, बिना किसी browser update की ज़रूरत के। Chrome का CRLSets और Apple के समकक्ष mechanisms ने अपने platforms पर कुछ ही दिनों में यही किया। CA ने इंटरमीडिएट्स revoke कर दिए। एक browser उपयोगकर्ता के नज़रिए से, यह घटना शुरू होने से पहले ही लगभग खत्म हो गई।

अब गैर-ब्राउज़र दुनिया पर नज़र डालिए। remediation की सूची किसी software supply chain inventory जैसी लगती है: Ubuntu, Debian, Fedora, Alpine, Arch, Gentoo के लिए updated ca-certificates packages; एक नया NSS release; एक नया curl CA bundle; Python के लिए certifi; Rust के लिए rustls-webpki और webpki-roots; Go point releases; तीन release lines में Electron patch versions; Composer का ca-bundle; और Elixir का castore। इनमें से हर एक अलग artifact है, अलग release cadence पर, और अलग update mechanism से consume होता है। कुछ तो disclosure के कई दिनों बाद तक लंबित थे।

और फिर वह श्रेणी है जो मुझे रात को जगाए रखती है: ऐसा software जो binary के अंदर अपना CA store खुद रखता है। पिछले साल बनी एक statically linked Go service अपनी roots compiled artifact में लेकर चलती है। उसे फिर से build और redeploy करना ही एकमात्र fix है, क्योंकि कोई system package नहीं है जिसे patch किया जा सके। इसे अपने registry की हर container image से गुणा कीजिए जिसमें बनी-बनाई /etc/ssl/certs layer है, हर desktop पर हर Electron app, हर connected device पर हर firmware image, और आपको समस्या का आकार दिख जाएगा। system trust store तो आसान हिस्सा है। हम पहले लिख चुके हैं कि embedded और OT devices security incidents को कई साल लंबी गाथाओं में कैसे बदल देते हैं; compromised CA ठीक वैसी ही घटना है जहाँ ऐसे devices कभी ठीक ही नहीं होते।

Trust Stores का वह लंबा सिलसिला जिसका कोई मालिक नहीं

इस घटना से एक खास मामला है जो अपना अलग पैराग्राफ़ डिज़र्व करता है क्योंकि यह बिल्कुल सटीक उदाहरण है: macOS। Apple के platform ने समझौता हुए इंटरमीडिएट्स को OS स्तर पर तुरंत block कर दिया। लेकिन बिल्ट-इन /usr/bin/curl /etc/ssl/cert.pem के against verify करता है, एक ऐसी फ़ाइल जो अपडेट नहीं हुई थी, और revocation की जाँच नहीं करता। तो आपके पास पूरी तरह patched Mac हो सकता है जहाँ Safari नकली certificate ठुकरा दे, और उसी मशीन की curl उसे खुशी-खुशी स्वीकार कर ले। एक मशीन, दो trust फैसले, उल्टे नतीजे।

यह बिखराव ही असली सबक है। हम अक्सर “Web PKI” की बात ऐसे करते हैं जैसे यह एक ही system हो। असल में यह बहुत अलग-अलग गुणों वाले दर्जनों systems हैं:

• ब्राउज़र: push-आधारित revocation (OneCRL, CRLSets), CT enforcement, auto-updates। Remediation घंटों से लेकर दिनों में मापा जाता है।
• OS trust stores: package-managed updates (ca-certificates, ca_root_nss)। Remediation distro की release cadence और इस पर निर्भर है कि मशीन कभी patch होती है या नहीं।
• भाषा इकोसिस्टम: certifi, webpki-roots, Go के embedded roots, Node का bundled Mozilla store। Remediation का मतलब है release काटना और हज़ारों projects में dependency bumps का इंतज़ार करना।
• Compiled artifacts और images: binaries, containers, firmware। Remediation का मतलब है rebuild और redeploy, जिसका व्यवहार में अर्थ है एक लंबी असुरक्षित पूँछ जो सालों तक खिंचती है।
• IoT और embedded: अक्सर कोई update path ही नहीं होता। व्यावहारिक रूप से स्थायी exposure।

ब्राउज़रों ने ठीक इसी स्थिति के लिए एक दशक से निवेश किया है। लगभग कोई और नहीं कर पाया। Mozilla की ओर से एक upstream टिप्पणी ने इसे सीधे शब्दों में कहा: ब्राउज़र इकोसिस्टम के बाहर revocation में बहुत कम या लगभग कोई निवेश नहीं हुआ है, और उन clients के लिए इस तरह की घटना एक बहुत बड़ी समस्या है। मैंने infrastructure चलाते हुए जो कुछ देखा है, यह उसी से मेल खाता है। अगर आप cloud authentication events कैसे log होते हैं, उनके blind spots से निपट चुके हैं, तो यह पैटर्न आपको पहचाना लगेगा: महत्वपूर्ण रास्ता अच्छी तरह instrumented है, और लंबी पूँछ एक अँधेरा कमरा है।

जाँचिए कि आपके clients अब भी असुरक्षित हैं या नहीं

सिद्धांत एक तरफ, आपको सच में अपने estate की जाँच करनी चाहिए, और TLS की अच्छी बात यह है कि इसे अनुभवजन्य रूप से परखा जा सकता है। community के सदस्यों ने ऐसे hosts खड़े किए जो समझौता हुए इंटरमीडिएट्स द्वारा हस्ताक्षरित certificates परोसते हैं; अगर आपका client बिना certificate error के connect हो जाता है, तो वह अब भी उन पर भरोसा करता है। curl या किसी भी command-line tool की जाँच का सामान्य तरीका कुछ ऐसा दिखता है:

# A certificate error here means you're protected.
# A successful response means this client still trusts a compromised intermediate.
curl -v https://dv-g3b-emudhra.we-have-a-problem.com/
# You can also test whether a client will accept a forged cert for an
# arbitrary hostname by pointing it at a test server:
curl -v https://example.org --connect-to example.org::2.29.126.86:

इसे हर उस context से चलाइए जो मायने रखता है: आपके developer laptops, CI runners, container base images, server fleets। नतीजे इनके बीच अलग होंगे, और यही अंतर मायने रखता है। upgrade करने की ज़रूरत वाली चीज़ों की त्वरित सूची के लिए:

• Go services: Go 1.27.3 या 1.26.10 या बाद के संस्करण से rebuild करें, क्योंकि roots compiled in होती हैं।
• Python: certifi 2026.10.19 या बाद का संस्करण (pip और uv के versions भी जाँचें, वे अपना bundle साथ लाते हैं)।
• Rust: rustls-webpki 0.103.16 और webpki-roots / webpki-root-certs 1.0.10।
• Node.js और Electron: हर release line के लिए लंबित या patch releases; हर shipping artifact जाँचें।
• System stores: Ubuntu, Debian, Fedora, Alpine, Arch, Gentoo के लिए updated ca-certificates packages आ चुके हैं; लिखे जाने के समय FreeBSD का ca_root_nss लंबित था।

अगर आप package का इंतज़ार नहीं कर सकते, तो ज़्यादातर Linux distros आपको प्रभावित roots पर manually भरोसा हटाने देते हैं। Debian/Ubuntu पर इसका मतलब है /etc/ca-certificates.conf में certificates पर ! prefix लगाना और update-ca-certificates चलाना; Fedora/RHEL परिवार पर roots को /etc/pki/ca-trust/source/blocklist/ में निकालना और update-ca-trust चलाना। NixOS में एक साफ़ declarative option है:

security.pki.caCertificateBlacklist = [
"Comodo AAA Services root"
"emSign ECC Root CA - G3"
];

इन workarounds में आप असल में क्या हटा रहे हैं, यह ध्यान दीजिए: वे roots जिन तक वे इंटरमीडिएट्स चेन होते हैं। PKI remediation की यही कड़वी सच्चाई है। ज़्यादातर trust store tooling में “सिर्फ़ इस इंटरमीडिएट पर भरोसा न करें” जैसा कोई primitive नहीं है, इसलिए आप एक root को blocklist करते हैं और असंबंधित certificates के नुकसान को स्वीकार करते हैं। आपातकाल में यह सही सौदा है, पर है तो यह एक सौदा ही।

जहाँ मेरा विरोधी दावा टूट जाता है

मैंने शुरुआत में तर्क दिया था कि खुद की की गई key generation की विफलताएँ breaches से भी बुरी हैं। अब ईमानदारी से बताता हूँ कि यह कहाँ टूटता है। पारंपरिक breach, जैसे DigiNotar, कम से कम यह मानता है कि CA तब तक सक्षम तरीके से काम कर रहा था जब तक हमलावर ने उसे मात नहीं दी, और सक्षम CAs ही वह चीज़ हैं जिस पर पूरा सिस्टम दाँव लगाता है। एक key ceremony जो private key “4” उगलती है, इसका मतलब है कि audited controls, HSM procedures, compliance checkboxes, इनमें से किसी ने भी CA द्वारा किए जाने वाले सबसे संवेदनशील काम में एक विनाशकारी खामी नहीं पकड़ी। यह प्रतिद्वंद्वी की समस्या नहीं है; यह assurance की समस्या है, और assurance ही वह असली उत्पाद है जो एक CA बेचता है।

जहाँ यह दावा वाकई विफल होता है: breaches का बचाव करना कठिन होता है और वे लंबे समय तक चुपचाप चल सकती हैं। जो हमलावर सावधानी से इंटरमीडिएट key चुरा लेता है, वह उसे कम इस्तेमाल करके लक्षित interception के लिए प्रयोग कर सकता है और किसी CT लागू करने वाले client को कभी छुए बिना रह सकता है। इसके उलट, कमज़ोर keys को कोई भी सार्वजनिक certificates स्कैन करके खोज सकता है, और यही तरीका है जिससे यह वाली घटना सामने आई। एक तर्क यह है कि भयंकर-पर-स्पष्ट, सूक्ष्म-पर-लक्षित से बेहतर है। मैं इससे पूरी तरह सहमत नहीं हूँ, पर इसे खारिज भी नहीं कर सकता। सच्चाई यह है कि दोनों विफलता के तरीके एक ही जगह पहुँचते हैं: एक इंटरमीडिएट जिस पर से भरोसा हटाना पड़ता है, और clients की एक लंबी पूँछ जो महीनों तक संदेश तक नहीं पहुँचेगी।

इस पर आपको असल में क्या करना चाहिए

आप Web PKI को ठीक नहीं कर सकते। पर आप इसकी अगली विफलता के प्रति अपने exposure को घटा सकते हैं:

• अनुमान नहीं, परखिए। अपने clients को उन hosts के खिलाफ जाँचिए जो समझौता हुई chains परोस रहे हैं। इसमें एक दोपहर लगती है और यह आपको चौंका सकता है।
• Compiled artifacts को rebuild कीजिए। Go binaries और container images अपने trust stores साथ लेकर चलते हैं। “हमने base image patch कर दी” तब तक कोई मायने नहीं रखता जब तक आप redeploy न करें।
• Trust stores की inventory बनाइए। जो आपने गिना नहीं, उसे remediate नहीं कर सकते। certifi की प्रतियाँ, vendored bundles और Electron apps को गिनिए जैसे वे मायने रखते हों, क्योंकि रखते हैं।
• जहाँ संभव हो, system trust stores को प्राथमिकता दीजिए। हर vendored bundle एक patch है जिसे आप भेजना भूल जाएँगे। OS store पर केंद्रित होने से समस्या खत्म नहीं होती, पर आपको एक जगह मिलती है जिसे ठीक करना है।
• CT और revocation इकोसिस्टम पर नज़र रखिए। ऐसे projects मौजूद हैं जो गैर-ब्राउज़र clients तक ब्राउज़र-स्तरीय revocation लाना चाहते हैं, उन्हें समर्थन मिलना चाहिए; यह घटना उनके लिए फंडिंग माँगने का अब तक का सबसे अच्छा तर्क है।
• CA घटनाओं को security incidents मानिए। इन पर किसी को पेज होना चाहिए, inventory run शुरू होना चाहिए, और लिखित रिकॉर्ड बनना चाहिए, वैसे ही जैसे लीक हुए credential पर होता है। क्योंकि ये वही हैं।

कड़वा सार यह है: Web PKI का आपातकालीन ब्रेक ठीक उन्हीं clients में बखूबी काम करता है जिन्हें उसकी सबसे कम ज़रूरत है, क्योंकि CT ने उन्हें पहले ही कवर कर रखा था। जिन clients को ब्रेक की ज़रूरत थी (headless, embedded, vendored, भुलाए हुए) उनमें से ज़्यादातर के पास वह है ही नहीं। अगली इंटरमीडिएट CA समझौता घटना का सवाल “क्या” नहीं, “कब” का है। एकमात्र चर जो आपके नियंत्रण में है, वह यह है कि आपका अपना estate इसे नोटिस करता है या नहीं।