I got bitten by python SSL defaults are different than openssl:
/* Python custom selection of sensible cipher suites
* @SECLEVEL=2: security level 2 with 112 bits minimum security (e.g. 2048 bits RSA key)
* ECDH+*: enable ephemeral elliptic curve Diffie-Hellman
* DHE+*: fallback to ephemeral finite field Diffie-Hellman
* encryption order: AES AEAD (GCM), ChaCha AEAD, AES CBC
* !aNULL:!eNULL: really no NULL ciphers
* !aDSS: no authentication with discrete logarithm DSA algorithm
* !SHA1: no weak SHA1 MAC
* !AESCCM: no CCM mode, it's uncommon and slow
* Based on Hynek's excellent blog post (update 2021-02-11)
There is a configure option --with-ssl-default-suites=python|openssl which can
change these defaults.
I wonder if it would make sense to either expose this config option with a USE
flag or just enforce openssl defaults ?
Oh nice. I generally like the idea of following OpenSSL, and it would follow suit with e.g. how we disable custom certificate stores.
Could you make a quick comparison against the current OpenSSL defaults though? (presuming their notes might not be up-to-date)
Also, does that imply disabling things like ECDH? Wouldn't that risk breaking something?
I see that Fedora is using OpenSSL defaults . Debian doesn't seem to use the flag but with their humongous patch set they might be actually doing something like that anyway . Arch uses Python defaults .
(In reply to Michał Górny from comment #1)
> Oh nice. I generally like the idea of following OpenSSL, and it would
> follow suit with e.g. how we disable custom certificate stores.
> Could you make a quick comparison against the current OpenSSL defaults
> though? (presuming their notes might not be up-to-date)
> Also, does that imply disabling things like ECDH? Wouldn't that risk
> breaking something?
I don't know how to do that, not that into SSL.
What tripped me was the change of SECLEVEL, from 1 to 2 in python
SECLEVEL=2 requires a key size >= 2048 and we had an old cert which had key size = 1024.
This cert has been fixed now though.
Security, could you advise us here?
After some discussion, I think the best solution here would be to:
1. Stop overriding SSL defaults in CPython.
2. Enforce stronger SSL defaults in OpenSSL itself, possibly under USE=hardened or alike.
Long story short, I don't like CPython overriding the defaults indeed but I also don't like the idea of going with weaker settings than CPython does by default. After all, since upstream is already 'hardening' SSL settings here, weakening them on Gentoo would mean that people developing on Gentoo could create packages that fail on other distros.
I think the best compromise here is to have strong settings available in OpenSSL itself, and possibly use OpenSSL as a single 'switching point' for these settings rather than having individual packages override them.
CC-ing base-system@ as OpenSSL maintainers.
I think it makes sense to use the OpenSSL default settings for Python.
Could you file a separate bug with your proposed changes for the OpenSSL defaults?