We had a probe that checked whether a connection was using post-quantum cryptography. It looked for "Cipher is" in the output. But when the handshake failed, it would print "Cipher is (NONE)." So it reported that github.com and amazon.com were compliant. For weeks.
The success criterion was embedded in the errorline.
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
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.
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.)
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.
We had a probe that checked whether a connection was using post-quantum cryptography. It looked for "Cipher is" in the output. But when the handshake failed, it would print "Cipher is (NONE)." So it reported that github.com and amazon.com were compliant. For weeks.
The success criterion was embedded in the errorline.
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
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.
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.
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.)
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.