The subject should read "DNS queries not forwarded through SOCKS proxies"

eroman, arindam: could you take a look at this bug?  Thanks.

I have a similar problem here with Chrome 3.0.195.33 on Windows. Unless DNS prefetching 
is disabled, the DNS queries are NOT going through the proxy.

Regardless of whether DNS prefetching is disabled or not, the DNS queries are NOT
going through the proxy. DNS prefetching may add it's own quirks to getting this
working, but right now DNS queries are not forwarded through the proxy when
prefetching is on and they are not forwarded through the proxy when prefetching is off.

I don't know about SOCKS, but if I turn off prefetching in the version I mentioned, 
then DNS requests are getting forwarded through a regular proxy (not SOCKS).

Anyone relying on something like torsocks or sockscap to wrap TCP is going to be
unhappy as well. Chrome's multi-process behavior steps out of the libc libresolv
hooking that is used to SOCKS'ify the application.

as far as I know, the chrome implementation of SOCKS5 is far from complete, in
particular, socks authentication and the UDP layer are NOT implemented. see this link.

http://code.google.com/p/chromium/issues/detail?id=469#c37

DNS query through socks relies on UDP layer (which is why only v5 supports it). 

I confirmed that by default Chrome does client-side DNS resolving when using a SOCKS 
v5, and if that fails, it falls-back to proxy-side DNS resolving.

This policy is not useful when you are using a SOCKS 5 proxy to hide your traffic, since it 
requires you to additionally disable host resolving if you want to be anonymous.

I will change the policy so that for SOCKS v5 Chrome starts by sending DNS through the 
proxy (rather than only falling back to that behavior).

Will this change also be applied to all proxies in Chrome? It's the same issue with
all proxy support, not only  SOCKS.

Labels Update:

Replace Area-BrowserBackend by Area-Internals

Committed in r34903 + r34928.

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=34903 

------------------------------------------------------------------------
r34903 | eroman@chromium.org | 2009-12-17 16:24:37 -0800 (Thu, 17 Dec 2009) | 10 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=34903&r2=34902
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction_unittest.cc?r1=34903&r2=34902
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/socks5_client_socket.cc?r1=34903&r2=34902
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/socks5_client_socket.h?r1=34903&r2=34902
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/socks5_client_socket_unittest.cc?r1=34903&r2=34902
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket_stream/socket_stream.cc?r1=34903&r2=34902

When talking to a SOCKS v5 proxy, default to sending addresses as raw domains rather than IP addresses.

Before, we would default to client-side DNS resolution (sending IP addresses to the proxy) for both v4 and v5. However if you are using a v5 server, it is most likely that you want to do the resolves on the proxy-side. And in fact if you are using a SOCKS 5 proxy to anonymize your browsing, you definitely don't want that as the default policy.

Embedders of the network stack can select the alternate policy by passing a non-NULL Host resolver into SOCKS5ClientSocket.

BUG= 29914 
TEST=HttpNetworkTransactionTest.SOCKS5_HTTP_GET, HttpNetworkTransactionTest.SOCKS5_SSL_GET

Review URL: http://codereview.chromium.org/507033
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=34928 

------------------------------------------------------------------------
r34928 | eroman@chromium.org | 2009-12-17 19:39:21 -0800 (Thu, 17 Dec 2009) | 7 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=34928&r2=34927
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/socks5_client_socket.cc?r1=34928&r2=34927
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/socks5_client_socket.h?r1=34928&r2=34927
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket/socks5_client_socket_unittest.cc?r1=34928&r2=34927
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/socket_stream/socket_stream.cc?r1=34928&r2=34927

Cleanup: Remove the support for IPv4 and IPv6 addressing types in the SOCKS5 implementation.
This is no longer used by chrome, and it is unlikely that embedders would want to use this.
The default will just use the DOMAIN addressing type.

BUG= 29914 

Review URL: http://codereview.chromium.org/507048
------------------------------------------------------------------------

@eroman -- did you have any thoughts on comment #11 from nixmlists? Also, would you 
like to merge this to the 249 branch or would you like me to do it?

@nixmlists, thanks for your observations on the implications. We will merge this to an 
upcoming release.

@scarybeasts, nixmlists. Regarding comment #11, I don't quite understand what it is 
asking. My change was specifically about letting SOCKS 5 proxies do DNS resolution 
for requests proxy-side.
   * SOCKS 4 will continue to do client side (and fall back to proxy side using 4A 
extension)
    * HTTP proxies have always done proxy-side resolution, and that is unchanged
    * SOCKS 5 now do proxy-side resolution  (this is what I changed)
