The title of this bug report was cut off somehow. The title should be something like:

Socks4a not being activated. DNS requests leak even if DNS packets blocked.

(No comment was entered for this change.)

(No comment was entered for this change.)

Can confirm with Chrome ver 3.0.195.21.

Using putty as SOCKS proxy with logging all requests already arrive with hostnames 
resolved.

(No comment was entered for this change.)

Duplicate of  Issue 266 .

#266 (Chrome uses Windows' proxy settings) points to #469 (Support SOCKS proxy) 
instead.

https://code.google.com/p/chromium/issues/detail?id=266#c71

Is there any chance of getting this bug some love from the Chrome team?

This is the only bug that stops me from dropping Firefox for all of my personal 
browsing.

It's simply not safe to use Chrome without a VPN or a SOCKS4a/5 proxy (say, an SSH 
tunnel) at this point...

This IS NOT a duplicate of 266 nor 469 (Comment 6 by jon@chromium.org, Oct 22, 2009).

And this is a security flaw!


For some reason I can't fix the tagging...

brett does the duplication makes sense?

I wouldn't mind the DNS pre-fetching if it would simply not leak my private bits all 
over my local (monitoring/censoring/blocking) network.

My use case is that I'm either using Tor, a local ssh tunnel (eg: -D 8888), or an 
HTTP proxy (rarely, only when forced).

In the case of Tor - leaking DNS pretty much ruins using Chrome for anonymity right 
from the start. This issue also makes it very hard to use Tor and Chrome for just 
simple (non secure, non anonymous) circumvention techniques too.

In the case of my local ssh tunnel, I'm using it because my local network is hostile. 
Forged responses to DNS requests (imagine the Defcon as my local network and you're 
close) are not uncommon and because DNS offers zero trust, it's simply easier to 
tunnel with a more reasonably secure protocol.

I haven't yet tried chaining an HTTP proxy into the mix with my ssh tunnels - it 
seems like it won't solve the core issues at hand.

This of course doesn't really speak to the fact that I have to set a system wide 
proxy from the UI. I'd surely love to have a custom proxy field that doesn't make my 
entire system (package updater, etc) use the same proxy as my super fast browser. It 
seems like another process (that isn't Chrome related) will probably cause my proxy 
to lock up from time to time. When there are many processes racing to use it for a 
bunch of tasks at the same time, I suspect there will be trouble...

I have no idea, wtc should know the most about this.

+CC jochen

Also de-duping, this doesn't seem like the same as 266.

Matt: What are you opening this issue about?

From what I can tell, there are two parts here:

(1) Disable DNS prefetching if you are using thor (since it will directly issue DNS).

(2) Use SOCKS v5 instead of 4A  (specify your proxy server as socks5://<host>:port)

from what I talked about with Matt, it is about not doing DNS prefetching when using a proxy. In general, it's 
pointeless when you use a remote proxy, and when you use a local proxy, chances are you're using something 
like privoxy and don't want the dns requests to leak.

jar: could you take a look at this bug?  Please see comments 13-15.

DNS pre-resolution currently resolves hosts in links even if a proxy is present, 
because we believe that up-stream resolvers (commonly shared by the proxy and the 
client) will have their cache warmed, resulting in improved performance for the user. 

If you want to manually block such actions, there is an option to disable DNS pre-
resolution in the options->Under-The-Hood tab in Chromium.  I suspect that may be the  
issue.   In general, there was never a claim or promise made about "leak free" 
performance of DNS resolutions.  We do try to use the local OS resolver (and NOT ask 
an extranet-global-resolver) before the local OS can confirm there is no local 
resolution.  

For now I'm going to mark this as won't-fix, but if I'm missing some critical point 
in my understanding of the problem and issues, please feel free to re-open with a 
clarification.

Thanks,

Jim

When you look at the description at top it says that when local DNS resolution is not 
enabled, Chrome will stop working at all and no sites can be visited.

I tested this with changing DNS server address on my XP to a non-existing one which 
does not refuse connections instantly. This results in dramatic slow-down on web 
browsing but requests start to come to Socks proxy with names no longer solved.

So I propose two ways to solve this issue:

a) (preferred) By default disable DNS local resolution when using proxies.
-- this would be the behaviour people would expect when using a proxy
-- have a configuration option to re-enable local DNS in case it is really needed

b) Chrome will check for local DNS only once per session.
-- once it discovers that there are no local DNS answers, use proxy



