Repository navigation
Conversation
Several eMudhra intermediate CA keys were compromised and revoked. As defense in depth, reject any chain containing one of the affected public keys, so connections are blocked even when the root store (OS, container) has not yet dropped the issuing roots or certifi/pip are not updated. The denylist in `Modules/_ssl/distrusted_spki.h` matches the DER-encoded SPKI, so cross-signed certificates that reuse a key are blocked too. Mirrors Golang's [crypto/x509](https://go.dev/cl/851047) change. See https://emudhra.we-have-a-problem.com/. Signed-off-by: Christian Heimes <christian@python.org>
a2f652f to
6275d65
Compare
Name the SPKI table struct type and list the const table in the c-analyzer "should be const" ignore list, so check-c-globals passes. Document the new verification behavior in What's New for 3.16. Signed-off-by: Christian Heimes <christian@python.org> Co-Authored-By: Claude Opus 4.8 (1M context) <noreply@anthropic.com>
tiran
added
type-security
Documentation build overview
48 files changed ·
|
Signed-off-by: Christian Heimes <christian@python.org>
Signed-off-by: Christian Heimes <christian@python.org>
| @@ -0,0 +1,6 @@ | |||
| -----BEGIN PRIVATE KEY----- | |||
There was a problem hiding this comment.
We receive a steady stream of beg bountiesreports to PSRT about private keys being present in bugs.python.org, etc. A compromised private key would likely invite even more attention, can we obfuscate this in a way that prevents that from happening?
There was a problem hiding this comment.
yeah I was thinking the same thing based on past reports. also, distrusted_keycert.pem looks like a premade cert signed with the distrusted private key... rather than checking that hazmat-ish thing into our tree, could the test wanting that just generate one at runtime when an openssl command is available (too slow? we can tag it as @support.requires_resource('cpu') ).
I like that the filenames clearly have distrusted_ in their name. I wish things scanning for private key strings would grow up and learn to not report things like this but they tend to be a trivial grep.
There was a problem hiding this comment.
It's two ECC genkey operations and one ECC signing operation. That is incredible fast, maybe 10ms in total on a recent computer.
Is this really worth the trouble and extra complications? "Security scanners" are already complaining about the private RSA keys. And they will start to complain about the eMudhra CA certs, too. I could obfuscate the files with ROT13 or put them in a password-protected zip file (Brave Sir Robin?).
There was a problem hiding this comment.
The problem is really the dumb scanners that do stuff like blocking git push - I have to jump through all sorts of hoops to admin-override checks just to maintain a mirror at work, and then I also have to go and add comments to all these files to satisfy another scanner that this isn't a real secret (or else they're going to contact my manager 😟 ).
But yeah, even something that separates the header from the base 64 and writes the key file out just for the test would be a huge pain relieved from my perspective. Even renaming to .txt may well work, though I haven't tried that. I assume others face similar issues.
| @@ -0,0 +1,6 @@ | |||
| -----BEGIN PRIVATE KEY----- | |||
There was a problem hiding this comment.
yeah I was thinking the same thing based on past reports. also, distrusted_keycert.pem looks like a premade cert signed with the distrusted private key... rather than checking that hazmat-ish thing into our tree, could the test wanting that just generate one at runtime when an openssl command is available (too slow? we can tag it as @support.requires_resource('cpu') ).
I like that the filenames clearly have distrusted_ in their name. I wish things scanning for private key strings would grow up and learn to not report things like this but they tend to be a trivial grep.
gpshead
added
needs backport to 3.11
sethmlarson
left a comment
sethmlarson
left a comment
There was a problem hiding this comment.
Few comments, otherwise I am happy with the implementation.
| @@ -0,0 +1,6 @@ | |||
| :mod:`ssl` now rejects TLS certificate chains that contain any of a set of | |||
There was a problem hiding this comment.
As discussed in the parent issue, we should document clearly that this is a last-line-of-defense, and not meant to be relied on by users or distributions as fix for a CA certificate compromise.
There was a problem hiding this comment.
I have updated the blurb, what's new, and header file comment. Please review and suggest changes.
| * Verification rejects any chain with a cert whose SPKI SHA-256 digest is in | ||
| * the _distrusted_spki table. We match the key, not a cert fingerprint, so | ||
| * cross-signs that reuse the key are blocked too. To block another key, add | ||
| * its digest. |
There was a problem hiding this comment.
Let's add a note here for our future selves about the high threshold for a compromise to be considered being added here.
…neration * use SHA256_DIGEST_LENGTH * verify cb: keep OpenSSL error, fail closed on internal errors * generate intermediate key on the fly * update docs to explain defense-in-depth / special circumstances Signed-off-by: Christian Heimes <christian@python.org>
| verification while that update has not yet reached the OS, a container image, | ||
| or a bundled trust store in various Python packages. Keys are added to the | ||
| denylist only under a very high threshold. | ||
| (Contributed by Christian Heimes in :gh:`160040`.) |
There was a problem hiding this comment.
Documenting the change in What's New document makes it harder to backport to other branches. Would it be enough to document it as a Changelog entry instead?
If we keep it in What's New, it should be moved to special sections in old What's New documents (when the change will be backported), such as https://docs.python.org/dev/whatsnew/3.14.html#notable-changes-in-3-14-5.
The compromised eMudhra CA certs and the leaf signed by them are kept in a password-protected zip so naive security scanners don't flag them. test_ssl and make_ssl_certs read the PEMs from the archive. Signed-off-by: Christian Heimes <christian@python.org>
7 participants
Several eMudhra intermediate CA keys were compromised and revoked. As defense in depth, reject any chain containing one of the affected public keys, so connections are blocked even when the root store (OS, container) has not yet dropped the issuing roots or certifi/pip are not updated.
The denylist in
Modules/_ssl/distrusted_spki.hmatches the DER-encoded SPKI, so cross-signed certificates that reuse a key are blocked too. Mirrors Golang's crypto/x509 change. See https://emudhra.we-have-a-problem.com/.