0:03My name is Alex Krivet. I'm a product manager here at Cloudflare. I'm joined today by Suleiman Ahmed. He's a senior research engineer. We're going to talk to you today about securing internet traffic for the quantum computing environment. We're going to talk about how we made a default change that automatically helps you and your origin server talk over post -quantum encryption. So I'm going to start with the problem because maybe that's where product managers usually like to start um so the problem is that uh we're seeing uh sort of an advance towards uh q day everybody here know when i say the word q day what that is some hands some not hands okay so q day represents an attack that's sort of described here um you can have a a client and a site uh today that encryption is is established using a thing called tls math on the internet that protects that connection somebody uh can sit on that wire and they can sort of spy and check what's transiting that wire they can say cool this data that's transiting it is um some financial information they can it's maybe a sale maybe a text message anything um today because of that encryption uh it looks like junk they can't decrypt it this is just a bunch of strings random stuff that i can't actually seen um maybe they can store it for a very very long time um with the hope that in the future this currently kind of theoretical thing a quantum computer will be able

1:36to break that math that encrypts those things and so you can eventually see what that data is you can see uh what's transiting between a client and server q day is the day uh that we think that that quantum will be available to people and that those attacks will come forth. And so current research sort of estimates that Q -Day is maybe around 2030, maybe a little bit before, maybe a little bit after. Everybody has like weird confidence intervals about when this will actually happen. Cloudflare, maybe as you've heard in the keynote, is sprinting towards making everything post -quantum available by 2029. So, as part of this, we're doing a bunch of work, and to sort of talk about some of the work in that background, I'm going to turn it over to Suleiman.

2:32All right. So, yeah, so everything, like, on the internet, as we know, it's... Yeah, sorry about that. So, yeah, everything on the internet is... Most of the connections that we have on the internet are protected by... called TLS. That's how most of our secure communication happen between a client and a server. But even the TLS connections we have on the web are not secure from quantum computers, especially from a cryptographically relevant quantum computer. So to fully understand the risk, let's take a look at the important parts of the TLS connection establishment that relies on math that could be broken by a quantum computer. So the first part is the TLS key agreement.

3:20This is how a TLS client and a server agree on a shared secret without ever sending it publicly across the wire. So if a quantum computer breaks this math, tomorrow all encrypted traffic that is recorded from before that instance or today will become fully readable and this makes this thread quite retroactive. The second part of a TLS handshake is the authentic And this is about digital certificates. A server proves exactly who it says it is. So if a quantum attacker breaks this part, they can impersonate the server. They could technically forge old signatures as well, but forging, for instance, like very old signatures is not really that useful for it as it has its signatures, compared to the data compromise of Taylor's key agreement.

4:12So this is why the industry has been first focusing on prioritizing fixing key given first before so that we can prevent against harvest now and decryptor attacks that Alice has mentioned about. All right. So the fix for TLS key agreement has been here for quite some time already. And it's a new algorithm, a post -consecure algorithm called MLChem, which is a letter space algorithm. that countercomputers cannot break. NIST actually officially standardized it in the last August under FIFS-203 standard. In TLS, we basically paired MLChem with a classical key agreement algorithm, X2-5109, which we also know as ACDH, and the entire algorithm is also known as XMLChem.

5:08So if an attacker would have to now break both your post-quantum algorithms and your classical algorithms. But there is a catch. And the catch is that with XMLChem, the size of your packets go larger than 1 ,200 bytes. So with just your classical key shares, you have 32 bytes. But now with MLChem added, you go like around 1,200 bytes. And just keep the number in mind because that will be useful for the next slide. that we're talking about. But the good news is the browsers have already eaten most of this cost. For example, Chrome, Firefox, and Apple have already turned this algorithm on by default. And because of that, on Cloudflare Radar, we have been seeing that roughly 70% of all browser traffic is already secure from quantum threats, which you can also see on Cloudflare Radar Live.