Regards,
-- 
Joosep-Georg

This bug thread has been sidetracked, let me try to make the original problem and its 
resolution more clear.

Problem: User wants to use a SOCKS4 proxy server, and select 4A as the specific protocol. 
(in other words, do proxy-side DNS resolution with a SOCKS v4 server).

In Firefox you can do this using the "Network.proxy.socks_remote_dns" option.

However in Chrome with its very spartan network settings, there is nothing equivalent.

Note that in both Chrome and Firefox, the USER is responsible for selecting which version 
of the protocol to use.

Firefox lets you select V4, V5, or V4A. 

Chrome lets you select V4, or V5.
(V4A is only chosen as a fallback to V4 after local DNS resolving fails, and can't be 
explicitly chosen.)

Unless your proxy server does not support V5, the best fix is to use v5 of the protocol 
instead of v4; this will default to doing proxy-side DNS resolutions which is what you 
want.

To do that, specify the proxy as:
  socks5://<host>:<port>

(Or if you are configuring via a PAC script, "SOCKS5 <host>:<port>".)

I'm using Chrome 5.0.375.55 beta on Linux.

I'm happy to confirm that with DNS-Prefetching disabled and explicitly setting
socks5://<host>:<port>, I do not have DNS leaks.

I tested this with a local SSH tunnel (ssh -D 8001 foo@bar.com) and the debugging
messages show that the host name is being resolved on the remote side. Additionally,
I used wireshark to confirm that Chrome isn't leaking DNS at the same time - it
appears to no longer leak in this specific configuration.

Additionally, I found that the work around for my petty gripe regarding the Gnome
network settings is easy enough to fix. Simply launch chrome like so:

 /opt/google/chrome/google-chrome --proxy-server="socks5://127.0.0.1:8001"

The help documentation on this setting is misleading. It specifically states that
this setting is for HTTP/HTTPS:

       --proxy-server=host:port
              Specify the HTTP/HTTPS proxy server.  Overrides any environment
              variables or settings picked via the options dialog.

Perhaps it would be reasonable to rephrase it to something like:

       --proxy-server=[protocol://]host:port
              Specify the HTTP/HTTPS/SOCKS4/SOCKS5 proxy server. 
              Overrides any environment variables or settings picked via
              the options dialog. This defaults to HTTP/HTTPS proxies when
              a protocol is not specified.

Thanks for the help and the all the great work!

ioerror: Thats a very good point. I will update the manpage to explain this, and also 
give some examples (as it isn't obvious at all)

ioerror: Done. Here are the changes I made to the man page: 
http://codereview.chromium.org/2221006/diff/5001/6001

(No comment was entered for this change.)

FYI, the decision Firefox made here was to simply disable DNS prefetch automatically on any proxy that supported DNS resolution, which seems logical to me, especially for HTTP proxies with no notion of resolution.

However, I could also see DNS prefetch actually using the resolution mechanism of SOCKS4A and SOCKS5 instead of DNS, where it is supported (command 'f0'). That probably makes even more sense, because then you are actually priming the DNS cache of whatever DNS server the user is *actually* using, as opposed to just guessing that the local resolver is somehow still involved and even valid. See bugs #46524 and #36845 for cases where users expect their proxy to be the agent actually doing resolution, due to broken local DNS servers.

This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.

(No comment was entered for this change.)

(No comment was entered for this change.)