\

Cloudflare AKE cuts origin HelloRetryRequests from 52% to 3.7%

16 points - today at 5:02 PM

Source
  • lucaprata

    today at 5:45 PM

    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.

    • chrismorgan

      today at 5:55 PM

      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.

      • sandeepkd

        today at 6:29 PM

        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

          • today at 6:46 PM

        • greatgib

          today at 6:30 PM

          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.

            • sophacles

              today at 7:09 PM

              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.)