Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Testing 0-RTT for DoH/3 #385

Open
LeonardWalter opened this issue May 3, 2024 · 8 comments
Open

Testing 0-RTT for DoH/3 #385

LeonardWalter opened this issue May 3, 2024 · 8 comments

Comments

@LeonardWalter
Copy link
Contributor

I want to test the 0-RTT capabilities of the client but in my traffic captures I never see any 0-RTT packets sent out from the client.
My server is a very basic caddy file server and reverse-proxy setup to a Routedns cleartext DNS over HTTP listener.
I'm using the latest caddy version that supports 0-RTT and can see 0-RTT traffic when I connect via Chromium. But not when using the dohclient.

Are there any public DoQ / DoH servers that support 0-RTT and work with this client?

@LeonardWalter
Copy link
Contributor Author

Hi,
I spent some more time testing this and found these instructions for quic-go here on how to enable 0-RTT: https://quic-go.net/docs/http3/client/#using-0-rtt

The TLS session cache was missing.
I opened PR #387, but I did not implement a toggle for 0-RTT. Now it is the default behavior when QUIC/H3 is used, which might be a security concern for some people.
I made some changes to the client code and now 0RTT also works with my caddy server. I was able to confirm it with Wireshark captures.

The following screenshot shows the Wireshark flow graph captured from my caddy reverse proxy. I am capturing traffic from the public and loopback interface.
The traffic was triggered by the routedns dohclient. The graph shows how the DNS query is forwarded to the local DoH resolver after the first QUIC messages.
image

@folbricht
Copy link
Owner

Thanks for looking into this and providing a fix. I do think we may want a toggle in config to turn it on rather than defaulting to it given the potential risks. Most people likely want to turn it on anyway but perhaps not everyone.

@cbuijs
Copy link
Contributor

cbuijs commented May 7, 2024

My 2 cents: I tend to think making it default is okay, running it now close to 24 hours straight without any issues. The whole point of quic was/is 0-rtt? But having a configuration-switch would be cool anyway.

@cbuijs
Copy link
Contributor

cbuijs commented May 7, 2024

BTW, just wondering if the "listeners" need something as well?

@LeonardWalter
Copy link
Contributor Author

Yes, both listeners are missing support for 0-RTT at the moment.
Also, the DoQ client is still not using 0-RTT, it should use some version of DialEarly. (https://quic-go.net/docs/quic/client/#0-rtt)

@LeonardWalter
Copy link
Contributor Author

Just added a new commit to the PR that adds the toggle.
I also updated the examples to include Use0RTT.

Some hours ago I changed the DoQ client to use DialEarly.
I tested both the DoQ client and DoH/3 client with a server that allows 0RTT and can confirm that 0RTT is used for reopening connections.

@cbuijs
Copy link
Contributor

cbuijs commented Jun 24, 2024

Is it me, it seems that that the documentation says to use enable-0rtt = true in the config, but is should be Use0RTT = true?

Documentation examples also use both, in the code it seems to be Use0RTT though.

Seems inconsitent? Both are accepted in the config, but I cannot see the difference when used.

See here in documentation:


# Use0RTT will overwrite the method to GET.

Code:

Use0RTT: r.Use0RTT,

@folbricht
Copy link
Owner

It's definitely enable-0rtt in all configs, Use0RTT is the internal name used in code only. The critical bit is

Use0RTT bool `toml:"enable-0rtt"`
which maps from one to the other.

One of the comments was wrong though and I just fixed that in #400

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants