What is your domain? We could help you debug it, but you left the Help template mostly empty so we are unable to assist further other than saying “it works for us”
Why do you think that test can’t be trusted? It was recently updated and works with all the latest HTTP/3 deployments. The sslyze tool, on the other hand, hasn’t updated its early data plugin in about 3 years (other than a couple irrelevant changes) but the QUIC protocol drafts have changed a lot in those 3 years. I suspect it’s using an older version of the draft.
HTTP/3 check shows a success for your domain:
Zero Round Trip Time Resumption (0-RTT)
The QUIC handshake for this connection was completed without any additional round-trips.
SUCCESS
Upon further investigation, it appears sslyze doesn’t even support QUIC:
I think sslyze is the tool that can’t be trusted for this. (And that’s saying something, since HTTP/3 Check is developed by a competing web server company.)
If you want to test HTTP/3 yourself, Marten Seeman, the developer of our QUIC library, suggests:
If you actually want to check for 0-RTT support, have a look what Chrome does, and record a qlog to see if 0-RTT packets are sent.
Thank you for the great insight!
The reason I got suspicious was that I found threads on this forum and Github about “not enabling 0-RTT by default” because it could be a security risk.
Now another question would be, how would one go about disabling it if their website has a high-security application? Just to make sure
Edit: I had 2 tests that said it didn’t support it, and 1 that did. So I wasn’t sure what to think of it.
Though, the “0-RTT security concern/risk/vulnerability” stuff has been brought up pretty frequently with Caddy, and it all really roots down to concerns of replay attacks, but that’s something you should be fixing at the application level instead of just disabling 0-RTT at the web server level. Browsers have already been “replaying” POST requests without changing the contents for a long time now with the “resend form on reload” stuff.