In all cases you should turn off DNS prefetching if you want to avoid making requests 
that don't go through the proxy.

Sure thing.

"In all cases you should turn off DNS prefetching if you want to avoid making
requests that don't go through the proxy."

My concern was the client-side resolution due to DNS prefetching for HTTP proxies.
Could there be at least a big fat warning near the prefetching check box?
Unsuspecting users using proxies with prefetching enabled, and it's on by default ==
big trouble. Imagine those users in China trying to avoid censorship and
imprisonment, etc...

Yes I know Chrome is not recommended for this sort of thing for other privacy
reasons, but stil...

Regarding comment 15:

"Cleanup: Remove the support for IPv4 and IPv6 addressing types in the SOCKS5
implementation. This is no longer used by chrome, and it is unlikely that embedders
would want to use this. The default will just use the DOMAIN addressing type."

Could someone explain what the implications of this change are? Thanks.

Regarding comment 7 @coderman: What are possible work-arounds? Thanks.

@nixmlists: RE comment 18: I recommend filing the DNS prefetching on by default + 
proxies as a separate issue. It sure would be nice to be able to automatically disable 
prefetching in some circumstances, but it is a bit tricky to know what those are.

@nixmlists: RE comment 19: Sure. The second change was simply a cleanup. In 
r34903 (the first change) I make proxy-side resolution the default when using SOCKS 
v5 proxy, which is what this bug is about. But I retain the old behavior (client-side 
resolution with fallback to proxy-side) as a customizable option at the code-level. In 
the cleanup change (r34928) I remove that optional support alltogether, since I don't 
expect we will ever use it, so it is just unnecessary complexity.

@eroman: re comment 21: Until that happens, please add a warning box to Chrome next
to the prefetching check box. Or at least have it documented somwhere. Is it
documented anywhere?

@nixmlists:

It is hard to justify a "big fat warning" that would complicate user experience (or 
understanding of the option) to handle what is seemingly a use case by a very small 
percentage of the user base.  I can appreciate that for a select set of users, this 
use case is a VERY delicate issue.  I would also assume(?) that for that set of "very 
concerned users" that a VERY careful usage pattern is required in order to remain 
safe. I think such warnings should be included in such blogs/directions/wiki pages, 
etc., but probably shouldn't confuse or extend the current Chromium UI.  The "how to 
surf anonymously" direction (with a focused technical adversary) are not IMO a 
feature that Chromium attempts to teach much about directly.

Guys, I'm really need this feature, could anybody tell me when would the fix come to 
the BETA version or stable version? Thanks.

I am waiting for this feature also. Any further step?

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=37191 

------------------------------------------------------------------------
r37191 | eroman@chromium.org | 2010-01-26 16:49:50 -0800 (Tue, 26 Jan 2010) | 15 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/249s/src/net/base/net_error_list.h?r1=37191&r2=37190
   M http://src.chromium.org/viewvc/chrome/branches/249s/src/net/http/http_network_transaction.cc?r1=37191&r2=37190
   M http://src.chromium.org/viewvc/chrome/branches/249s/src/net/http/http_network_transaction_unittest.cc?r1=37191&r2=37190
   M http://src.chromium.org/viewvc/chrome/branches/249s/src/net/proxy/proxy_info.cc?r1=37191&r2=37190
   M http://src.chromium.org/viewvc/chrome/branches/249s/src/net/proxy/proxy_info.h?r1=37191&r2=37190
   M http://src.chromium.org/viewvc/chrome/branches/249s/src/net/proxy/proxy_list.cc?r1=37191&r2=37190
   M http://src.chromium.org/viewvc/chrome/branches/249s/src/net/proxy/proxy_list.h?r1=37191&r2=37190
   M http://src.chromium.org/viewvc/chrome/branches/249s/src/net/proxy/proxy_list_unittest.cc?r1=37191&r2=37190
   M http://src.chromium.org/viewvc/chrome/branches/249s/src/net/proxy/proxy_server.h?r1=37191&r2=37190
   M http://src.chromium.org/viewvc/chrome/branches/249s/src/net/proxy/proxy_service.cc?r1=37191&r2=37190
   M http://src.chromium.org/viewvc/chrome/branches/249s/src/net/proxy/proxy_service.h?r1=37191&r2=37190
   M http://src.chromium.org/viewvc/chrome/branches/249s/src/net/proxy/proxy_service_unittest.cc?r1=37191&r2=37190
   M http://src.chromium.org/viewvc/chrome/branches/249s/src/net/socket/socks5_client_socket.cc?r1=37191&r2=37190
   M http://src.chromium.org/viewvc/chrome/branches/249s/src/net/socket/socks5_client_socket.h?r1=37191&r2=37190
   M http://src.chromium.org/viewvc/chrome/branches/249s/src/net/socket/socks5_client_socket_unittest.cc?r1=37191&r2=37190
   M http://src.chromium.org/viewvc/chrome/branches/249s/src/net/socket_stream/socket_stream.cc?r1=37191&r2=37190

