Is QUIC too fast for security??
The long-debated QUIC protocol is getting serious attention these days. It has been in development since 2012, but is all the rage now because HTTP/3 (the main reason QUIC was designed in the first place) is now an official standard.
What is it, then, and what might it mean for security? Let's find out.
First, Some Background
Well, actually, first: some name explanation.
What Does QUIC Stand For?
QUIC was an initiative started by google way back in 2012. At that time the protocol was to have a fuller name: Quick UDP Internet Connections. However, the official QUIC standard (as described by the IETF in RFP 9000) has no such designation. One can only assume that at some point someone decided that the backronym was way too cute. Thus, the entire name is QUIC. Why they decided to leave the entire name as QUIC (entirely capitalized), is left as an exercise for the reader.
Ok How About Now Some Background?
Anyway, back to the issue at hand. What is QUIC? Well, in short, QUIC is an effort to improve the speed of the world wide web. This is done with a new HTTP protocol (the HTTP3 part). QUIC takes on a lot of the responsibility previously handled by TCP (primarily guaranteeing packet delivery and managing network congestion), and letting the simpler UDP handle the raw packet transfer.
The image at the top of this page broadly describes the way that QUIC is organized. You will see that HTTP is listed on both sides of the image; in both cases HTTP is not a part of the transport protocol. In researching the topic there is often confusion between HTTP/3 and QUIC. This is because they were developed side by side, and HTTP/3 was always intended to be the first use case for QUIC. However, in the same way that HTTP/2 is not a part of TCP, HTTP/3 is not a part of QUIC.
Why The Change To UDP?
The primary difference between UDP and TCP is speed. TCP is very, very reliable. It was first developed in the 70's, and its goal has always been the guaranteed delivery of packets. This means confirming a good connection (via a TCP handshake), and confirming every packet sent gets to its destination- in the proper order. This is absolutely essential for a downloaded file, for instance. If you have even one packet missing, you will have a corrupted download and will have to begin all over again.
UDP is not concerned about 100% packet delivery. It is only concerned with the speed of packets being sent. Thus, some common uses for UDP in the past have been things such as audio and video streaming. Since the number of packets that come in from, say, Netflix, are so enormous, it makes little difference if some don't get lost. In most cases you won't even notice it as a viewer. Same thing for audio. If you lose some packets on a zoom call, all you have to do is ask the person to "say that again," and everything's great.
QUIC's design goal is to maximize the speed of UDP, while at the same time guaranteeing the packet delivery of TCP.
Does QUIC Perform As Advertised?
Generally speaking, yes. The biggest gains are in the way QUIC handles connection handshakes. Current estimates are that using QUIC could make connections as much as 2-3 times faster. QUIC handles the in-order packet delivery in a much more modern way than TCP did, which in theory allows all streams to process download independently. This also happens entirely in the QUIC layer which means that HTTP3 doesn't need to be involved at all- less players, more efficiency.
Where Do We Stand With QUIC Usage Now?
So first off: You are probably already using it. Cloudflare, CDN extraordinare, made QUIC available as soon as the standard was approved in May of 2021. That first week, they observed 12% of Internet traffic was using QUIC. This is almost certainly because 1) Connections using QUIC only required a UDP connection over port 443 (meaning end users did not have to make any changes), and 2) QUIC was a Google initiative, so of course support for it had been baked natively into Chrome since 2020. Fast forward to today and you will see Cloudflare's Radar tool reporting HTTP/3 numbers hovering between 25% and 30%.
So What Are The Downsides?
The biggest thing going against QUIC is that it is new. The development of the standard was pretty fast, and a lot of the supporting technologies haven't kept up. For one thing, QUIC is not baked into any Operating Systems yet. This means it runs at the userspace level (as opposed to the kernel level). This is less efficient. Also, QUIC requires more computational power on the server side in general. Add this all up and serving pages using HTTP/3 over QUIC means web servers will need 2-3x more CPU power than HTTP2 over TCP. Additionally, there are very few tools built that can help with monitoring and management of HTTP/3 and QUIC- everything is designed for HTTP/2 and TCP.
Security Considerations
While overall the Internet seems pretty enthusiastic about QUIC (who doesn't want faster web pages?), there are also a few concerns floating out there. I believe a lot of them come from the protocol's relative newness. But even so, they are worth discussing.
- The Google Connection
There are also emerging concerns that QUIC will weaken privacy online. A group of Chinese researchers have shown that QUIC makes IP Fingerprinting easier, making it easier to track users around the web. These concerns have been percolating for years (Being a Google-led initiative does not exactly build confidence in the rigorous adherence to privacy for any product), but I imagine we will learn more from researchers, now that QUIC is reaching official status and widespread use.
- Proprietary QUIC Encryption Limits Firewall Visibility
Here we have a big one. Because QUIC also handles encryption on its own, a lot of firewall vendors (Palo Alto being just one example) recommend disabling QUIC entirely- at least until QUIC protections are built into their products. The reason given for this is simple: QUIC is it's own thing. It is delivered via UDP over port 443. Therefore, firewalls cannot see anything except for packets being delivered over UDP 443. For now, this renders Deep Packet Inspection impossible. This lack of visibility means that really rigid enterprise firewall rules cannot be reliably enforced, and products features like Cisco Umbrella Secure Web Gateway cease to work properly.
- Advanced Features Bring Advanced Risks
The QUIC protocol can also be extended in a few ways to make things even faster. One way to do this is with what is called 'early data.' Early data simply means that a data download session can begin as the first step of a connection. Remember: A handshake should take a few steps. The way it usually works is the handshake happens in 2 steps (or "Round Trips") of transmission, then data. Early Data means that the data starts being transmitted immediately- before any round trips are complete. This has the advantage of data loading immediately, but the disadvantage of not securing the session with a completed handshake. This opens you up to the risk of replay attacks, where an attacker could impersonate a valid sender early enough in the session that they could send malicious data. This could mean scripts that would be executed, regardless of whether or not the attacker could actually read any of the data that comes back. If you deploy a payload this way, you have a (difficult but achievable) way in.
It's important to note that Early Data is not new- it was a part of the TLS 1.3 standard. It can be completely disabled by the application developer, or set up so that only 'safe' requests can be executed.
Conclusion
I personally think that there's more smoke than fire at the moment, but the newness of QUIC is a cause for concern. I don't blame vendors and enterprise players for thinking that the best move is to just disable QUIC for now and force people to use the well-understood HTTP/2 over TCP Internet. Losing packet-level visibility seems to mean is that endpoint and application level security are going to become the most important layers, with network level security still being important but it will take a backseat for a time. Same thing for things like early data- it will be increasingly incumbent on the application developers to behave responsibly, and on the endpoint managers to actively protect their property on a device-by-device basis. (XDR, anyone?) This also helps explain why pure network players like Cisco advocate disabling QUIC entirely, while application and loadbalancing focused companies like F5 think that QUIC is inevitable.