Repository navigation
ssl: distrust compromised eMudhra intermediate CA keys #160040
Description
Feature or enhancement
I propose to add a small denylist to _ssl that rejects any TLS certificate chain containing one of the recently compromised eMudhra intermediate CA keys. The check runs during certificate verification and matches the DER-encoded SubjectPublicKeyInfo, so cross-signed certs that reuse a key are blocked, too.
Yesterday a set of eMudhra intermediate keys were disclosed as compromised and revoked, see https://emudhra.we-have-a-problem.com/. d=4 isn't a secure EC private key. Removing trust is the root store's job, but the update lags in practice, and there is no reliable way to propagate an intermediate revocation to applications. Until the roots are gone, Python still completes handshakes through a known-bad key.
As a defense in depth Python should blocks those connections in the meantime. With a simple callback, this can be enforced on every SSLContext when verification is enabled (CERT_OPTIONAL / CERT_REQUIRED); CERT_NONE is unaffected.
Has this already been discussed elsewhere?
No response given
Links to previous discussion of this feature:
Golang has implemented filtering to address CVE-2026-111943.
- Go issue: crypto/x509: mitigation for security concerns with a specific Certificate Authority golang/go#82345
- Go fix (crypto/x509): https://go.dev/cl/851047
- eMudhra disclosure and affected intermediates: https://emudhra.we-have-a-problem.com/
Activity
pythongh-160040: Distrust compromised eMudhra intermediate CA keys
pythongh-160040: Distrust compromised eMudhra intermediate CA keys
tiran commentedon Oct 21, 2026
CC RMs @hugovk @Yhg1s @pablogsal and security @sethmlarson
pythongh-160040: Fix c-analyzer check and add What's New entry
pythongh-160040: Add tests for distrusted eMudhra intermediate CA keys
zooba commentedon Oct 21, 2026
I don't see why we should assume that users can update their entire application runtime faster than their OS certificates.
Certificate bundles are intended to be updated efficiently and without breaking unrelated parts of the applications relying on them. Updating a Python release is nowhere near as safe.
pythongh-160040: Match distrusted SPKI by SHA-256 digest
sethmlarson commentedon Oct 21, 2026
Thanks for suggesting this and submitting a patch @tiran. My biggest concern is the precedence that this sets, would we reach for this functionality for future compromises and tell users to upgrade their Python? I know you're putting this forward as defense-in-depth so it's not either-or, but I am cautious about signing us up for more expedited releases and asking users to mitigate by updating the Python runtime.
My preference is providing users and distributions mechanisms to resolve these issues themselves without requiring a series of expedited Python releases and upgrades. Maybe this would take the form of a defined pattern for integrating a CRL for Python distributions? (upki?) And maybe leaning more on Windows and macOS certificate APIs?
tiran commentedon Oct 21, 2026
The situation would be far less messy if packages would stop shipping their own trust store and solely rely on system trust store. Then users would only need to update or reconfigure their OS and everything would be fine. I'm looking forward to a world where every Linux OS has something like upki or a PKCS#11 provider with OS-wide revocation lists and policies.
It's 2026 and
certifiis still a thing... On top of that, packages likepipalso vendorcertifi. And that's just the tip of the ice berg! I know of at least one more packages with almost 14 million downloads per day that ships a custom root CA bundle with eMudhra certs (the maintainers are aware). Let's not forget about packages with upper version caps that prevent security updates.I don't have to explain to you how serious a compromise root or intermediate CA is. Thankfully it does not happen that often. The last major compromises happened in 2011. DigiNotar got owned and TurkTrust accidently issued two CAs. I strongly believe that this event requires special care and defense-in-depth. Google felt the same way.
tiran commentedon Oct 21, 2026
Sorry, I forgot to address your biggest concern:
I agree, it's a valid concern. Let's document when and why Python is blocking certificates:
sethmlarson commentedon Oct 21, 2026
@tiran Thanks, I'm okay moving forward if this is clear to users and distributions why this list exists and that it's not to be relied on for a timely defense to compromised certificates. Does Go publish any of their thinking or documentation around their decision to adopt this?
I've also confirmed with RMs that there is willingness to backport this PR to prior versions, so it will be more effective than only landing in 3.16.
tomato42 commentedon Oct 21, 2026
While, yes, this is a sub-optimal solution, the proper solution (have OpenSSL and similar libraries able to consume OneCRL or CRLSets) is still some time away, but it is being worked on.
Node.js also implemented the blocklist: nodejs/node#66871
zooba commentedon Oct 21, 2026
Let's also be clear that it is not a security boundary, and we are not obliged to treat changes to the blocklist or its behaviour as vulnerabilities. No change to the blocklist will be embargoed, and its presence should not cause the PSRT to be included in pre-disclosure analysis or updates of future issues. We'll make updates in public after the problems are disclosed and after actual certificate bundle distributors have updated their bundles/revocation lists.
Yes, I'd really hoped we'd have a more secure (aka less configurable) "access HTTPS endpoint" API by now to take the most burden of what everyone wants
certififor. Something without OpenSSL being part of the public API (which is what prevents us reliably relying on the OS functionality).pythongh-160040: Refine distrusted SPKI check, docs, and test cert ge…
tiran commentedon Oct 22, 2026
Nope :/
In my scans I even found packages with recent releases that had an ancient CA bundle from about 2015/2016. The bundle had the Comodo AAA cross-sign cert, distrusted StartCom+WoSign, and were lacking the Let's Encrypt ISRG Root X1 CA.
pythongh-160040: Store distrusted test certs in an encrypted zip
Yhg1s commentedon Oct 22, 2026
FWIW, I think this is a reasonable action to take at this point, and I don't think it creates unreasonable expectations.. We're helping people avoid getting MITM'd because we can, not because we're the right place to do so. (It's also quite attractive that this will let people on the patched versions of Python upgrade to a safe version of pip by simply running
python -m pip install -U pip, without having to know about hashes and URLs.)willingc commentedon Oct 22, 2026
I agree with @Yhg1s.
Thanks core team, RMs, and PSF security folks for getting information out in a timely and helpful way. Anything that we can do to help maintainers who are not security experts (such as scientific Python package maintainers) to get things more secure is very much appreciated.
P.S. Thanks @tiran for all of your help, and it's great to see you here. I've missed you.
pythongh-160040: Drop the ssl What's New entry