6:05So, if the browsers have already solved this problem, then why are we giving this talk? Well, when we use Cloudflare and we proxy our traffic through Cloudflare, there isn't just one connection. There are two. One connection is from your browser to Cloudflare to us, and then the second connection is between Cloudflare to the origin server. So, on the second leg, when talking about the connection of Cloudflare to origin server, server, we are the client. So whatever TLS stack that you're running on your origin server, whether it's OpenSSL, Nginx, or some OLL appliance that's running your web server, we are the one that are initially connecting to that for making that TLS connection. So your origin TLS stack has to support the post -quantum secure algorithm, but it's entirely up to classware to understand when it's appropriate to lead or...

7:01use those quantum-secure algorithms to connect with your origin server. And across millions of different origin server setups, making that choice has to be completely automatic. All right, so initiating that connection safely, like whether Cloudflare can make that connection safely with your origin server, can be hard because the client has to guess. And let me explain why. So in TLS 1.3, the protocol forces the client to make a blind guess about what the server supports in its first message. The client commits to a key agreement by sending a key share before the server has said a single word. If we guess right, which is the diagram on the left side, the connection finishes in a single network round trip. So this is the fast route.

7:51If it gets wrong, that's the diagram. on the right side, the server rejects it and sends the hello retry request and the connection doesn't really drop but the thing is that we are now incurring an extra round trip penalty for completing that connection. And as my colleague Alex said, it's like missing a shortcut. I mean, if you have played Mario, you're missing a shortcut here.

8:18All right, so why couldn't we just lead with a post-bundum connection for all origins like let's just like have cluster send the post -condem key share for every origin connection that it makes well as you saw on the last slide if it gets wrong and your origin doesn't support post-condem algorithms we will be incurring an extra round trip so that's a performance penalty but actually a bigger concern has been around connection breakage so remember the large key share sizes of 1200 bytes that we talked about a few minutes ago a classic key share used to perfectly fit inside the 32 bytes in a single network packet. A post -quantum algorithm or key share splits the packet as fragments the client hello into multiple packets.

9:05So the TLS protocol allows your TLS client hello to be on multiple network packets, but because of protocol ossification and a lot of older load balancers and maybe firewalls that assume the TLS packet must be in a single network packet, it might cause some connections to break and your connections will start dropping. We tried to test this out and see how many of these origins are actually in this category of when they see a post-content or a large key share or a client hello with multiple fragments, how many times did they break? Well we found out that around 0 .34 % of our origins at back in 2023 were failing with this. a specific failure of augmented client hello.

9:53But even with the small percentage, we're still talking about thousands and thousands of different origin servers that could drop completely offline if we just led with a post-content connection without doing any sort of measurement. All right, so what we did was we played it safe. At our client side, we just specified support that, hey, I can talk post-content. If you support post-content, do a LOD track. request and connect with me again. This did incur a round -trip latency and even this safe retry mechanism wasn't really perfect because we saw that many origins were even failing to do a hello retry request properly. So they weren't, even if we just said them, hey, we support post -quantum and they tried to retry and use post-quantum secure algorithms, the connection would still break, surprisingly.

10:41Okay. So to summarize the takeaway so far, right? So for years, our default guess for TLS connection has been the classical or traditional algorithm called X2.5.1.1.9. But it created a massive performance tax, roughly 52% of our origin connections to TLS 1.3 capable origins were ended up needing a new try because of it. And we knew that flipping the switch and guessing post quantum first caused like 0.34% of origins to fail, which were mostly from middle boxes dropping the connections entirely. All the while, all the origins that did support post-quantum algorithm, their ratio was growing over the internet from roughly half a percent to around 13% that we saw recently on Cloudflare Radar.

11:35But the problem was that our static initial start of guess for the critical details connection was still the classical tradition. algorithm X2.5.19. So leading with the classical key share penalized the modern servers with extra latency, while leading with post-quantum broke the fragile servers because of their legacy setups. So what did we do? Well, we stopped guessing entirely and we thought it would be better if we started measuring these origins and understand what algorithms do they actually support. So with that, I introduced a new system that we recently built called Automatic Key Exchange. It's a system that we recently built, and there was also a blog post about it that recently went live about it a few months ago.

