Donald Stufft added the comment:
The cipher string includes HIGH, so if ChaCha20Poly1305 or another cipher suite
is added to OpenSSL it'll get included in the cipher string by default.
So the major difference of what you suggest would be no longer prioritizing
ciphers. However I would argue that would be bad. The priority exists so that
we get the best possible cipher is as many situations as we possibly can. It
doesn't mean that we'll get the best possible cipher in *every* single
situation, but generally we will.
To this ends it prioritizes:
* PFS with a secure cipher over everything else (Your string would do this
as well)
* After that prefer ECDHE over DHE
* After that, prefer AES-GCM
* After that, prefer AES-CBC
* After that, any other HIGH cipher
* After that, 3DES
* After that, any use of RC4 including those with PFS
So if OpenSSL added ChaCha20Poly1305 it would fit into the priority after
AES-GCM and AES-CBC.
For any device that has hardware support for AES (AES-NI) AES-GCM is hands down
a better choice of cipher. It is secure, has no issues in the spec itself, and
it is *fast*, like 900MB/s for AES-128-GCM on a Sandy Bridge Xeon w/ AES-NI
(ChaCha20Poly1305 got 500MB/s on the same hardware, however it is a 256bit
cipher will AES-128-GCM is a 128 bit cipher). Using ChaCha20 on those devices
would be a worse choice than AES-GCM.
However on lower powered devices, such as smart phones, especially those
without hardware support for AES, ChaCha20 really shines. A Galaxy Nexus can do
AES-256-GCM at 20MB/s whereas it can do ChaCha20Poly1305 at 92MB/s (same phone).
So in an ideal world, assuming ChaCha20 was implemented in OpenSSL, we'd adjust
the default cipher string based on the hardware they are running on. However
since we don't have the ability to do that then preferring AES (which we know
on some systems will be much faster) over an unknown future cipher (which we
have no knowledge of if it will be faster or not) is a much more reasonable
choice. If at some point in the future OpenSSL gains ChaCha20Poly1305 support
then these strings should probably change to put ChaCha20Poly1305 in between
AES-GCM and AES-CBC because on any given the system the likelyhood that you
want AES-GCM is still higher than ChaCha20, but the likelyhood you want
ChaCha20 over AES-CBC is greater.
It's also important to note that the server in any TLS communication is the end
that picks exactly which cipher we select. Ideally all servers will be
configured to have the strongest cipher first, and to prefer their own cipher
order. In that case for the *client* side of a TLS connection the order of the
ciphers doesn't matter and thus your string vs the implemented string has no
difference in behavior. However if the server doesn't enforce their own
preference for ciphers, then the difference will be that an undefined cipher
will be selected (could be AESGCM, AESCBC, ChaCha20, or Camellia). On the
server side of this, if you're using Python to terminate your TLS on the server
side, the likelyhood that a server is running on a low powered device where the
benefits of ChaCha20Poly1305 are the highest are pretty low and preferring
AES-GCM is an even safer idea.
----------
_______________________________________
Python tracker <rep...@bugs.python.org>
<http://bugs.python.org/issue20995>
_______________________________________
_______________________________________________
Python-bugs-list mailing list
Unsubscribe:
https://mail.python.org/mailman/options/python-bugs-list/archive%40mail-archive.com
