3 ms·

No, it hasn’t been solved and it won’t be because it can’t be solved without adding more round trips to the handshake. It’ll be down to firewalls to stop this f

• Aachen 6y ago
  It could use the STK (source address token), which it creates for 0RTT anyway, to identify which sessions to respond to. New sessions from a source IP which shows elevated rates could be dropped X-1/X times (e.g. X=5) because a legitimate client will retry and obtain an STK in, on average, X attempts. This would reduce the amplification factor to below one, assuming the client handshake is <X times smaller than the server handshake (which includes a cert). Firewalls can't block this because then you introduce a denial of service vector. If I can block anyone on the Internet from accessing a service because the service's firewall blocks the source IP... this is why this isn't a solution for dns and other udp protocols' amplification attacks, either. Otherwise we'd block offenders and be done with the problem of amplified DDoS attacks really quickly. The problem is allowing legitimate clients to pass that look (nearly?) identical to what the attacker sends. The STK seems to solve this (in a similar way to TCP, while allowing for 0RTT after the client met the server once), so let's use it? Edit: just noticed you posted another comment critical of QUIC. To be clear, this isn't "QUIC is amazing, let's use this STK and it'll be great". I don't know enough about it for that. Heck, I like the textual property of HTTP/1 and would be fine keeping that as well. I just noticed this security problem with HTTP/3 and would prefer to see it fixed before widespread deployment given how heavily similar services are abused.