CVE-2026-111943: समझौता किया गया इंटरमीडिएट प्रमाणपत्र प्राधिकरण

मूल लेख ↗ Hacker News चर्चा ↗

eMudhra के एक समझौता किए गए इंटरमीडिएट प्रमाणपत्र प्राधिकरण में बेहद कमजोर elliptic-curve कुंजियाँ पाई गई हैं, जिससे हमलावर सार्वजनिक प्रमाणपत्रों से प्राइवेट कुंजियाँ निकालकर किसी भी डोमेन के लिए “वैध” TLS प्रमाणपत्र बना सकते हैं। ऑपरेटिंग सिस्टम, भाषाएँ और टूल प्रभावित इंटरमीडिएट्स को revoke या blacklist करने की होड़ में हैं, खासकर उन मामलों में जहाँ सॉफ्टवेयर OS अपडेट पर निर्भर रहने के बजाय अपनी खुद की trust store शिप करता है (जैसे Go का crypto/x509, Python का certifi, uv, containers, और embedded devices)। टिप्पणीकार यह भी बताते हैं कि क्लाइंट अभी भी खराब CAs पर भरोसा करता है या नहीं, यह कैसे परीक्षण करें, और trust-store प्रबंधन तथा layered package managers की fragmented प्रकृति समय पर और व्यापक remediation को कितना कठिन बना देती है।

घटना की प्रकृति

  • eMudhra ने आठ इंटरमीडिएट CA कुंजियाँ इतनी कमजोर तरीके से जनरेट कीं कि प्राइवेट कुंजियाँ सार्वजनिक प्रमाणपत्रों से निकाली जा सकती हैं।
  • इन कुंजियों वाला कोई भी व्यक्ति मनचाहे डोमेन (बैंक, PyPI, आदि) के लिए “वैध” TLS प्रमाणपत्र जारी कर सकता है, जिससे MITM हमले संभव हो जाते हैं।
  • कई पोस्टर उसी व्याख्या साइट और पिछले HN थ्रेड्स की ओर लिंक करते हैं; यह Go-केंद्रित CVE एक बड़े, जारी eMudhra घटना का हिस्सा है।

Go-विशिष्ट पहलू और ट्रस्ट स्टोर

  • चर्चा का केंद्र Go का crypto/x509 है, जो सिस्टम ट्रस्ट स्टोर के साथ एक आंतरिक denylist का उपयोग करता है।
  • यह CVE मूलतः यह है: कुछ Go संस्करणों में समझौता किए गए इंटरमीडिएट्स के लिए अपडेटेड denylist एंट्रीज़ नहीं हैं।
  • यह स्पष्ट किया गया कि Go प्रमाणपत्रों को तभी अस्वीकार करेगा यदि या तो OS ने उन्हें हटा दिया हो या Go denylist अपडेट हो गई हो।
  • एक महत्वपूर्ण बारीकी: binaries में Go की trust logic स्थिर रूप से एम्बेड होती है, इसलिए लाभ पाने के लिए आपको ऐप्स को नए Go toolchain के साथ rebuild/redeploy करना होगा।

OS और distro की प्रतिक्रियाएँ

  • बताया गया है कि Gentoo और Slackware अपडेट हो चुके हैं; विशिष्ट Gentoo emerge commands साझा किए गए हैं।
  • macOS OS स्तर पर इन प्रमाणपत्रों पर भरोसा नहीं करता दिखता, हालांकि कुछ टूल अलग trust view दिखाते हैं।
  • Red Hat की प्रतिक्रिया को अधूरी और धीमी बताया गया है; केवल दो Comodo roots हटाने वाला एक workaround नोट किया गया है, जिसे “ongoing” चिह्नित किया गया है।
  • तुलना की गई: कुछ लोग तेज़ security updates के कारण Debian को पसंद करते हैं; अन्य अभी भी RHEL की समग्र patch quality को बेहतर मानते हैं, लेकिन लगातार देरी नोट करते हैं।

अन्य ecosystem और tooling

  • Python, certifi, uv, bun, Java (AWS Corretto), और अन्य stacks अपने CA bundles embed कर सकते हैं और उन्हें स्पष्ट अपडेट की आवश्यकता हो सकती है।
  • Python उपयोगकर्ताओं के लिए अलग मार्गदर्शन का संदर्भ दिया गया है; uv के बारे में नोट किया गया है कि उसका अपना trust store है।
  • Browsers के पास अक्सर स्वतंत्र CRLs होते हैं और वे सुरक्षित हो सकते हैं, भले ही CLI tools (curl, wget) न हों।

परीक्षण और स्थानीय mitigation

  • कई test endpoints साझा किए गए हैं; सही परिणाम TLS failure होना है, “unable to get local issuer certificate” के साथ।
  • लोग इन hosts के विरुद्ध curl और Python urllib का उपयोग करके trust behavior सत्यापित करते हैं।
  • Workarounds में macOS पर curl को updated Homebrew CA bundle की ओर point करना शामिल है; Debian पर CA certs प्रबंधित करने के लिए scripts साझा किए गए हैं।

परिचालन और मेटा थीम्स

  • बहुत से लोग multi-layered package management, containers, और बिखरे हुए trust stores को लेकर निराशा व्यक्त करते हैं।
  • कुछ लोग containers का समर्थन करते हैं; अन्य सरल host-based deployment और systemd hardening के पक्ष में तर्क देते हैं।
  • स्वचालित patching के लिए LLMs/agents पर भरोसा करने पर बहस है: coverage के लिए मददगार, लेकिन operator की complacency का जोखिम भी है।
  • शब्दावली (“monster-in-the-middle” बनाम “man-in-the-middle”) और इस विषय के कितनी जल्दी “old news” बन जाने पर संक्षिप्त चर्चा है।