The Features of 3.5: QUIC server

This is the first in a series of post about the features of OpenSSL 3.5. Its target audience is people who are curious about internet security, but who don’t recognize the acronyms in that list. This post is about QUIC server.

It can be helpful to think of the internet as a series of agreements about how computers talk to each other. Those agreements are called protocols and they can be mixed and matched according to the purpose of the communication. Protocols can be layered on top of each other with each protocol depending on the layer below and supporting the layer above.

For instance, a really common set of protocols:

1. The Internet Protocol (IP) allows computers to find each other. You might have seen references to IP addresses, which are often displayed as four numbers separated by periods: 127.0.0.1. If you know a computer’s IP address, you can send it a message just as you can send a text to someone if you know their phone number. Many other sorts of devices besides computers can have IP addresses, so we usually use the more general term “node”.
2. The Transmission Control Protocol (TCP) allows two nodes to set up reliable two-way communication. It works a little like a telephone call in that one node can ask for a message to be repeated if it gets garbled somehow.
3. The Transport Layer Security (TLS) (sometimes called by its older name, SSL) makes connections secure and private. It’s a bit like talking in code so that anyone who overhears the conversation will not be able to understand it. This is the protocol that OpenSSL has provided for more than 25 years.
4. The Hypertext Transfer Protocol (HTTP) is a way for one node (the client) to ask another node (the server), for web pages. So when you followed a link to this post, your internet browser (a client) asked our server for that page via HTTP. Because the connection is secured by TLS/SSL, the specific protocol used in this case is called HTTPS where the S stands for Secure.

This particular set of protocols (also known as a protocol stack) is called HTTP/2 and is shown in the middle column of this diagram:

The previous version of the stack was called HTTP 1.1 and, as the diagram indicates, the secure layer provided by TLS/SSL was optional. That made sense for sites that weren’t worried about private data being intercepted. It was handy to have the flexibility of not having to deal with the overhead of verifying the server really was what it claimed to be and encrypting messages. But as more and more people got concerned about privacy and security, more and more sites served their content using the security provided by TLS.

Engineers at Google noticed some inefficiencies in this stack if everyone wanted their data to be secure when sent to and from a server. For instance, the TCP layer includes a series of messages (called a handshake) between the two nodes in order to establish a connection. The TLS layer has a second handshake sequence so that the nodes can agree on the details of the secret code (encryption) they will be using. If you can ensure the TLS handshake will happen, the TCP handshake can be made redundant.

As websites have grown more complicated, they deliver dozens of files including images, videos, and various files to make the page look just like the designer intended. Unfortunately HTTP/2 has a flaw called head-of-line blocking in which a single file can prevent an entire web page from loading. An analogy might be a line of people ordering at a cafe with a strict “first come, first served” policy. If the first person in line orders a hot chocolate and the cafe is out of whipped cream, the entire line needs to wait for the first order to be finished. It would be easy enough to serve coffee, tea and other drinks that don’t need whipped cream, but that’s not something the policy allows for. TCP implements something called the reliable byte stream paradigm, which sounds great until you learn that it’s liable to get stuck just like our fictional cafe line.

So Google invented a new protocol called QUIC. The name was originally intended to stand for Quick UDP Internet Connections, but now is just a series of letters like KFC or IHOP. By the way, UDP stands for User Datagram Protocol which is an alternative to the TCP layer. Instead of making connections like a phone call, UDP is more like a radio station sending out a broadcast signal. If you are tuned to the right station (the server’s IP address) you get the data without a two-way connection. QUIC takes advantage of the broadcast nature of UDP to send many streams of data at once. What’s more, UDP isn’t susceptible to the head-of-line blocking flaw.

QUIC takes over the responsibility of creating a connection from TCP and delegates securing the connection to a TLS library such as OpenSSL. Not only is that a more efficient way to connect two nodes, it also ensures the data is protected from being intercepted in transit. The close connection between QUIC and TLS makes adding the tools needed to create a QUIC server a natural addition to OpenSSL.

If you’d like to dig deeper, please see:

• An introduction to QUIC in OpenSSL in the library documentation which goes into more detail about the benefits of QUIC and provides a high-level overview of how OpenSSL supports the protocol.
• Writing a simple blocking QUIC client is a guide that shows (with code) how to build a simple QUIC client.
• Writing a simple blocking QUIC server is a guide for building a simple QUIC server using the OpenSSL library.
• For a look into the design process of QUIC on OpenSSL, see the quic-design directory in the openssl repository.

The OpenSSL Foundation thanks everyone who contributed to this feature. We’d especially like to thank Hugo Landau, Matt Caswell, Tomáš Mráz, Neil Horman, Sasha Nedvedicky, and Andrew Dinh.

Next time: The external QUIC library interface in OpenSSL 3.5.

HTTP protocol stacks image: https://commons.wikimedia.org/wiki/User_talk:Sedrubal, CC BY-SA 4.0, via Wikimedia Commons