Sophos Cloud Optix
Google’s campaign to nudge the web towards faster performance took a big step last month. Key personnel at the Internet Engineering Task Force (IETF) suggested basing the next version of a core protocol on technology that originated with the search giant.
The IETF is responsible for signing off many of the key standards underpinning the internet and the web. One of them is the hypertext transport protocol (HTTP), which is how browsers fetch web pages.
In 2013, Google introduced a new experimental protocol called Quick UDP Internet Connections (QUIC), that would make HTTP requests faster and more secure.
Google proposed the idea of running HTTP requests using QUIC in 2016. The IETF evolved the protocol, producing what amounts to its own version (sometimes called iQUIC, in contrast to Google’s gQUIC).
The IETF has been working on running HTTP over QUIC for a while. On 18 October, Mark Nottingham, chair of the HTTP and QUIC working groups, suggested that it was time to call that specification HTTP/3. This would, effectively, make it the next major version of HTTP, and it represents a significant change.
A QUIC-ker internet
QUIC seeks to make network connections faster by reducing the number of round trips that one computer has to make when downloading information from another over HTTP.
Round trips happen in HTTP requests because the client (typically the browser) has to establish a connection with the server. Think of it like asking a new work colleague for something. First, you have to introduce yourself, explaining who you are and what you do. Then you have to wait for them to greet you back and acknowledge you before you make your request. Later, after getting to know them, you could just pop your head round the door and say “hey, Derek, can I borrow that file?” And Derek would just hand it over because he knows you and trusts you. QUIC works the same way.
The protocol has some other tricks up its sleeve. One of them, drawing on earlier work in HTTP/2, uses multiple connections at once. It also estimates the bandwidth that connections will use in either direction in advance, to try and minimize congestion by spacing packet transmissions accordingly, and uses error correction to minimize retransmitting lost data.
QUIC also uses version 1.3 of the encryption and certification standard TLS, which became an official “proposed standard” of the IETF in August 2018.
Unlike HTTP/2, TLS 1.3 isn’t optional though. If you want the extra speed of HTTP/3 you’ll have to sign-up to the extra privacy and security of TLS 1.3 too.
One big step that Google took when designing QUIC was to abandon the core network mechanism for transporting traffic, known as the Transmission Control Protocol (TCP). This has been a staple for internet communications since the mid-1970s and has underpinned the web since its beginning. Instead, QUIC switched to the alternative User Datagram Protocol (UDP), which was designed for low latency communications. Effectively, UDP just concentrates on sending packets, avoiding the extra functions that TCP offers such as re-sending lost packets and reassembling packets in the correct sequence. This makes it faster.
The wish to move to UDP is the reason that Google didn’t continue with SPDY, an earlier protocol that it also proposed. This was a TCP-based protocol, also designed to make HTTP transmissions faster. This forms the basis for HTTP/2, ratified in 2015, but Google pulled support for it the same year after deprecating it.
Google estimates that traditional TCP-based HTTP requests take about 100ms because the client has to establish a connection with the server before it asks for anything. This gets worse when using TCP and TLS for extra security, taking up to 300ms. On a QUIC connection, it will initially take the same time as a TCP connection. When the client has spoken to the server before, it will take 0ms, because there will be no round trip. The server already knows who the client is, so there’s no need for an introduction.
The IETF draft for HTTP over QUIC was published on 24 October. Ratifying it will take time. If and when it happens, the whole world won’t suddenly move over to HTTP/3. However, those websites that do will be able to serve requests to compliant browsers more quickly and securely.
Looks like I will have to read up more on this, as UDP does not have the built in congestion avoidance that TCP does…
Given that we are actively blocking QUIC on our XG because Sophos says it’ll bypass scanning , will the XG line have a method for dealing with this traffic in the future?
I wish I could give you a certain answer about what we (by “we” I mean the whole community, not just Sophos)! will end up doing with QUIC. But it’s a bit early to know exactly how it will end up – or whether it will get global adoption at all.
After all, a few years ago, we were all wondering what “IT effects” Google’s much vaunted HTTP/2 would have…
…and yet that didn’t last and has been supplanted already. For all we know, HTTP/3 might be HTTP/5 by the time it’s settled into a stable form, and could be substantially different from what it is now.
Which is a long way of saying, “Security is a journey, not a destination…”
So Google made an “experimental protocol called Quick UDP Internet Connections (QUIC), that would make HTTP requests faster and more secure”.
What next? Facebook, cloudfare, WordPress…?
And the words “sign up for extra privacy and security” make me shudder.
Sounds like a Two Tier internet to me.
Have I missed something?
It would only be a two-tier Internet in the same way that, say, people using HTTP/2 vs people using HTTP/3 create a two-tier Internet. Everyone has access to it, and some will choose to use it, and some won’t.
If you’re worried about the fact that a private company inspired the protocol, then there are two things to remember. First, iQUIC effectively took over from gQUIC as the community moulded Google’s original proposal for its own purposes. Second, private companies are actively involved in all kinds of standards work, ranging from WiFi specifications to most protocols underpinning the modern web.
When it comes a two-tier Internet I’m far more worried about the subversion of public spaces by private ones, and the control of vast amounts of Internet infrastructure by private companies.
Thanks for the clarification!!
No, you’re not missing anything. It’s shady af.
I am confused how UDP maintains security with HTTPS
Shamelessly reposted from a comment thread on Ars Technica (User yokem55)
I’m going to tell you a UDP joke. I don’t care if you get it or not.
TCP Joke:
A: Hi, i’d like to tell you a TCP joke.
B: Okay, i’d like to hear your TCP joke.
A: Sure, are ready to hear my TCP joke?
B: Yes, I am ready to hear your TCP joke.
A: Okay, I’m going to start telling you my TCP joke. My TCP joke is 100000 Bytes long. How my much of my joke to you want to hear at once?
B: Start small and I’ll let you know if I got it, If i don’t get it, back off and break it into smaller chunks.
You’re amazing
OK, that was the funny! Now I want to send some ads…
Okay so would this involve some form of fingerprinting your device, inorder for the server to sucesfully recall and validate the clients ID as that seems like a standard Google practice… I’ll “wait” the 300ms instead.
@Danny Bradbury, would you happen to know of an in-depth exploration of the “client tracking” aspects of this mechanism?
From a privacy standpoint, what remains unclear to me is the “Connection ID” header field. What added value does this bring, for which purpose is it implemented, and how could it (potentially) be abused?
https://tools.ietf.org/html/draft-ietf-quic-transport-11#section-4.7
Does that mean that if I, say, switch from 4G to WiFi, or from the IP address of my home router to a random IP the destination server will still be able to figure out that it is my client connecting to it (akin to a sort of transport-level cookie)?
How, how long, and where would such a gigantic pool of Connection IDs be kept, and how could it be post-processed for surveillance or marketing purposes?
Many thanks for the quality of the blog posts by the way!