My understanding is that Caddy doesn’t support 0-RTT by design as it would be dangerous to users who don’t understand it. However, it does support HTTP/3 which I believe by default, works with 0-RTT.
If I have a reverse_proxy to a webpage which is potentially vulnerable to possible replay attacks on 0-RTT, wouldn’t having HTTP/3 enabled be a security issue?
I’ve seen references by Caddy on 0-RTT support but I’m unsure if what exactly they mean.
Here, it’s said it would probably not be implemented: (TLS 1.3, not HTTP/3)
12:34AM - 18 Aug 20 UTC
05:24PM - 20 Aug 20 UTC
Unclear if this belongs as a request to Caddy or one of it's packages. Possibly
But then I see references to 0-RTT in QUIC on Caddy’s recent changelogs:
We're pleased to present Caddy 2.7, which makes significant strides in areas of scaling, performance, and niche features.
Special thank-you to @francislavoie, @mohammed90, and other core team membe...
Is QUIC’s 0-RTT implementation not vulnerable to this? I’m very confused about the entire thing. I do NOT want to have to disable HTTP/3 to get rid of possible 0-RTT attacks, but if this is the case then I will end up having to do it.
Welcome Lucas! Good question.
This issue has the most recent discussion about this, as of last week, including Marten’s opinion (the author of our HTTP/3 lib):
10:05AM - 16 Aug 23 UTC
02:49PM - 16 Aug 23 UTC
Release 2.7.3 highlights
- Significant HTTP/3 performance improvements (upst
If there is a vulnerability there, it is orthogonal to the web server and likely more of an application concern. (Replay attacks are not unique to 0-RTT.)