Hacker News Reader

Comment by keepamovin | Hacker News Reader

Do these amplification attacks also apply to WebRTC and WebTransport?

WebRTC generally goes through a probing process to verify two-way connectivity before sending media.

I not familiar with WebTransport.

My understanding of QUIC was that the handshake was designed so the client would pad their initial datagram such that the response was of similar size, avoiding a small request/large response pattern. And that typical connection establishment did a key exchange on the first round trip; primarily for privacy, but also to confirm two way connectivity. I could be wrong though; especially around resumption and/or connection agility, where a client moves addresses and the session moves with the client.

> WebRTC generally goes through a probing process to verify two-way connectivity before sending media.

To expand on this WebRTC is extremely complex but it certainly has one thing in common with more traditional VoIP systems - the UDP flows for media are negotiated dynamically.

You establish a signaling channel using whatever (WebRTC famously doesn't mandate a signaling protocol). This signaling channel with any authentication, verification, etc you want transports SDP (session description payload) bodies between each party (typically via a web server and websocket/datachannel/HTTP). What you end up with is a set of dynamically negotiated send/receive ports on each side and the application establishes the socket and flow between them with the receiving sockets on each side typically making sure the source IP:port pair matches what was negotiated. The listening socket on each side discards any junk that may show up from an unverified source IP:port pair.

The process you're referencing to is called ICE (Interactive Connectivity Establishment). ICE is very complex but basically what ends up happening is a series of candidates of all potential IPs, source ports, etc are evaluated for bidirectional connectivity between the parties. Once a reliable session candidate is verified the rest of the media session is established using the same source and destination IP:port pairs.

At the risk of getting too into the weeds WebRTC also does UDP port multiplexing so everything related to the session from ICE to the media, datachannel, etc are sent and received on the same socket. This is how you can have relatively high certainty you can establish a bi-directional flow between parties - because you only get this far when ICE has confirmed the IP:port flow on each side can reach the other.

WebTransport requires an established HTTP3 (and therefore QUIC) connection or an established HTTP2 (and therefore TCP) connection, so its vulnerability to reflection attacks corresponds to the vulnerability of the underlying handshakes.

Am curious about QUIC and HTTP3 as well.

QUIC explicitly mentions that it is vulnerable to amplification attacks in the RFC. It suggests sending an extra packet to mitigate, at which point I believe the advantage of QUIC is lost as far as establishing connections is concerned.

I believe you're referring to the stateless retry mechanism? It's designed to be used only when the server is actually under attack (either as an amplification vector or exhaustion of its own connection capacity). The idea is that the server establishes some threshold for pending QUIC connections, and only if that is exceeded does it start requiring clients to complete the extra stateless, SYN-cookie style roundtrip to validate their source address. So it maintains the advantage of one less roundtrip than TCP+TLS unless the server is receiving large amounts of connections that are not progressing in a timely manner.

QUIC requires the initial handshake packets to be at least 1200 bytes, and sets the anti-amplification limit of 3x [0]. This means that the server can typically send up to 3600 bytes in response (unless the client's handshake message exceeds one packet, which usually only happens if there is a post-quantum key share in it). 3600 bytes is usually enough, unless your certificate chain is too large, in which case you'd need to compress it. [1] is a nice overview of the problem.

(full disclosure: I worked on some of this stuff)

[0] https://datatracker.ietf.org/doc/html/rfc9000#name-address-v...

[1] https://www.fastly.com/blog/quic-handshake-tls-compression-c...

Reply on news.ycombinator.com