The ssl module has two cipher suite configurations, one for server-side and the other for client-side. Issue #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:
Prefer CHACHA20 over AESGCM on hardware without AES-NI and CLMUL CPU instructions.

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:
> 
> Alex Gaynor added the comment:
> 
> 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.

For servers we want to prefer CHACHA20 over AESGCM iff both sides have
AES-NI and CLMUL. A server on a device such as a RPi benefits from
CHACHA20, too. For that reason I also changed the server side cipher string.

As you already said, there is no way to express this with OpenSSL cipher
suite string.

Update for Requests+urllib3 is here: https://github.com/shazow/urllib3/pull/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
 #   * Prefer any AES-GCM over any AES-CBC for better performance and security
+#   * Prefer any AES-GCM over any AES-CBC for better performance and security

The patch seems to be adding the same preference comment? or did you
mean other preference?

New changeset d2111109fd77 by Christian Heimes in branch '3.5':
Issues #27850 and #27766: Remove 3DES from ssl default cipher list and add ChaCha20 Poly1305.
https://hg.python.org/cpython/rev/d2111109fd77

New changeset 6f4f19217d9b by Christian Heimes in branch '2.7':
Issues #27850 and #27766: Remove 3DES from ssl default cipher list and add ChaCha20 Poly1305.
https://hg.python.org/cpython/rev/6f4f19217d9b

New changeset f586742e56cb by Christian Heimes in branch 'default':
Issues #27850 and #27766: Remove 3DES from ssl default cipher list and add ChaCha20 Poly1305.
https://hg.python.org/cpython/rev/f586742e56cb

See #27850. ChaCha20 is even less relevant for 3.3 an 3.4. It either requires LibreSSL, patch #26470 or a patched OpenSSL installation.