QUIC Protocol

QUIC (Quick UDP Internet Connections) is a modern transport layer network protocol designed to improve the performance of applications running over the Internet. Developed by Google and standardized by the Internet Engineering Task Force (IETF), QUIC addresses some of the performance and security shortcomings of traditional protocols such as TCP and TLS/SSL. Here's a primer on its key features, benefits, and uses:

Key Features

Multiplexed Connections

Supports multiple streams over a single connection, which helps reduce latency and prevents the "head-of-line blocking" issue that can occur in TCP when packet loss happens.

Built-in Encryption

Incorportes encryption by default with TLS 1.3, ensuring that data is secure from the onset of communication, reducing the number of round trips needed for handshake completion.

Improved Connection Establishment

Aims to reduce connection establishment time. In some cases, it can establish a connection and secure data transfer with zero round-trip time (0-RTT) compared to TCP's 1-RTT plus an additional round-trip for TLS handshake.

Connection Migration

Supports connection mobility, which means it can maintain a connection even if a client's IP address changes, benefiting mobile devices that switch between different networks.

UDP-Based

Built on top of UDP (User Datagram Protocol), allowing for faster data transmission and easier traversal of NATs (Network Address Translators) and firewalls compared to TCP.

Benefits

Reduced Latency

By minimizing connection and handshake time, QUIC can significantly reduce webpage load times and improve the responsiveness of real-time applications.

Better Performance over Lossy Connections

Its approach to handling packet loss and retransmissions can lead to better performance in unreliable networks, such as mobile networks.

Stream Multiplexing without Head-of-Line Blocking

Prevents a single lost packet from delaying the delivery of all other packets (unlike TCP), improving efficiency and reducing delays.

Uses

Web Browsing

Major web browsers and many websites have adopted QUIC to improve browsing speed and security. It is particularly advantageous for services that require fast, secure connections, such as search engines, streaming sites, and online gaming.

Mobile Applications

Apps that require real-time data exchange, such as messaging apps, mobile games, and VoIP services, can benefit from QUIC's reduced latency and connection migration features.

Cloud Services and CDN

Cloud service providers and Content Delivery Networks (CDNs) use QUIC to enhance the delivery speed and reliability of their services, especially for video streaming and large file transfers.

Challenges and Considerations

Some network devices (middleboxes) may not fully support QUIC or may block UDP traffic, which can limit its effectiveness in certain environments.

QUIC's reliance on software-based processing (as opposed to the hardware-accelerated processing available for TCP in some cases) might lead to increased CPU usage on servers.

Its adoption is expected to grow, further enhancing the performance and security of internet communications. Recent research and tool development for QUIC was presented at information security conference BSides Zagreb 2024. Shortly after, a diary entry was published at SANS Internet Storm Center. This entry links to the author Bojan Zdrnja's quicmap tool for scanning for QUIC services. Bojan developed the tool since nmap currently does not support UDP scanning well.

git clone https://github.com/bojanisc/quicmap.git
cd quicmap
python3 -m venv thevenv
source thevenv/bin/activate
pip3 install -r requirements.txt
python3 quicmap.py -h

Microsoft Supports SMB over QUIC

Documentation for SMB over QUIC can be found in Microsoft's docs.

TLS Client Hello Packets in QUIC

Because of how QUIC is built on UDP, it the negotiations of the TLS Handshake are not as obvious when examining QUIC packets in Wireshark. Here are a couple of screenshots just illustrating where the Client Hello details are buried.

quic && tls.handshake.extensions_server_name

After filtering for the correct packet(s), you can then expand the QUIC IETF layer and find the last CRYPTO field. When you expand that, it will reveal all of the same TLS Client Hello handshake details you're used to seeing in the TLS application layer packets.

Examining a QUIC Client Hello

Handshake Protocol: Client Hello

The Client Hello is the first message sent by the client in a TLS handshake. It serves the following purposes:

• Establish initial contact with the server.
• Provide a list of supported cryptographic algorithms and capabilities.
• Allow the server to choose a compatible set of parameters for secure communication.

The TLS Client Hello is a critical message in establishing the protocol version, cipher suites, and extensions supported by the client, which ultimately influences the security properties of the connection.

• Handshake Type: Client Hello (1)
• This is the initial message sent by the client to start a TLS handshake. It includes the supported protocol versions, cipher suites, compression methods, and other parameters to establish secure communication.

Length

• Length: 2035
• This represents the total length of the Client Hello message in bytes.

Version

• Version: TLS 1.2 (0x0303)
• The Client Hello is indicating TLS version 1.2. However, this field is maintained for backward compatibility only, as the supported_versions extension must be used instead to indicate supported TLS versions.

Random

• Random: 3480a7ea3f89da730f2e3043e35dadb2493ff35841112110b42f078c6b9e51dd
• A 32-byte random value used to ensure the freshness of the handshake. It helps prevent replay attacks and is combined with the server's random value to generate keys.

Session ID

• Session ID Length: 0
• This field is used in TLS 1.2 to resume sessions. The Session ID Length is zero, indicating no session resumption is requested.

