TLDR;
1. The TLS handshake involves a step to discover the commonly supported algorithms and can incur additional roundtrip if the first guess does not works out, its part of the protocol to keep it stateless
2. Cloudflare is scanning all the origins on daily basis and storing the result for supported algorithms to save on the possible roundtrip time
Whats missing in the article - They are saving on the *possible roundtrip latency, however they are not sharing the absolute lookup latency which now gets added to every connection
> The TLS handshake
Specifically TLS 1.3.
They don't explain, but late in TLS 1.3 development it was discovered that if you just say you're talking TLS 1.3 by increasing the version byte in the packet, as the protocol was designed almost thirty years ago, crap "security" middleboxes at a significant number of sites freak out and nothing works. Deploying a protocol which just doesn't work for, say, 10% of systems is unacceptable.
So the way TLS 1.3 actually works is - you begin the conversation pretending to be a TLS 1.2 client resuming an earlier conversation. You pick an arbitrary random long ID for this non-existent conversation, and you say you also happen to know a TLS 1.2 extension, and that bogus "extension" is actually your entire TLS 1.3 connection setup.
If the server you reached also knows TLS 1.3 they understand this charade, they reply "accepting" the resumption and since a TLS 1.2 resumption would just be encrypted application data, all TLS 1.3 just has the rest of the conversation labelled as TLS 1.2 application data and the dumb "security" middleboxes won't molest it. Nothing to see here.
If it does not know TLS 1.3 then this made-up ID won't match an actual conversation it has ever had, it can't resume that conversation, how about a new connection using the older protocol version, and everything proceeds as usual for the older protocol.
This reminds me of an article I read about browser agents strings and how we ended up where we are... just hacks on top of hacks.
Don't forget that TLS 1.0 introduces itself as SSL 3.1, TLS 1.1 as SSL 3.2, TLS 1.2 as SSL 3.3. This hack you describe involves TLS 1.3 also pretending to be SSL 3.3, because ossified infrastructure freaked out at seeing "SSL 3.4".
Yes, although I suppose the original idea I had for my comment rather got away from me, the reason I brought up TLS 1.3 is that this whole "Guess what KEX [Key Exchange e.g. X25519] to use" feature is only in TLS 1.3, previous protocols always eat a whole round trip to ask "Hi - do you speak TLS and if so what flavours?" and get a reply "I speak TLS 1.2 and I can do this KEX and that KEX and..."
The insight in TLS 1.3 was that we can guess a KEX and if we're correct we win a free roundtrip overhead†. So the history is that in TLS 1.2 you will always eat two round trips to talk HTTPS the first time, though in some cases you can reduce it to only one to "resume" conversations, in TLS 1.3 you can spend only one round trip even the first time if you guess the right KEX, and as few as zero round trips in some specific cases.
† This also means there's a strong incentive to have few KEX options, a new KEX must be unarguably better for a large constituency so that it's worth losing the round trip bonus to get a better KEX until your KEX is so popular that everybody will guess that KEX instead of the previous most popular.
Watch this happening! https://bytebybyte.dev/
[dead]
What latency gets added? Presumably on cache miss they already need to look up "whats the origin for www.example.com" and get info about it. This is just a handful of bytes in that record.
I assume they are referring to looking up the first guess to use in their local DB - all new connections get that even those for which the previous simple default would be optimal. If that lookup is hitting storage or going over their local network (or both: hitting storage on another node) rather than the result coming from local RAM, then this might be measurable. Even then, the cost of adding a ms or few to every connection might be much lower than the saving from the reduced round trips. To be worse overall the added latency for this lookup would need to be about 55ms (assuming 150ms saved on each round-trip that would have happened but didn't have to).
If the new for-every-request latency is noticeable above the noise floor at all then they could be really tricksy and make two connection attempts, one immediately with the default guess and one with the looked up value, and as soon as the first connection succeeds abandon the other. In fact if the majority of the connections needing a retry use the same method, so there are two covering almost all cases, you could remove the lookup and just send out two connection attempts, one with each of those two methods. I very much doubt this would be worth the effort, and it would add load elsewhere that would need to be accounted for in judging the value of the optimisation.
They have to check from their data store on the algo they scavenged for the clients, thats the whole idea about being correct instead of making a guess.