Looking Into QUIC Packets in your Network
Introduction
QUIC (Quick UDP Internet Connection) is a relatively new protocol gaining popularity by becoming the default choice of the FAANGs for streaming and data transfer over the web. This is a new session layer protocol on top of UDP which has a potential to replace TLS/TCP because it can offer reliability and security while working blazingly fast. Therefore, it is often regarded as a new transport layer protocol in the internet community.
Some of the newer drafts of this protocol have improved security of network traffic packets significantly where the packets have become tamper proof and not easily visible by network equipment. Even basic sniffing on handshake packets have been disabled by different layers of protection.
In this blog we will see how QUIC packets are encrypted to make them tamper proof from the middle boxes.
Quickly Know QUIC
QUIC was initially developed by Google under the name GQUIC. Later adopted in IETF under the name QUIC. Currently both Google and IETF versions of QUIC exist in the internet and both are used by millions of users.
QUIC is a UDP based protocol that serves both transport and session layer function. It improves performance significantly compared to traditional TCP based connections. In the image below it is seen that QUIC replaces the TCP + TLS part of the network.
Fig: QUIC in network stack
The reliable components of TCP like loss recovery, congestion control, connection establishment etc. have been taken care by QUIC, and the security provided by TLS adapted in it.
The connection establishment is improved significantly in QUIC where the TLS handshake establishment and TCP handshake establishment are done by QUIC itself in transport layer saving multiple Round-Trip Times.
Security in QUIC has also been improved by encrypting everything in transport layer and not relying on TCP + TLS to encrypt. This prevents any transparent modification by intermediators and eventually eliminates the attack surface that TCP provides.
What happens behind QUIC connections?
In a typical QUIC connection for the first time, the handshake process happens, but unlike a more conventional TCP+TLS handshake, it requires many fewer round trips making the process faster.
Fig: Handshake process of a typical QUIC connection.
At the very beginning of the connection the client sends an initial packet which includes a TLS 1.3 ClientHello packet. If the enclosed parameters are acceptable for the server, it answers with an Initial packet (including the TLS ServerHello). This message is followed by a Handshake packet including the rest of the TLS server messages (server authentication related information).
Fig: QUIC connection establishment and protected packet flow
The handshake ends with a message from the client. Then, application data can be exchanged using so called 1-RTT packets. The three phases, corresponding to different packet types (Initial, Handshake, 1-RTT) correspond to the three cryptographic epochs used in TLS 1.3 (cleartext messages, protection using Handshake secrets, protection using Traffic secrets). Now in TLS1.3 typically after the hello packets everything is encrypted with forward secrecy.
In almost all the recent versions of QUIC protocol (from GQUIC-Q050) we can observe that even the Initial Hello packets are even encrypted to hide everything from middle boxes. In the next sections we will see how the encryption with publicly available secrets are implemented and how someone can decrypt them to see the initial QUIC packets.
Protecting QUIC Packets
In almost all the recent versions (from GQUIC-Q050) of QUIC the TLS1.3 encrypted packets have been re encrypted with publicly available secrets to make them tamper proof by middle boxes. Every QUIC packet consists of two-part, header and payload (TLS encrypted data with padding). From the QUIC level encryption point of view there are two types of protection happens in every QUIC packet protection and header protection.
Fig: Encryption in QUIC packets
Finally, these two parts are added together to make a complete protected QUIC packet.
Encrypting Packets In QUIC
In this section we will be forming a QUIC Initial header and encrypting payload part of an initial packet. The QUIC packet protection is done with static publicly available keys and handshake keys send with initial packet.
The publicly available keys used are-
Here the initial salt is version specific and, in this example, we will be encrypting for QUIC draft-29.
The header structure of an initial QUIC packet is following.
The connection id can consist either the source ID(SCID) or Destination ID(DCID) or both. The packet number is used in determining the cryptographic nonce for packet encryption. Each endpoint maintains a separate packet number for sending and receiving.
The public flag is a one-byte value and the bits of the public flags are as follows
The first bit indicates the type of header, depending on packet type the header can be short or long. The last two bits indicates packet number length.
The header for initial type of QUIC packet consists of components shown above. Some of the component will be used for encrypting the payload part of the packet.
The unprotected payload of the initial packet is encrypted in the packet protection stage. The unprotected payload is sent as a CRYPTO packet. In the context of this blog we will call the unprotected TLS crypto frame as plaintext.
Fig: QUIC Crypto Frame
At first, we will derive the initial secret which is needed in order to derive other keys. The initial secret is derived from initial salt and connection id (dcid in this case).
The initial secret key is then used in a HKDF function to generate different keys to use in successive stages.
HMAC Based Key derivation Function is a basic and essential component of cryptographic systems. Its goal is to take some source of initial keying material and derive from it one or more cryptographically strong secret keys.
The nonce is generated from the client_iv and packet number. The plaintext is padded to make it a fixed length payload(1162 byte). Finally, the fixed length padded payload is encrypted with AEAD function(aes-128-gcm) in this case.
The fixed length encrypted payload is shown below:
After payload protection comes the header protection. As per the encryption mechanism figure shown before some specific parts of the header is masked with the mask generated from the encrypted payload. The first step of generating the mask is calculating packet number length from the flag byte (The last two bits of the flag byte represent the packet number length). Next step is calculating the sample from the protected packet based on the calculated pn_length. This calculation is valid for initial type of packet, for other type refer to the ietf documentation. And finally, from this sample the mask is calculated with the help of previously calculated hp_key in HKDF stage.
The mask is then applied in multiple part of the header to prevent tampering of the packet. (e.g. replacing dcid bytes, packet number etc.)
Fig: QUIC header protection fields
The figure above shows the fields in an initial type header that are covered by header protection and the portion of the protected packet payload that is sampled.
The header is now masked, one interesting point to remember is that even the fields such as connection ID are not protected but even if we change them the payload protection changes so the header mask changes. That is why it is not possible for middle boxes to replace important bytes of a QUIC packet without decrypting and re-encrypting it (which is computationally costly).
Finally, the masked header and protected packet is added to make a complete protected QUIC packet.
This is the desired application layer bytes which is when sent by transport layer creates a valid QUIC packet which can be decrypted and dissected by Wireshark.
Fig: Encrypted QUIC frame bytes
Fig: Decrypted and dissected QUIC packet.
QUIC in ATI
The researchers at Keysight ATI(Application & Threat Intelligence) have performed extensive research on different QUIC versions and implemented most of the widely used versions of QUIC. The supported versions of QUIC by Keysight BreakingPoint are:
Fig: QUIC Superflows In Keysight BreakingPoint
BreakingPoint offers highly customizable QUIC traffic to test your network equipment resiliency into the new era of network traffics. The users can change traffic parameters like Connection ID, Packet Number, Server Name Indication (SNI), User Agent and Payload Size (volume of encrypted application traffic) during BreakingPoint System (BPS) simulation.
Fig: Customizable Parameters in QUIC simulations.
For more details about Keysight BreakingPoint and to test your network equipment against the most updated network traffic available in the internet visit BreakingPoint.