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
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.
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.
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.
Great. Next can cloudflare stop providing Https to the user (giving the impression of security) when the connection back to the origin isn't strict HTTPS and is often plaintext?
It is more secure (though not end-to-end secure, of course) from the PoV of most threat models because the monitoring most are most concerned about is at their side of the connection (“local infra (often wireless) -> through ISP -> …” or “local -> through ISP -> through state/org level monitoring -> …”).
Tracking you by monitoring the network traffic between CF (or other connection aggregator) and the origins is possible, but usually significantly more effort. Those with reason to be concerned about true end-to-end encryption will know that seeing any CF artefacts means they need to investigate to know if they are getting e2ee or just end-to-proxy.
At a minimum I'd like cloudflare to mark such traffic in some way, and browsers to put a little cross through the "Https" indicator to show the traffic is passing unencrypted across the internet.
That is not a small “minimum”. There are places in the certificate format that a new flag can go, but then all browsers and apps that perform https requests need to be altered to display this in a manner that is:
• consistent
• not overly serious, so users who end up trained to ignore this new signal don't automatically ignore more significant warnings
• (and this is the fun part) communicate this new semaphore signal to the general public without confusing them…
To head off one cynical question: “Why worry about the general public when they wouldn't care anyway and just click through warnings with wreckless abandon already?” - if not the general public then who would this be for? Those who might need to care are already checking if their data is going through CF and so might not to under true E2EE.
They can just add an http header that browsers and browser plugins can listen for, they already add `cf-cache-status: HIT`, so they could add this too:
cf-http-endpoint: 1
or if you want it to match their own terminology[0], it could be:
Genuine question: why wouldn’t they have been doing this already? It feels like obvious low-hanging fruit on a critical path, so I presume there’s something more to it than I’m imagining.
Speculation, no insider info: Its one more thing that needs to be sent out to all their proxies, and could be a reason for meaningfully different metrics whenever the (non-time-critical) regular updates fail. The more configuration/state each proxy receives and processes, the more difficult it will be to determine what is wrong when one exhibits abnormal behavior. At least one of the serious outages was even directly attributed to having accidentally exceeded some hard limit (very hard actually, a rust panic) in how much data could be distributed through one particular such channel, see https://blog.cloudflare.com/18-november-2025-outage/
Ever since http2 and especially http3 (my god did that take years to reach the mainstream), I've been sad to see intermediaries like Cloudflare gobbling up all the newest protocols and ciphersuites and etc while open source lags behind. The separation has reached years, there's years between new security measures implemented by Cloudflare and when it'll be available to independent server operators. It is getting progressively harder to stay current because you are fighting against an entity with vastly more resources and with far more of an incentive to remain the easiest way to get there. With Cloudflare you get all the latest http server protocols and versions, all the latest everything ciphers TLS everything, and all in exchange for letting them MitM your traffic. I've leaned on them myself too because there is just no way to get that stuff for myself these days. h2o was the only readily available http3 software for years.
I'm curious how Cloudflare keeps the learned key exchange preference accurate when a hostname is backed by multiple origins with different TLS configurations?
Cloudflare is the canonical example of why you can't vibe-code infrastructure. Knowing that this optimization was even necessary, let-alone having the ability to build it, is something that doesn't become apparent until you're operating at considerable scale. Once there, of course if you're Cloudflare, you use coding agents to build it. But outside of these temples of scale, good luck even knowing it was needed.
If you work at a SaaS of any kind, I think it's worthwhile considering what things will look like when scale is the only thing that is really defensible anymore.
The irony is that everything about this speaks to vibe coding. The writeup was written by Claude, in a good way (E.g "while the milliseconds are important, that second part may matter more").
I think things like this are now possible through vibecoding.
That's not what I'm saying at all. I guarantee Cloudflare engineers are using coding agents every day for everything they do. The point is that discovering what you need to build comes only with the experience of operating at tremendous scale. I do not believe that someone could replicate what Cloudflare offers today just because they, say, have invested $20K/mo for 100x Claude Max plans, all of which are cranking 24x7.
This is the SaaS advantage you can still have in an AI era. You can beat your competition by being exposed to more of the real world than them. For example, anyone can vibe code an accounting app, but no matter how good AIs get no vibe-coded AI app can have a track record of what happens in an complaince audit and whether it stood up during a tax audit from some particular jurisdiction. The real world will always be more complicated than an AI can vibe code a solution to, if for no other reason that as we advance in AI, the amount of stuff an AI needs to deal with is going to increase from everyone else doing AI stuff too.
nothing stops you from simulating load. something that scales, by definition, it will have something in the small that is more or less identical to something in the large. it goes both ways.
the obstacle was always the parade of tedious obstacles to create (in this case) a sophisticated virtual harness to simulate (in this case) whatever the hell this article is about. so yeah, actually, the capability of retail coding plans are kind of the only thing that matters...
For content delivery you can simulate the load one PoP would get. You don't need to be at Cloudflare scale to build a testbench with 800G+ of traffic at different pps.
It's a capital heavy investment in an already crowded marketplace (there are many CDN companies well predating Cloudflare) with little guarantee of return on investment. Who are you expecting to show up? If you want alternatives, there are plenty, for specific products/features.
1) So they saved 15ms on the connection so that you can then wait 20s in their annoying nag screen before reaching the real website content.
2) On the Monday they complain about the load on server by LLM scrapings compulsively your webserver an offer themselves as the internet guardian solution; and on Tuesday, they compulsively send useless requests to your servers so that they can save a few microseconds in the very first connection ever to your server.
"For each TLS 1.3 capable origin, we run a series of a few lightweight TLS handshakes, each offering exactly one key agreement group: X25519, P-256, P-384, P-521, or X25519MLKEM768. [...] And because the active scanning happens outside your production traffic path, we confirm that both your origin and the network in between can handle connections with a stronger key agreement before any real traffic depends on it.
2) Perhaps theres a slight difference between thousands of requests per day from untrusted entities and a single TLS handshake per day from a trusted one? (Note i understand you clearly don't trust cloudflare, but the people who sign up for cloudflare do trust them - that's the trust relationship i refer to here.)
Agree on point 1. Now even tiny websites that wouldn't be a target for anyone are hiding behind Cloudfare.
If you are so worried about people sending requests to your website then take it offline, that will get you 100% success preventing bots
I'm so tired of having to do Captchas and waiting everywhere to access websites
As someone who hosts a few “tiny websites” that are “hiding behind Cloudflare”, it’s because of some incredibly misbehaved botnet traffic that’s otherwise persistently scraping via residential proxies.
This is a hobby for me. It’s for my enjoyment and it allows me to provide resources that others enjoy using. However, I’m not going to allow literally 99%+ of requests to be aggressive scrapers that won’t give up until you’ve got a heavy-handed solution in place.
I hate it too, but the alternative is even more consolidation, so unfortunately this is just the reality right now and you’ll have to get over it until when/if things improve.
> I hate it too, but the alternative is even more consolidation, so unfortunately this is just the reality right now and you’ll have to get over it until when/if things improve.
No, the actual alternative is learning to do it yourself. Unless you're a frequent target of UDP DDoS, there is almost nothing you can't defend against straight from the server itself.
Spending time learning how to configure your firewall, set rate limits in your web server, tune your application for caching and further rate limits, and should all this fail install a self-hosted captcha/proof-of-work fence yourself, is definitely a fair amount of efforts when those things aren't part of the core hobby.
Sorry, this just isn’t true. Some clients just don’t have the resources to pay for a dev playing whack-a-mole against residential proxy bots that are basically indistinguishable from legit users, but en masse can take down a VPS.
Rate limiting doesn’t work when individual IPs are only making a handful of requests.
So that’s why we’re using CF/Fastly. Too bad, I’d prefer not to, but there is just not an alternative at this point.
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.
Great. Next can cloudflare stop providing Https to the user (giving the impression of security) when the connection back to the origin isn't strict HTTPS and is often plaintext?
It is more secure (though not end-to-end secure, of course) from the PoV of most threat models because the monitoring most are most concerned about is at their side of the connection (“local infra (often wireless) -> through ISP -> …” or “local -> through ISP -> through state/org level monitoring -> …”).
Tracking you by monitoring the network traffic between CF (or other connection aggregator) and the origins is possible, but usually significantly more effort. Those with reason to be concerned about true end-to-end encryption will know that seeing any CF artefacts means they need to investigate to know if they are getting e2ee or just end-to-proxy.
At a minimum I'd like cloudflare to mark such traffic in some way, and browsers to put a little cross through the "Https" indicator to show the traffic is passing unencrypted across the internet.
That is not a small “minimum”. There are places in the certificate format that a new flag can go, but then all browsers and apps that perform https requests need to be altered to display this in a manner that is:
• consistent • not overly serious, so users who end up trained to ignore this new signal don't automatically ignore more significant warnings • (and this is the fun part) communicate this new semaphore signal to the general public without confusing them…
To head off one cynical question: “Why worry about the general public when they wouldn't care anyway and just click through warnings with wreckless abandon already?” - if not the general public then who would this be for? Those who might need to care are already checking if their data is going through CF and so might not to under true E2EE.
They can just add an http header that browsers and browser plugins can listen for, they already add `cf-cache-status: HIT`, so they could add this too:
or if you want it to match their own terminology[0], it could be: [0]: https://developers.cloudflare.com/ssl/origin-configuration/s...Genuine question: why wouldn’t they have been doing this already? It feels like obvious low-hanging fruit on a critical path, so I presume there’s something more to it than I’m imagining.
Speculation, no insider info: Its one more thing that needs to be sent out to all their proxies, and could be a reason for meaningfully different metrics whenever the (non-time-critical) regular updates fail. The more configuration/state each proxy receives and processes, the more difficult it will be to determine what is wrong when one exhibits abnormal behavior. At least one of the serious outages was even directly attributed to having accidentally exceeded some hard limit (very hard actually, a rust panic) in how much data could be distributed through one particular such channel, see https://blog.cloudflare.com/18-november-2025-outage/
Ever since http2 and especially http3 (my god did that take years to reach the mainstream), I've been sad to see intermediaries like Cloudflare gobbling up all the newest protocols and ciphersuites and etc while open source lags behind. The separation has reached years, there's years between new security measures implemented by Cloudflare and when it'll be available to independent server operators. It is getting progressively harder to stay current because you are fighting against an entity with vastly more resources and with far more of an incentive to remain the easiest way to get there. With Cloudflare you get all the latest http server protocols and versions, all the latest everything ciphers TLS everything, and all in exchange for letting them MitM your traffic. I've leaned on them myself too because there is just no way to get that stuff for myself these days. h2o was the only readily available http3 software for years.
I'm curious how Cloudflare keeps the learned key exchange preference accurate when a hostname is backed by multiple origins with different TLS configurations?
[flagged]
Cloudflare is the canonical example of why you can't vibe-code infrastructure. Knowing that this optimization was even necessary, let-alone having the ability to build it, is something that doesn't become apparent until you're operating at considerable scale. Once there, of course if you're Cloudflare, you use coding agents to build it. But outside of these temples of scale, good luck even knowing it was needed.
If you work at a SaaS of any kind, I think it's worthwhile considering what things will look like when scale is the only thing that is really defensible anymore.
The irony is that everything about this speaks to vibe coding. The writeup was written by Claude, in a good way (E.g "while the milliseconds are important, that second part may matter more").
I think things like this are now possible through vibecoding.
I like to think that the coding agents has basically raised the bar.
Those who are above the bar can steer and add their expertise to hit a new level.
Brother, if you think Cloudflare isn't vibe coding features...
That's not what I'm saying at all. I guarantee Cloudflare engineers are using coding agents every day for everything they do. The point is that discovering what you need to build comes only with the experience of operating at tremendous scale. I do not believe that someone could replicate what Cloudflare offers today just because they, say, have invested $20K/mo for 100x Claude Max plans, all of which are cranking 24x7.
This is the SaaS advantage you can still have in an AI era. You can beat your competition by being exposed to more of the real world than them. For example, anyone can vibe code an accounting app, but no matter how good AIs get no vibe-coded AI app can have a track record of what happens in an complaince audit and whether it stood up during a tax audit from some particular jurisdiction. The real world will always be more complicated than an AI can vibe code a solution to, if for no other reason that as we advance in AI, the amount of stuff an AI needs to deal with is going to increase from everyone else doing AI stuff too.
nothing stops you from simulating load. something that scales, by definition, it will have something in the small that is more or less identical to something in the large. it goes both ways.
the obstacle was always the parade of tedious obstacles to create (in this case) a sophisticated virtual harness to simulate (in this case) whatever the hell this article is about. so yeah, actually, the capability of retail coding plans are kind of the only thing that matters...
To even simulate the kind of load Cloudflare gets, you already need to be Cloudflare.
For content delivery you can simulate the load one PoP would get. You don't need to be at Cloudflare scale to build a testbench with 800G+ of traffic at different pps.
If it's so easy, why hasn't the next Cloudflare-destroyer shown up yet? Anyone?
It's a capital heavy investment in an already crowded marketplace (there are many CDN companies well predating Cloudflare) with little guarantee of return on investment. Who are you expecting to show up? If you want alternatives, there are plenty, for specific products/features.
There's more to building a successful CDN business than running workloads in a testing environment.
2 things comes to my mind reading this article:
1) So they saved 15ms on the connection so that you can then wait 20s in their annoying nag screen before reaching the real website content.
2) On the Monday they complain about the load on server by LLM scrapings compulsively your webserver an offer themselves as the internet guardian solution; and on Tuesday, they compulsively send useless requests to your servers so that they can save a few microseconds in the very first connection ever to your server. "For each TLS 1.3 capable origin, we run a series of a few lightweight TLS handshakes, each offering exactly one key agreement group: X25519, P-256, P-384, P-521, or X25519MLKEM768. [...] And because the active scanning happens outside your production traffic path, we confirm that both your origin and the network in between can handle connections with a stronger key agreement before any real traffic depends on it.
>they compulsively send useless requests
Those requests aren't useless; They clearly optimize. What a silly take.
>to your servers
To their customer's servers, right! Most people turn on other CF optimizations like h2/h3 to origin.
2) Perhaps theres a slight difference between thousands of requests per day from untrusted entities and a single TLS handshake per day from a trusted one? (Note i understand you clearly don't trust cloudflare, but the people who sign up for cloudflare do trust them - that's the trust relationship i refer to here.)
Agree on point 1. Now even tiny websites that wouldn't be a target for anyone are hiding behind Cloudfare. If you are so worried about people sending requests to your website then take it offline, that will get you 100% success preventing bots
I'm so tired of having to do Captchas and waiting everywhere to access websites
As someone who hosts a few “tiny websites” that are “hiding behind Cloudflare”, it’s because of some incredibly misbehaved botnet traffic that’s otherwise persistently scraping via residential proxies.
This is a hobby for me. It’s for my enjoyment and it allows me to provide resources that others enjoy using. However, I’m not going to allow literally 99%+ of requests to be aggressive scrapers that won’t give up until you’ve got a heavy-handed solution in place.
I hate it too, but the alternative is even more consolidation, so unfortunately this is just the reality right now and you’ll have to get over it until when/if things improve.
> I hate it too, but the alternative is even more consolidation, so unfortunately this is just the reality right now and you’ll have to get over it until when/if things improve.
No, the actual alternative is learning to do it yourself. Unless you're a frequent target of UDP DDoS, there is almost nothing you can't defend against straight from the server itself.
Spending time learning how to configure your firewall, set rate limits in your web server, tune your application for caching and further rate limits, and should all this fail install a self-hosted captcha/proof-of-work fence yourself, is definitely a fair amount of efforts when those things aren't part of the core hobby.
Sorry, this just isn’t true. Some clients just don’t have the resources to pay for a dev playing whack-a-mole against residential proxy bots that are basically indistinguishable from legit users, but en masse can take down a VPS.
Rate limiting doesn’t work when individual IPs are only making a handful of requests.
So that’s why we’re using CF/Fastly. Too bad, I’d prefer not to, but there is just not an alternative at this point.
The raw direct connection is very much alive . I put the sketchier stuff on CF because I don’t want my IP (and my identity) to be tarnished.