Page MenuHomePhabricator

Support TLSv1.3
Open, NormalPublic


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

Event Timeline

BBlack created this task.Jul 13 2017, 1:59 PM
Restricted Application added a project: Operations. · View Herald TranscriptJul 13 2017, 1:59 PM
Restricted Application added a subscriber: Aklapper. · View Herald Transcript
BBlack moved this task from Triage to TLS on the Traffic board.Jul 13 2017, 1:59 PM

Change 365014 had a related patch set uploaded (by BBlack; owner: BBlack):
[operations/puppet@production] ciphersuites: add TLSv1.3 variants in "high" list

Change 365014 merged by BBlack:
[operations/puppet@production] ciphersuites: add TLSv1.3 variants in "high" list

Could be interesting for us to roll out openssl 1.1.0? ( 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)

JW added a subscriber: JW.Jun 24 2018, 1:45 PM
kolbert added a subscriber: kolbert.Feb 2 2019, 4:47 PM
Vgutierrez added a project: Goal.
94rain added a subscriber: 94rain.Apr 12 2019, 12:00 AM
BBlack added a comment.May 8 2019, 5:49 PM

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.

Paladox added a subscriber: Paladox.May 8 2019, 5:50 PM
Ladsgroup added a project: Performance.EditedMay 28 2019, 7:35 PM

Adding Performance because handshakes on TLS 1.3 are 100ms faster and also it caches parts of handshakes ( Hope that's fine for you.