Securing Internet traffic for the quantum computing era

My name is Alex Krivit. I'm a product manager here at Cloudflare. I'm joined today by Suleman Ahmad. He's a senior research engineer. We're going to talk to you today about securing Internet traffic for the quantum computing. 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. So the problem is that we're seeing sort of an advance towards 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. You can have a client and a site. Today, that encryption is established using a thing called TLS. It's a math on the Internet that protects that connection. Somebody 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 some financial information. It's maybe a sale, maybe a text message, anything. Today, because of that encryption, it looks like junk. They can't decrypt it. This is just a bunch of strings, random stuff that I can't actually see. Maybe they can store it for a very, very long time with the hope that in the future, this currently kind of theoretical thing, a quantum computer will be able to break that math that encrypts those things. And so you can eventually see what that data is. You can see what's transiting between a client and server. Q-Day is the day that we think that that quantum computer 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 Suleman. All right. So, yeah, so everything like on the Internet, as we know, everything on the Internet, most of the connections that we have on the Internet are protected by a protocol called TLS. That's how most of our secure communication happens 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. This is how a TLS client and a server agree on a shared secret without ever sending it publicly across the web. 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 authentication piece. 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 TLS signatures compared to the data compromise of TLS key agreement. All right. So 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 decrypted attacks that Alex 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 quantum secure algorithm called MLChem, which is a letter space algorithm that quantum computers cannot break. NIST actually officially standardized it in the last August under FIPS 203 standard. In TLS, we basically paired MLChem with a classical key agreement algorithm, X25109, which we also know as ACDH. And the entire algorithm is also known as XMLChem. So 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 I'll be 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. All right. So 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, we are the client. So whatever TLS stack that you're running on your origin server, whether it's OpenSSL, Nginx, or some old appliance that's running your web server, we are the one that are 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 Cloudflare to understand when it's appropriate to lead or use post-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, whether Cloudflare can make that connection safely with 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 clients 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. If it gets wrong, that's the diagram on the right side, the server rejects it and sends a 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. If you have played Mario, you're missing a shortcut here. All right. So why couldn't we just lead with a post-quantum connection for all our origins? Let's just have Cloudflare send the post-quantum 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-quantum 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 1,200 bytes that we talked about a few minutes ago? A classical 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 and fragments the client hello into multiple packets. So 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-quantum 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 back in 2003 were failing with this specific failure of augmented client hello. But even with this 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-quantum 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-quantum. If you support post -quantum, do a LOD try 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 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. Okay. 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 X25119. But it created a massive performance tax. Roughly 52% of our origin connections to TLS 1.3 capable origins ended up needing a retry 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 going over the Internet from roughly half a percent to around 13% that we saw recently on Cloudflare Radar. But the problem was that our static initial start of guess for the creating the TLS connection was still the classical traditional algorithm X25119. 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 the 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 like 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 that recently went live about it a few months ago. So instead of risking live user traffic, we run lightweight proofs to your origin out of band. We test different key agreement algorithms individually to see exactly what your server and every middle 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 performant option for your origin server. Then if it supports post-quantum, we use post-quantum secure algorithms and fall back to fastest classical algorithm if it does not. We roll 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. So the worst case scenario was just an extra round trip, but we make sure that none of your origin-based connections are ever broken. We do this scanning daily. So whenever your origin starts supporting a post-quantum algorithm, the software will automatically use the system, upgrade all your origin-based connections to post -quantum secure. All right, so how is this system useful for our customers? Alex will take it from here. All right, thank you, Suleman. 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 Suleman 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 AutoCAD 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, and 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 have people and keep reminding them, say like, update stuff, update stuff, which is great. As part of the AutoSSL 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, like, 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. We're trying to make sure that we're rolling and we're still getting 200s. And if we're stopped, 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 things that obviously we saw in rolling this out was that, you know, across all of the cohorts that we scanned, and this was data from maybe a month ago or so, we increased the post quantum connections that we're able to establish to origins from about $25 billion a day to $45 billion, almost doubling, which has been fantastic. It's faster. We've been able to see that we're able to contact origins in that single round trip, down from about 52% of things that needed a retry to 3.7%, which was fantastic. So 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. So the next half, and maybe half that is of particular interest today, is authentication. So one of the things 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. So 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. 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 Confluence radar page that you can go and check with. So that's a great step. Auto kex is on should be on for everybody unless you specifically turned it off. Leave it on. So really nothing to do on that front. And then finally, you know, make sure that your origin is, you know, upgraded to use post quantum encryption. And we have a blog that specifies all of this in greater detail that came out about a month ago. So make sure to read that. Awesome. Thank you, guys.