Merge 34903, 34928, 35008, 35549, 36054 to the 249s branch.

This pulls down two proxy changes from head:
(1) Use proxy-side DNS resolution when using SOCKS v5; BUG= 29914 
(2) Remove implicit fallback to DIRECT when using a proxy list; BUG= 12303 

r34903 - main SOCKS v5 DNS change
r34928 - simplification of r34903
r35008 - extra set of unit-tests for SOCKS v5
r35549 - remove fallback to DIRECT for proxies
r36054 - fix a regression from 35549 for single-proxy

BUG= 29914 ,  12303 ,  31983 

Review URL: http://codereview.chromium.org/552164
------------------------------------------------------------------------

The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=37199 

------------------------------------------------------------------------
r37199 | laforge@chromium.org | 2010-01-26 17:18:51 -0800 (Tue, 26 Jan 2010) | 18 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/branches/249/src/net/base/net_error_list.h?r1=37199&r2=37198
   M http://src.chromium.org/viewvc/chrome/branches/249/src/net/http/http_network_transaction.cc?r1=37199&r2=37198
   M http://src.chromium.org/viewvc/chrome/branches/249/src/net/http/http_network_transaction_unittest.cc?r1=37199&r2=37198
   M http://src.chromium.org/viewvc/chrome/branches/249/src/net/proxy/proxy_info.cc?r1=37199&r2=37198
   M http://src.chromium.org/viewvc/chrome/branches/249/src/net/proxy/proxy_info.h?r1=37199&r2=37198
   M http://src.chromium.org/viewvc/chrome/branches/249/src/net/proxy/proxy_list.cc?r1=37199&r2=37198
   M http://src.chromium.org/viewvc/chrome/branches/249/src/net/proxy/proxy_list.h?r1=37199&r2=37198
   M http://src.chromium.org/viewvc/chrome/branches/249/src/net/proxy/proxy_list_unittest.cc?r1=37199&r2=37198
   M http://src.chromium.org/viewvc/chrome/branches/249/src/net/proxy/proxy_server.h?r1=37199&r2=37198
   M http://src.chromium.org/viewvc/chrome/branches/249/src/net/proxy/proxy_service.cc?r1=37199&r2=37198
   M http://src.chromium.org/viewvc/chrome/branches/249/src/net/proxy/proxy_service.h?r1=37199&r2=37198
   M http://src.chromium.org/viewvc/chrome/branches/249/src/net/proxy/proxy_service_unittest.cc?r1=37199&r2=37198
   M http://src.chromium.org/viewvc/chrome/branches/249/src/net/socket/socks5_client_socket.cc?r1=37199&r2=37198
   M http://src.chromium.org/viewvc/chrome/branches/249/src/net/socket/socks5_client_socket.h?r1=37199&r2=37198
   M http://src.chromium.org/viewvc/chrome/branches/249/src/net/socket/socks5_client_socket_unittest.cc?r1=37199&r2=37198
   M http://src.chromium.org/viewvc/chrome/branches/249/src/net/socket_stream/socket_stream.cc?r1=37199&r2=37198

Merge 37191 - Merge 34903, 34928, 35008, 35549, 36054 to the 249s branch.

This pulls down two proxy changes from head:
(1) Use proxyside DNS resolution when using SOCKS v5; BUG= 29914 
(2) Remove implicit fallback to DIRECT when using a proxy list; BUG= 12303 

r34903  main SOCKS v5 DNS change
r34928  simplification of r34903
r35008  extra set of unittests for SOCKS v5
r35549  remove fallback to DIRECT for proxies
r36054  fix a regression from 35549 for singleproxy

BUG= 29914 ,  12303 ,  31983 

