-
-
Notifications
You must be signed in to change notification settings - Fork 31.1k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add ChaCha20 Poly1305 to SSL ciphers #71953
Comments
The ssl module has two cipher suite configurations, one for server-side and the other for client-side. Issue bpo-26470 will add OpenSSL 1.1.0 support, which will introduce new cipher suites with ChaCha 20 stream cipher and Poly1305 authenticator. CHAHA20 should be used when GCM is not available (AES GCM > CHACHA20 > AES CBC). $ bin/openssl ciphers 'ECDH+AESGCM:ECDH+CHACHA20:DH+AESGCM:DH+CHACHA20:ECDH+AES256:DH+AES256:ECDH+AES128:DH+AES:ECDH+HIGH:DH+HIGH:ECDH+3DES:DH+3DES:RSA+AESGCM:RSA+AES:RSA+HIGH:RSA+3DES:!aNULL:!eNULL:!MD5'
ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:DHE-DSS-AES256-GCM-SHA384:DHE-RSA-AES256-GCM-SHA384:DHE-DSS-AES128-GCM-SHA256:DHE-RSA-AES128-GCM-SHA256:DHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES256-CCM8:ECDHE-ECDSA-AES256-CCM:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA:ECDHE-RSA-AES256-SHA:DHE-RSA-AES256-CCM8:DHE-RSA-AES256-CCM:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA256:DHE-RSA-AES256-SHA:DHE-DSS-AES256-SHA:ECDHE-ECDSA-AES128-CCM8:ECDHE-ECDSA-AES128-CCM:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES128-SHA:DHE-RSA-AES128-CCM8:DHE-RSA-AES128-CCM:DHE-RSA-AES128-SHA256:DHE-DSS-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA:ECDHE-ECDSA-CAMELLIA256-SHA384:ECDHE-RSA-CAMELLIA256-SHA384:ECDHE-ECDSA-CAMELLIA128-SHA256:ECDHE-RSA-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA256-SHA256:DHE-DSS-CAMELLIA256-SHA256:DHE-RSA-CAMELLIA128-SHA256:DHE-DSS-CAMELLIA128-SHA256:DHE-RSA-CAMELLIA256-SHA:DHE-DSS-CAMELLIA256-SHA:DHE-RSA-CAMELLIA128-SHA:DHE-DSS-CAMELLIA128-SHA:ECDHE-ECDSA-DES-CBC3-SHA:ECDHE-RSA-DES-CBC3-SHA:DHE-RSA-DES-CBC3-SHA:DHE-DSS-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-CCM8:AES256-CCM:AES128-CCM8:AES128-CCM:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:CAMELLIA256-SHA256:CAMELLIA128-SHA256:CAMELLIA256-SHA:CAMELLIA128-SHA:DES-CBC3-SHA Bonus points: |
On X86 and X86_64 AES-NI and PCLMULQDQ can be detected with OPENSSL_ia32cap_loc(). https://www.openssl.org/docs/man1.0.2/crypto/OPENSSL_ia32cap_loc.html |
So, for servers really what we care about is if the _client_ has PCLMULQDQ/AESNI, not whether the server itself does. Unfortunately, there's no sane way to do this. Haven't reviewed this patch in terribly much detail, but conceptually fine. Cory, we should make sure this type of change propogates its way through requests, urllib3, hynek's blog post, and whatever else has a copy-pasted ciphersuite string. |
Yup. So for Requests at least, the fix is easy: because OpenSSL kindly just quietly ignores cipher suites it doesn't know about we can unconditionally add it to the requests/urllib3 cipher string. In the first instance we'll just do it statically, and then we can consider down the road whether Python/cryptography could give us a way to ask whether we should prefer ChaCha20 over AES-GCM. In the short term, my expectation is that we'd still want to prioritise AES-GCM over ChaCha20 in Requests: is there any reason to think that I'm wrong there? |
Simply doing AES-GCM before ChaCha20 is probably the simplest thing to start with, can always get fancier later. |
On 2016-08-15 13:09, Alex Gaynor wrote:
For servers we want to prefer CHACHA20 over AESGCM iff both sides have As you already said, there is no way to express this with OpenSSL cipher |
Update for Requests+urllib3 is here: urllib3/urllib3#947 Update for Twisted is here: https://twistedmatrix.com/trac/ticket/8760 |
tbh I personally perfer aiohttp over requests. |
Cory, Alex: Do you like to have a public API for CPU feature discovery? I don't mind to make OPENSSL_ia32cap_loc() a public API or even expose the bit set as structure with nice field names. Decorater: This ticket is not a vote on favorite packages. Please keep it on topic. |
Christian: Certainly I'd like to be able to use that API from within urllib3 and Twisted. Having something public would be really convenient. Of course, it'd be good if OpenSSL exposed something useful here, but in the absence of that Python would be convenient. |
Exposing it in some way would be good, but we can make that a seperate issue. |
Documentation cosmetic: # * Prefer ECDHE over DHE for better performance The patch seems to be adding the same preference comment? or did you |
New changeset d2111109fd77 by Christian Heimes in branch '3.5': New changeset 6f4f19217d9b by Christian Heimes in branch '2.7': New changeset f586742e56cb by Christian Heimes in branch 'default': |
Note: these values reflect the state of the issue at the time it was migrated and might not reflect the current state.
Show more details
GitHub fields:
bugs.python.org fields:
The text was updated successfully, but these errors were encountered: