mitmproxy में --emudhra विकल्प जोड़ा गया

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

Mitmproxy ने एक `--emudhra` विकल्प जोड़ा है, जो हाल ही में उजागर हुई, बेहद कमजोर eMudhra intermediate CA keys—जिनमें से एक सचमुच 4 थी—का उपयोग करके HTTPS certificates बनाता है जिन्हें कई पुराने या unpatched devices अभी भी trust करते हैं। टिप्पणीकार चर्चा करते हैं कि यह legacy Android phones, smart TVs, और IoT devices के traffic को transparently intercept करने में कैसे मदद करता है, साथ ही iOS और macOS जैसे platforms पर certificate revocation और trust store updates की व्यापक विफलता को भी उजागर करता है। यह घटना CA governance, संभावित backdoors, ऐसे tools के जिम्मेदार उपयोग, और certificate authority की गंभीर चूक को देखते हुए सार्वजनिक shaming उचित है या नहीं—इन सवालों को उठाती है।

mitmproxy में नया --emudhra फीचर

  • यह विकल्प इंटरसेप्ट किए गए TLS प्रमाणपत्रों पर अब सार्वजनिक हो चुकी eMudhra इंटरमीडिएट कुंजियों में से किसी एक से हस्ताक्षर करता है।
  • इसका उद्देश्य व्यावहारिक रूप से यह परखना है कि कौन-से डिवाइस और ऐप्स अभी भी इन compromised chains पर भरोसा करते हैं।
  • कुछ लोग व्यापक कवरेज के लिए कई compromised chains (emSign और AAA paths) को एकीकृत करने का सुझाव देते हैं; एक merge request लिंक की गई है।

उपयोग के मामले: डिबगिंग, रिवर्स इंजीनियरिंग, जेलब्रेकिंग

  • इसको उपयोग करने को लेकर उत्साही प्रतिक्रियाएँ इन पर आईं:
    • पुराने Android फ़ोन (यदि ऐप्स pinning नहीं करते या अपना trust store इस्तेमाल नहीं करते)।
    • Smart TVs और IoT डिवाइस, ताकि vendor traffic, configs, या firmware updates देखे जा सकें।
  • बताए गए mitm flows: config/firmware/ads channels को इंटरसेप्ट करना, जो dev modes सक्षम कर सकते हैं या RCE दे सकते हैं।
  • सीमाएँ: certificate pinning, attestation, private roots, और वे डिवाइस जो पहले ही trust update या revoke कर चुके हैं।

eMudhra compromise का विवरण

  • आठ intermediate CAs के P-384 private keys बेहद कमजोर थे; उदाहरण दिए गए (4, 56, 66, आदि), जो प्रभावी रूप से 3–8 bits of entropy थे।
  • कुछ व्याख्याएँ बताती हैं कि यह ऐसा लगता है जैसे गलती से 384-bit की जगह 8-bit keys इस्तेमाल हो गईं।
  • शामिल roots: emSign ECC Root CA – G3 और एक पुराना AAA root; इस पर टाइमलाइन चर्चा की गई है कि कौन-सा major trust stores में कब शामिल/बाहर है।
  • elliptic-curve key search के लिए लगभग 2^(n/2) प्रयासों की आवश्यकता नोट की गई है, जिससे “मध्यम रूप से कमजोर” EC keys GPUs पर brute-force की जा सकती हैं।

Platform Revocation Behavior (विशेषकर Apple)

  • कई users ने test sites पर जाते समय iOS, iPadOS, और macOS में असंगत परिणाम रिपोर्ट किए:
    • कुछ ने देखा कि सभी chains blocked थीं।
    • दूसरों ने अभी भी 1–3 forged chains accepted देखीं।
  • परिकल्पनाओं में phased rollout, OCSP/CRL lookup failures, या timeouts शामिल हैं; व्यवहार अभी भी स्पष्ट नहीं है।
  • macOS Keychain में roots को manual distrust करना bad chains को भरोसेमंद रूप से ब्लॉक करता है।

नैतिकता, नामकरण, और व्यापक सुरक्षा विषय

  • --emudhra नाम को लेकर मिश्रित राय है:
    • कुछ इसे एक गंभीर CA failure के लिए उचित accountability मानते हैं।
    • अन्य इसे उन व्यक्तियों पर बोझ डालना मानते हैं जो “कभी इसे भूल नहीं पाएँगे।”
  • कई टिप्पणियाँ इसे “एक security disaster को defensive tool में बदलना” मानती हैं, जिससे उपयोगकर्ता उन डिवाइसों का निरीक्षण और नियंत्रण कर सकते हैं जिन्हें vendor lock down करना चाहते हैं।
  • सभी CAs को समान रूप से कमजोर keys के लिए व्यवस्थित रूप से स्कैन करने के प्रस्तावों का उल्लेख है; एक reply नोट करती है कि यह विशेष issue मौजूदा tools का उपयोग करके पाया गया था और उस scan में कोई अन्य कमजोर keys नहीं देखी गईं।