12:23So instead of risking live user traffic, we run lightweight probes to your origin out of band. We test different key agreement algorithms individually to see exactly what your server and every... box sitting in between or in front of your origin server can actually handle so once we know what your key agreements are either your origin support then we pick the strongest and most secure and most performance option for your origin server then if it's a post post quantum we use post quantum secure algorithms and fall back to the fastest classical algorithm if it does not we roll this out this change out meticulously across our network, we tested on a slice of live traffic, and if we see any rise of connection breakage or any issues in your connections, we instantly roll that change back, and it falls back to the same classical key share that we have.

13:18So the worst case scenario was just an extra round trip, but we make sure that none of your origin-faceted connections are ever broken. We do the scanning daily, and so whenever your origin starts supporting a post... quantum algorithm, Cloudflare will automatically, using the system, upgrade all your origin phase connection to post -quantum secure. All right. So how is the system useful for our customers? Alex, we'll take it from there. All right. Thank you, Zulman. So why this works on Cloudflare and why we're trying to make this easy and on by default. So the first thing is in these connections, sort of as Zulman was saying, that second leg of the TLS connection across Cloudflare is we're the client in that situation. So we can make this change in the AutoCADX system and say like, hey, how about we do this scan out of band, check with the origin, see what's the strongest encryption key and curve that it can support.

14:16And we just do that the next time that a real prod connection comes in. So we can make this single change and we can make everybody more secure by default instead of trying to, you know, have people and keep reminding them, say like, update stuff, update stuff, which is great. As part of the auto SSL TLS pipeline, we're already scanning origins in order to help find the best encryption mode. So this was a very simple change for us because we're just saying, okay, instead of this X25519, let's also add the post-quantum connection so that those can be sort of that first, that preferential connection as well. We watch every rollout. Every rollout, obviously, we don't want to break people.

15:02We're trying to make sure that we're rolling and we're still getting 200s. And if we're not getting 200s, something is going wrong. As we're talking to an origin, we're going to stop that. We're going to revert, and we're going to see and make sure that everything is continuing to work. It's free. It's on on every plan. So there's nothing really to configure. It's in default. So we're trying to make security sort of easy going forward. The big thing is, things that obviously we saw in rolling this out uh was that uh you know across all of the cohorts that we scanned and this was data from maybe a month ago or so uh we increased the post-quantum uh secure connections that we were able to establish to origins from about 25 billion a day uh to 45 billion so almost in doubling which has been fantastic um you know where it's faster we've been able to see that we're able to contact origins uh you know in that single round You know, down from about 52 % of things that needed a retry to 3 .7%, which was fantastic.

16:02So then we saw that to be about 14 times faster, which is fantastic. And on average at P90, that was about 150 milliseconds faster. So customers are happier. Your end users are happier because they're getting content faster because we don't have to do that hello retry every single time.

16:21So the next tab. And maybe half that is of particular interest today is authentication. So one of the things that is scary, obviously, is if somebody is sitting on that wire and saying, hey, I am the origin server. We want to make sure that that is a valid check, that we are not downgrading to classical if an attacker is impersonating an origin or whatever. So being able to force non-classical. downgrades is sort of the next thing that we're thinking about in this situation so as customers and people are updating origins to be post -quantum secure making sure that this attack vector where we fall back to a classical encryption is not available so that that fallback doesn't happen so we are working towards that there are some ways that you can do that already today on Cloudflare with things like tunnels but You know, obviously, we want to make that available across the entirety of the proxy.

17:23So that's sort of our next step here. I'm looking forward to doing that shortly. So some hands-on keyboard things. And I see we have two minutes. Oh, we're so early. We love that. So check your origin. Make sure that, you know, you're available for your origin is updated on post -quantum stuff already. There is a checker on Confler's radar page that you can go. and uh check with so uh that's a great step um auto kex is on should be on for everybody unless you specifically turned it off um leave it on so really nothing to do on that front uh and then finally um you know make sure that your origin is uh uh you know upgraded to use uh post -quantum encryption um and we have a blog uh that specifies all of this in greater detail that came out about a month ago um so make sure to read that um awesome