Cipher Suites

• Cipher Suites Length: 6
• Specifies the length of the Cipher Suites list.
• Cipher Suites (3 suites):
• The client supports three cipher suites:
  • TLS_AES_128_GCM_SHA256 (0x1301): Uses AES-128 encryption in GCM mode with SHA-256 as the hash function.
  • TLS_AES_256_GCM_SHA384 (0x1302): Uses AES-256 encryption in GCM mode with SHA-384 as the hash function.
  • TLS_CHACHA20_POLY1305_SHA256 (0x1303): Uses the ChaCha20 encryption algorithm with Poly1305 for message authentication and SHA-256 as the hash function.

Compression Methods

• Compression Methods Length: 1
• Specifies the length of the Compression Methods list.
• Compression Methods (1 method):
• Compression Method: null (0):
  • Indicates no compression is applied to the data being transmitted.

Extensions

• Extensions Length: 1988
• Indicates the total length of the extensions in the Client Hello message.

Each extension provides additional parameters or capabilities that the client supports or wishes to negotiate during the handshake:

Supported Versions

• Type: supported_versions (43)
• Length: 3
• Supported Version: TLS 1.3 (0x0304)
• Indicates that the client supports TLS 1.3. This is required for the QUIC handshake.

Server Name

• Type: server_name (0)
• Length: 30
• Server Name: chrome.cloudflare-dns.com
• Indicates the domain name the client wishes to connect to. This helps the server present the correct certificate during the handshake.

PSK Key Exchange Modes

• Type: psk_key_exchange_modes (45)
• Length: 2
• PSK Key Exchange Mode: PSK with (EC)DHE key establishment (psk_dhe_ke) (1)
• Specifies the key exchange modes the client supports. psk_dhe_ke indicates that the client can use PSK (Pre-Shared Key) along with Diffie-Hellman key exchange for establishing a secure connection.

QUIC Transport Parameters

This extension is used to configure transport settings for QUIC connections.

• max_udp_payload_size (0x03): Specifies the maximum UDP payload size the client can handle, set to 1472 bytes.
• initial_max_stream_data_uni (0x07): The maximum amount of data a client is willing to receive on a unidirectional stream before needing to send a MAX_STREAM_DATA frame, set to 6291456 bytes.
• initial_max_stream_data_bidi_local (0x05): The maximum data on a bidirectional stream initiated by the client, set to 6291456 bytes.
• initial_max_data (0x04): The maximum data the client is willing to receive across all streams, set to 15728640 bytes.
• max_idle_timeout (0x01): Indicates that the connection should be closed if no packets are received for 30 seconds.

Key Share

• Type: key_share (51)
• Length: 1258
• Contains key exchange information for supported groups. The client includes:
  • Group: X25519Kyber768Draft00: This is a hybrid post-quantum key exchange using a combination of elliptic curve X25519 and Kyber768 algorithms.
  • Group: x25519: A widely-used elliptic curve cryptography group for key exchange.

Signature Algorithms

• Type: signature_algorithms (13)
• Length: 20
• Lists supported signature and hash algorithms. These include combinations like ecdsa_secp256r1_sha256, rsa_pss_rsae_sha256, rsa_pkcs1_sha256, and more.

Supported Groups

• Type: supported_groups (10)
• Length: 10
• Specifies supported elliptic curve groups or finite field groups for key exchange. This includes X25519Kyber768Draft00, x25519, secp256r1, and secp384r1.

Early Data

• Type: early_data (42)
• Length: 0
• Indicates that the client supports sending early data using the 0-RTT feature of TLS 1.3. This allows data to be sent before the handshake completes, reducing latency.

Encrypted Client Hello

• Type: encrypted_client_hello (65037)
• Length: 250
• This extension contains a partially encrypted Client Hello message. It is part of an experimental approach to provide additional privacy by encrypting parts of the handshake.

Application Layer Protocol Negotiation (ALPN)

• Type: application_layer_protocol_negotiation (16)
• Length: 5
• Specifies which application layer protocols the client supports. In this case, h3 (HTTP/3) is indicated as the desired protocol.

Pre-Shared Key (PSK)

• Type: pre_shared_key (41)
• Length: 251
• Contains pre-shared key identities and binders for session resumption or faster handshake establishment using PSK. This is critical for achieving faster connection establishment with previously connected servers.

Handshake Type: Client Hello (1)

Length

The length field defines the size of the entire handshake message, including all extensions. It is used for parsing the message correctly and verifying that the entire message was received.

Version: TLS 1.2 (0x0303)

Even though the version field in the Client Hello is set to TLS 1.2, it’s a placeholder in this context. When supported_versions is included, it supersedes this field to indicate the actual supported protocol versions. This legacy field is used only for backward compatibility with servers that expect it.

Random

The Random field is a 32-byte value generated by the client to ensure the uniqueness and freshness of the session. It helps: - Prevent replay attacks by introducing randomness. - Generate keys during the handshake by combining it with the server's random value.

Session ID

The Session ID field is used for session resumption in earlier versions of TLS (TLS 1.2 and below). If the client wishes to resume a previous session, it includes a non-zero Session ID. Here, the Session ID Length is 0, indicating no session resumption is requested.

Cipher Suites

The Cipher Suites list presents the cryptographic algorithms the client supports. A cipher suite defines a combination of: - Key Exchange Algorithm: Determines how keys are exchanged between client and server. - Symmetric Encryption Algorithm: Encrypts data transmitted between client and server. - Message Authentication Code (MAC): Ensures integrity and authenticity of the message.

The cipher suites offered by the client provide various security properties such as confidentiality, integrity, and forward secrecy. For example: - TLS_AES_128_GCM_SHA256 uses AES-128 encryption in GCM mode for confidentiality, and SHA-256 for message integrity. - TLS_AES_256_GCM_SHA384 offers a higher security level with AES-256 encryption and SHA-384 for integrity.

Compression Methods

This field specifies supported compression methods, but modern TLS implementations do not use compression due to vulnerabilities like CRIME. The only method listed is null, indicating no compression.

Extensions

Extensions provide additional capabilities and settings for the TLS handshake. Each extension has a specific purpose:

1. Supported Versions

2. Indicates the versions of TLS supported by the client, such as TLS 1.3. This extension is critical for negotiating protocol versions and determining compatibility between client and server.

3. Server Name Indication (SNI)

4. The server_name extension allows the client to specify the hostname it is trying to connect to. This is particularly useful when the server hosts multiple domains on the same IP address, allowing it to present the correct certificate for the requested domain.

5. Pre-Shared Key (PSK) Key Exchange Modes

6. Specifies the key exchange modes the client supports using PSK. This extension is crucial for establishing a session quickly without a full handshake, reducing latency and computational load.

7. QUIC Transport Parameters

8. Specifies QUIC-specific parameters for managing the transport layer, such as max_udp_payload_size and initial_max_stream_data. These parameters configure the flow control and data transmission properties for QUIC, enabling the client and server to agree on the behavior of the QUIC connection.

9. Key Share

10. Indicates the key exchange groups supported by the client. This extension allows the client to share key exchange parameters, reducing the number of round-trips required for establishing a secure connection. It includes post-quantum and traditional elliptic curve algorithms for hybrid security.

11. Signature Algorithms

12. Lists the signature algorithms the client supports. This extension helps the server choose a compatible signature algorithm for digital signatures used in the handshake.

13. Supported Groups

14. Specifies supported elliptic curve groups or finite field groups for key exchange. The client lists its preferred groups, such as x25519 and secp256r1, allowing the server to choose one for the handshake.

15. Early Data

16. Indicates the client supports sending 0-RTT (Zero Round Trip Time) early data. This extension is useful for sending data before the handshake completes, reducing latency for specific applications.

17. Encrypted Client Hello (ECH)

18. Provides additional privacy by encrypting parts of the Client Hello. This prevents passive observers from gathering information about supported ciphers and extensions.

19. Application Layer Protocol Negotiation (ALPN)

    • Lists supported application protocols, such as HTTP/3. This allows the client and server to agree on the application protocol to use over the secure connection.

20. Pre-Shared Key (PSK)

    • Contains information about previously established PSKs for session resumption or quicker handshake establishment. PSKs provide a way to reestablish a secure session without repeating the full handshake.

JA4 Fingerprint Components

The JA4 fingerprint is a method used to uniquely identify a QUIC client based on its handshake characteristics. It’s similar to the JA3 fingerprint used for TLS handshakes. The JA4 fingerprint is generated using the following components:

1. QUIC Version: The version of QUIC being used (e.g., q13d corresponds to a specific QUIC draft version).

2. Cipher Suites: A list of supported cipher suites. Each cipher suite is represented by its numeric identifier, separated by hyphens. For example: 4865-4866-4867.

3. Extensions: A list of supported extensions. Each extension is represented by its numeric identifier, separated by hyphens (e.g., 43-0-45-57-27-51-13).

4. Supported Groups: A list of elliptic curve groups or key exchange groups the client supports. Each group is represented by its numeric identifier (e.g., 25497-29-23-24).

The JA4 string is a concatenation of these components, separated by commas, like so:

JA4 Fullstring: [QUIC Version], [Cipher Suites], [Extensions], [Supported Groups]

For example, your packet has the following components: - QUIC Version: q13d0313h3 - Cipher Suites: 1301,1302,1303 - Extensions: 43-0-45-57-27-51-13-10-42-65037-17513-16-41 - Supported Groups: 25497-29-23-24

The JA4 fingerprint is computed using these fields to create a unique identifier that security tools can use to detect and classify QUIC clients.

Decrypting QUIC Payloads with Keys in Wireshark or tshark

In March 2024, SANS Instructor for SEC503 Intrusion Defense In-Depth Instructor Andy Laman provided a talk at the SANS Secure Your Fortress Webcast on the use of Wireshark and tshark for QUIC packet capture analysis.