Review URL: http://codereview.chromium.org/552164

TBR=eroman@chromium.org
Review URL: http://codereview.chromium.org/556034
------------------------------------------------------------------------

Verified fix in Chrome 4.0.249.86 on Windows Vista.

The verification test involved:
  (1) Edit HOSTS file to map www.google.com to 127.0.0.1
  (2) Start Chrome and verify that http://www.google.com cannot be loaded.
  (3) Restart chrome with the flag --proxy-server=socks5://localhost:1080
  (4) Start up a SOCKS server at localhost:1080 that tunnels to another machine:
    ssh -D 1080 remotehost
  (5) Verify that loading http://www.google.com/ works now.

Fix was in 4.0.249.89.

Hello I am using chrome 5.0.375.29 beta on OSX and I'm afraid this bug still exists.

Can someone please verify the bugfix status on OSX?

Sorry for the previous comment.  I was setting it as socks4 proxy and when I set as socks5 proxy it 
works fine.

Verified fix in Chrome 4.0.249.86 on Windows Vista.

Still broken in 5.0.375.38 beta on Ubuntu 10.04, following the same test as the 
windows vista example above.

The verification test involved:
  (1) Edit HOSTS file to map www.google.com to 127.0.0.1
  (2) Start Chrome and verify that http://www.google.com cannot be loaded.
  (3) Restart chrome with the flag --proxy-server=socks5://localhost:1080
  (4) Start up a SOCKS server at localhost:1080 that tunnels to another machine:
    ssh -D 1080 remotehost
  (5) Verify that loading http://www.google.com/ still fails

@jar[dev]

> It is hard to justify a "big fat warning" that would complicate user experience


Would that be security through obscurity rearing its ugly head?



> or understanding of the option

treat users as microsoft does then?



> a use case by a very small percentage of the user base

Not looking at the problem will not make it go away



> this use case is a VERY delicate issue


Is that your confession of the value of privacy?  the sacrosant value of privacy?


> are not IMO a feature that Chromium attempts to teach much about directly

nor is RLZ, Client-ID, or URL-tracker apparently :|



> "how to surf anonymously"

Would be greatly advanced when your employer stops hiding geoip location issues under 
their respective mat.

geoip location opt-out at the ISP level is essential.  that "feature" in the browser 
ought be up front obvious to the new user.  google itself ought add opt-out to its 
line of web properties

> Still broken in 5.0.375.38 beta on Ubuntu 10.04

Confirmed

Still broken on latest OS X Stable release.

Worked fine for me in chrome 6.0.408.1 both linux and mac.

I'll try to get my hands on a 375 build and see if that is any different...

Tested on 375 on Linux: works fine.

% printf "\x05\x00" | nc -l -p 4545 | hexdump -C
% ./chrome --user-data-dir=/tmp --proxy-server=socks5://127.0.0.1:4545
00000000  05 01 00 05 01 00 03 0e  77 77 77 2e 67 6f 6f 67  |........www.goog|
00000010  6c 65 2e 63 6f 6d 00 50                           |le.com.P|
00000018

I am re-closing this bug, haven't been able to repro any problems.

For those that still can't get it to work on 375 or later, please send me the exact 
commands you are running, and attach the output from about:net-internals (if you are on 
ToT build go to the data tab).

bug still exist, I am able to repro it on google chrome 6.0.472.36. 

to repo bug:

run ssh proxy: ssh -D 8888 server
run chrome with proxy: google-chrome --proxy-server="socks5://localhost:8888"
run tcpdump on internet interface: tcpdump -i eth0 port 53
in chrome go to google.com
tcpdump will show dns trafic

See the threads above. You need to disable things like DNS prefetching otherwise there is other traffic generated by chrome.

I could confirm this bug exists 12.0.742.112

I setup an socks5 proxy, cant see any hostname lookup traffic pass through the proxy (via log)

more on this issue, this mighty caused by the PAC file
if I assign proxy in command line: chrome.exe --proxy-server=socks5://localhost:7070, host lookup is via socks5 proxy
but if I use such pac file:

function FindProxyForURL(url, host) {
	return 'SOCKS5 localhost:7001';
}

don't work

I think this issue should be re-open, what can I do/

Problem exists in latest dev branch release (14.0.835.15). Reproduced using tcpdump like in comment #41.

Same issue here, 15.0.874.15 dev-m

I have just testing this with 15.0.874.106 and tcpdump reports all DNS queries are local.
That includes starting with the --proxy-server set and turning off pre-fetch.

