Java Http3/QUIC implementation security, part 1: QUIC

Support HTTP/3 in the HttpClient

As part of the JEP, we implement:

• RFC 9114: HTTP/3
• RFC 9204: QPACK: Field Compression for HTTP/3
• RFC 8999: Version-Independent Properties of QUIC
• RFC 9000: A UDP-Based Multiplexed and Secure Transport
• RFC 9001: Using TLS to Secure QUIC
• RFC 9002: QUIC Loss Detection and Congestion Control
• RFC 9368: Compatible Version Negotiation for QUIC
• RFC 9369: QUIC Version 2

QUIC is implemented on top of TLS 1.3, defined in RFC 8446. TLS 1.3 support in JSSE was implemented in a prior JEP, and this JEP builds on top of that work.

The goal of the JEP is to implement a working implementation of HTTP/3 in the HttpClient. The QUIC implementation is supposed to be in a reasonably usable state; in particular, optional features and features that are only required by the server might not exist.

QUIC security considerations

This section structure mirrors the formal requirements specified in RFC 9000

21.1.1.1 Anti-Amplification

The QUIC implementation is supposed to limit the number of bytes it sends to an unvalidated address.

- The client only sends stateless reset messages to unvalidated addresses. We make sure that the stateless reset messages are only sent when they are strictly smaller than the incoming datagram.

- The server also sends handshake messages to unvalidated clients. Our server-side implementation does not have anti-amplification limit.

21.1.1.2 Server-Side DoS

In order to filter out forged handshake packets, the server can implement secure token generation, either in a retry packet, or in a new_token frame.

- Our client implementation of new_token and retry is complete

- The tokens generated by our server are not secure and easily forged, offering no protection against DoS.

21.1.1.3 On-Path Handshake Termination

We offer no extra protection against forged initial/retry packets.

21.1.1.4 Parameter Negotiation

No additional requirements

21.1.2 Protected packets

No additional requirements

21.1.3 Connection Migration

The server can offer a preferred address, and the client can choose to migrate to the preferred address or stay on the original one.

The client can switch addresses as a result of a (local) network change or as a result of a (remote) NAT rebinding.

In order to tell apart a real and a spoofed address migration, the QUIC endpoints are supposed to implement path validation. Until the path validation succeeds, the new address is subject to anti-amplification limit.

Our implementation:

- does not perform path validation. The handling of connection migration needs to be reevaluated.

- always sends packets to the same remote address. This is good enough on the client side, but not good enough on the server side.

- selects source address individually for each packet. The client source address might change in the middle of a connection if the routing tables change. This would be reasonable if we implemented path validation.

- optionally filters the source address on the incoming packets. This is good on the client side, but might be counterproductive on the server side.

21.2 Handshake Denial of Service

No additional requirements

21.3 Amplification Attack

Server guidance only. Our server implementation does not offer any guarantees for token validity.

21.4 Optimistic ACK Attack

(optional) We are vulnerable to optimistic ACK attack. We do not detect acknowledgements of non-existent packet numbers other than packet numbers that were not assigned yet.

continued in part 2...