Task to track our eventual TLSv1.3 support. Currently we're blocked on deploying a stable OpenSSL-1.1.1 release, but there's some prep work to be done on the ciphersuite and nginx sides as well. see also T205378: Enable ESNI support on Wikimedia servers
|operations/puppet : production||ciphersuites: add TLSv1.3 variants in "high" list|
Could be interesting for us to roll out openssl 1.1.0? (https://www.openssl.org/blog/blog/2018/02/08/tlsv1.3/). OpenSSL 1.1.1 should be ABI and API compatible with OpenSSL 1.1.0, so basically we'd be one minor release away from TLSv1.3
Yeah, that's the most plausible option (and we're already using custom OpenSSL 1.1 packages on Debian jessie to support e.g. chacha), but 1.1.1 has only just seen it's first alpha release (and they won't release it in a final version until TLS 1.3 is final)
Putting this here for lack of a better place, for future reference:
In the TLSv1.2 (and below) world, we've gone with a static preference on symmetric ciphers of ChaPoly -> AES256 -> AES128 for Various Hysterical Raisons (mostly logic about client mix and security tradeoff, etc). TLS 1.3 is going to be configured separately and has very different mechanisms. For the initial ATS setup we're likely to keep that same static preference ordering (ChaPoly > AES), but I think it may make sense (after initial deploy?) to take advantage of OpenSSL 1.1.1's SSL_OP_PRIORITIZE_CHACHA. The situation is different with TLS 1.3 because we know that no TLS-legacy devices will ever use TLS 1.3. For TLS 1.3 with that OP enabled, we'd probably switch our TLS preference list to AES256 -> ChaPoly -> AES128, and then let the OP prioritize ChaPoly over AES256 for clients that indicate the preference due to lack of AES acceleration.