This was tested with Ubuntu 11.10

On Google Chrome 16.0.912.32 (Official Build 108990) beta, I can confirm that Chrome WILL NOT USE the local DNS servers if "Predict network actions to improve page load performance" is unmarked.

using 16.0.912.63 beta, wireshark shows dns queries ARE local even though "Predict network actions to improve page load performance" is unmarked.

I've just switched back to Firefox. They're clearly not taking this seriously.

On 16.0.912.63 beta (64-bit Linux), tcpdump shows DNS queries are not local, if and only if "Predict network actions to improve page load performance" is unmarked. That is, I get the same result as neko.eth0 in comment #51.

I am willing to admin when i am mistaken:
I did further testing and checked chrome://net-internals it listed me using sock4. I was using proxy switchy extension with socks5 option selected which lead me to believe I was using socks5. After disabling the extension and adding the command line switch to the chrome shortcut in windows I can confirm wireshark shows no local DNS queries. (16.0.912.63 beta, windows 32bit)

After some research, I can confirm that the command-line option works correctly in Win7 x64 with 16.0.912.77 but that having the pre-fecth enabled results in DNS queries for the pre-fetches going through local DNS and not SOCKS5. 

I had to turn off "Predict network actions to improve page load performance" for the DNS lookup to not leak. Why is "Predict network actions to improve page load performance" turned off automatically when proxy is set?

Still seems broken because the DNS info will leak when anything other than http/https is used. I assume with some javascript or ad that requests an ftp URL and the DNS will be leaked.

I don't understand why NOT leaking DNS is not a priority with Google. People's jobs and lives can be put at risk for a simple oversight like this ftp leak.

Can we just have one simple option: "funnel all DNS to sock 5"? And make this default  when socks is used?

I agree completely with #57.  This is also a significant issue in several other ways:

 - Speed: when your proxy of choice is much more responsive than your default gateway
 - Robustness: when you know your default infrastructure is unreliable, and you understand how to set up something more reliable
 - Correctness: when your default DNS infrastructure doesn't work or returns invalid results.

This really needs to have SecSeverity-Medium at least.

There is a commonsense: "default or automatic settings" should not override "manual settings".
Obviously, it violate this commonsense.
When a user appointed a DNS source(socksV5) to be use, but it insists a default DNS.
It seems to be smart, stupid indeed.

I am assuming that this is not fixed as it still does not work. what is the timeframe for this to be fixed?

doesnt work... will switch to firefox, until then

I see this problem too.

Version 24.0.1312.56 Ubuntu 10.04 (24.0.1312.56-0ubuntu0.10.04.1)

As far as I can tell, everything works correctly if, and only if, you un-check "Predict network actions to improve page load performance" (see screenshot). I.e., once you uncheck that, your DNS queries go through the SOCKS 5 proxy as expected.

	predict.png 22.3 KB View Download

I appreciate the tip, but that setting is not enabled, and still seeing it use local DNS servers.

And just to avoid other problems: Using Opera on the same system, against the same proxy server does not show this problem.

my chrome browser version is 25.0.1364.97 m. I think it does dns query through socks. here is what I tested.

first, I remove the dns configuration on the local interface(for windows is the TCP/IP configuration panel)and flush the dns cache(in windows by ipconfig /flushdns command). by doing this, my computer can't find dns server to resolve names, now my chrome browser is set to direct connection. and when i type any url in address tab, the browser returns "can't resolve the domain".  it is what I expect.

then, I change the browser setting to use socks5 proxy, and do go to the same url again, and it can reach the domain, which means it did query the dns successfully. and you can see the dns cache shows up by checking the chrome://net-internals/#dns 

my problem is really frustrated, which is, by using socks5, some domains can be reached(such twitter), but some can't(youtube.com, facebook.com). by the way, I am from china mainland, some sites may be blocked by the national firewall, but as I know, the twitter.com is blocked just like the youtube and facebook, but why I can reach the twitter.com but the other two?  anybody has the same problem?

Since there is still confusion on how to configure SOCKS proxy servers, I have written a short tutorial here:

https://sites.google.com/a/chromium.org/dev/developers/design-documents/network-stack/socks-proxy

This explains why local DNS traffic might still be seen, and how to prevent it.

I am closing this bug thread to additional comments, since it has become too much of a catch-all. Please refer to the document first, and for other issues open a new bug report.

Cheers.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot