LOAD_BYPASS_PROXY for DNS over HTTPS requests

[Anthony Tseng]

Hi,

When making DNS over HTTPS request, we noticed LOAD_BYPASS_PROXY is needed  for that dns transaction.
And it is been there since the first DoH commit
https://chromium-review.googlesource.com/c/chromium/src/+/710554/40/net/dns/dns_transaction.cc#431
Is there any reasons not to route the DoH traffics though proxy when proxy config is valid?

Because currently DoH will bypass proxy settings and leak the IP or if someone is behind a corporate firewall and has to use socks5 proxy, this will cause DoH requests to fail.

Thanks,

Anthony

[Matt Menke]

At the most basic level, we need to be able to look up the proxy's name via DNS, if it's not using a numeric IP, and OCSP lookups and such for the proxy itself also have to bypass the proxy.  And then there's fetching the PAC script....

https:/crbug.com/910366 has some discussion.  We had initially been planning on sending them through the proxy.

--
You received this message because you are subscribed to the Google Groups "net-dev" group.
To unsubscribe from this group and stop receiving emails from it, send an email to net-dev+u...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/d42b6db9-b7e6-45db-bfb5-b2f4291baa03n%40chromium.org.

[Eric Orth]

It's primarily needed to prevent loops and deadlocks between the proxy code and the DNS code.  The proxy requests themselves and supporting traffic often require DNS queries, making the proxy unusable for many DNS queries.  For most forms of proxies, the proxy itself handles host resolution, so in practice, just about the only stuff going to the Chrome DNS stack while a proxy is active are the resolutions in support of proxy requests that cannot be done via the proxy.

On Wed, Feb 3, 2021 at 2:40 PM 'Anthony Tseng' via net-dev <net...@chromium.org> wrote:

--

[Ryan Sleevi]

On Wed, Feb 3, 2021 at 2:40 PM 'Anthony Tseng' via net-dev <net...@chromium.org> wrote:

Because currently DoH will bypass proxy settings and leak the IP or if someone is behind a corporate firewall and has to use socks5 proxy, this will cause DoH requests to fail.

Eric and Matt have covered the circular dependency issue (and the related bug), but just a note here, since you mentioned "leak the IP". We do not consider proxies as part of the privacy preservation story at present (try saying that three times fast!). While we continue to invest in solutions to reduce the information leakage to network observers, and will continue to do so, the use of "proxy" for privacy is not part of the security or privacy model of the code, and so such side-channels are not considered bugs.

That is, proxies are an access method, to enable access where otherwise the network operator has restricted/prevented things, but they're not a privacy method for when the network operator is monitoring things. For situations of "guaranteed zero leakage", the only appropriate mitigation is whole-OS network encapsulation (i.e. a VM or a physically-separate network device doing encapsulation). I realize that's probably not a very satisfying answer, but it's at least a clear statement about the (current) security/privacy guarantees of proxies and other forms of local device shaping/redirection. 

[Brian Johnson]

In the common case of a proxy through a firewall, the DoH query will be blocked. Since presumably it's possible to do the DNS lookup for the proxy without DoH, it seems like resolution of the proxy hostname should not use DoH at all because you need the proxy to make http requests in the first place.

[Eric Orth]

In the default mode of Chrome DoH (internally in code called AUTOMATIC mode), Chrome silently falls back to Do53 for any query that can't be resolved via DoH.  So in that default mode, the proxy-through-firewall case should work fine.  In the non-default mostly-DoH-only mode (internally called SECURE mode), we considered creating an exception to allow the proxy queries to use Do53, but we decided it was a better reflection of the user intent to not create such an exception.  So it's left up to users/admins to ensure Chrome is not in SECURE mode in the proxy-through-firewall case.  Otherwise, the user will get error messages (that I believe should include messages about changing their Secure DNS settings).

[Brian Johnson]

I guess it depends on a lot of factors like whether regular DNS queries are allowed through the firewall or whether it uses an internal DNS server that is reachable without the proxy and whether or not they are using the "automatic" settings for DoH, but if it's going to fallback to insecure DNS then it seems better to have one query (for the proxy server) use insecure DNS then to potentially have all queries use insecure DNS because the non-proxied https request is blocked.

[Matt Menke]

Of course, as already noted, Chrome doesn't really do DNS lookups when behind a proxy - the proxy does, except in the SOCKS4 case (which doesn't even support IPv6, so isn't exactly a big considaration).  So adding a bunch of complexity and testing in order to send some subset of DNS requests through a proxy using DoH is unlikely to be worth the investment.

To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/net-dev/E56318D8-2BD8-4AB6-A639-225A51249797%40brave.com.

[Brian Johnson]

What about first trying with the proxy and then a fallback to try without it before finally falling back to insecure dns if on “automatic” setting?

On Feb 3, 2021, at 2:00 PM, Brian Johnson <bjoh...@brave.com> wrote:

In the common case of a proxy through a firewall, the DoH query will be blocked. Since presumably it's possible to do the DNS lookup for the proxy without DoH, it seems like resolution of the proxy hostname should not use DoH at all because you need the proxy to make http requests in the first place.

[Eric Orth]

Attempting with the proxy is just not an easy thing to do without special code to more closely track and distinguish DNS requests looping through the proxy code (and that special code is among the stuff we considered not worth the effort for the obscure cases where it ever could succeed).  It's not a matter of the proxied HTTPS requests failing, it's a matter of actual loops and deadlocks in the code.