610896 - socks_remote_dns should default to true if using a SOCKS proxy

Status: RESOLVED DUPLICATE of bug 1741375

(Core :: Networking, defect, P3)

Description

[Jacob Appelbaum]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US) AppleWebKit/534.7 (KHTML, like Gecko) Ubuntu/10.04 Chromium/7.0.517.41 Chrome/7.0.517.41 Safari/534.7
Build Identifier: Mozilla/5.0

I believe that network.proxy.socks_remote_dns should be enabled when using a configured SOCKS proxy. While it is possible for users to dig into about:config, it's rather annoying to expect that said user will know this obscure Firefox detail. This failure mode for Firefox is somewhere between a small privacy failure and a major security issue (allowing for MITM, etc) in most cases. 

This default causes Firefox to fail open; this results in trusting the local network for DNS requests and responses. The user has specifically indicated that they wish to use a remote network, Firefox should fail to use anything except that remote network by way of the configured proxy.

I believe the proper fix is simply to set network.proxy.socks_remote_dns to 'true' in future Firefox builds. Any plugin or user who knows better will be able to disable this; they'd do so at their own risk of course.

Reproducible: Always

Steps to Reproduce:
1. Set a socks proxy
2. Visit important website
3. Leak DNS and trust local network not to forge replies, log queries, etc
4. Surf Onward...
Actual Results:  
I observe DNS leaks rather than remote proxy resolution.

Expected Results:  
I should observe no DNS leaks, my local network should only see connections to my proxy.

If you use an SSH tunnel, it's a perfectly fine SOCKS5 proxy. If you use Firefox and SSH together, you should only see SSH traffic relating to the tunnel when browsing the web with Firefox.

I wanted to check the "Many users could be harmed by this security problem: it should be kept hidden from the public until it is resolved." box but it's not a secret, it's simply a bad default.

It's possible that with an active attacker really bad stuff will happen as a result of this issue.

Comment 1

[Jacob Appelbaum]

I also find it sorta weird that 'proxy' and 'dns' are not valid keywords in the bugzilla system.

Comment 2

[Justin Samuel]

It appears from discussion in bug 134105 that the general consensus going years back was that socks_remote_dns should default to true for SOCKS proxies that support it (i.e. SOCKS4a and SOCKS5). However, according to bug 134105, comment 97, one reason the default was made false was because of bad user experience: "...failed DNS lookups result in no error being reported to the user." 

Up until the time of that comment, nobody in that bug had brought up the privacy and security argument for why socks_remote_dns should default to true. Later, in bug 134105, comment 122, privacy is mentioned.

I think the privacy/security arguments for a change of default far outweigh any UX concerns with the current implementation. If there are UX issues, people are running into them because many users are setting socks_remote_dns to true. The major question to me is whether there are any fundamental bugs that a change of default would trigger. For example, I'm assuming the current implementation is smart enough to know that SOCKS4 proxies can't do remote dns resolution even if socks_remote_dns is true, but I haven't checked that.

Comment 3

[Malcolm Smith]

The problem with SOCKS4a is that it's very difficult to detect.  SOCKS4a is an extension to SOCKS4 which requires sending a bogus IP address with a hostname tacked on to the end of a request.  A SOCKS4 server might just reject the request outright as invalid, or might try to connect to a bogus address.  The failure mode is a connection failure.  An unenlightened SOCKS4 server obviously can't tell a client that it failed due to non-support.  Clients are then left to infer/speculate why the connection may have failed.  And if we speculate wrong, you'd see a SOCKS4a client suddenly downgrade to SOCKS4, recreate all the privacy problems, and no longer be able to talk to the network.

That's the real reason (IMO) that we left this as a pref - if we could detect support reliably and fall back reliably, the option would be redundant.

Personally I would support changing the default, but my reasoning is the scarcity of pure SOCKS4 servers.  Users of those servers would have a bad experience with this change, and would need to know to change it; it's not clear to me this would be obvious to users.  Most SOCKS4 servers that still exist are really SOCKS4a capable now (the SOCKS4a 'spec' is 39 lines long - not hard to implement.)

Comment 4

[maillist-mozilla]

see bug #1015760

it doesn't make sense to set the default to false - why would you use a socks5 proxy when you have a working router in your lan ?
the default setting of "false" only works in very limited scenarios - namely you have a full-fledged internet connection and still want to use a proxy for whatever reason.

a default of setting of "true" on the other hand works for all scenarios.
if the user has configured to use a socks5 server, and the dns or whatever fails on the proxy, it is sufficient to show a generic proxy server failure message.

Comment 5

[maillist-mozilla]

in case you're still not convinced to change the default to true, at least supply a checkbox to turn this on in the proxy configuration dialogue.
i only found out about the setting by reporting a bug here and looking at similar bugreports - you cant expect this from an unsuspecting user.

Comment 7

[Erik]

In my opinion should be the default value for using the name resolution on all capable proxys (all types except SOCKS4) true.

Comment 8

[Sukhbir Singh]

Another vote for setting this to true by default. As others have commented above, the default behaviour should be true by default (preferred), and if not, at least set to true when the proxy is enabled. Is there anything we can do to get this moving?

Comment 9

[Arthur Edelstein [:arthur]]

Attachment: 0001-Bug-610896-Enable-network.proxy.socks_remote_dns-by-.patch

Here's my attempt at a patch that flips the pref to true by default. I also needed to make a small change to a couple of unit tests that were tacitly assuming the pref was false.

Try server results:
https://treeherder.mozilla.org/#/jobs?repo=try&revision=4702bb0c72b1

Comment 10

[Patrick McManus [:mcmanus]]

Comment on attachment 8764758 [details] [diff] [review]
0001-Bug-610896-Enable-network.proxy.socks_remote_dns-by-.patch

Review of attachment 8764758 [details] [diff] [review]:
-----------------------------------------------------------------

I think you need to sort out the socks4 thing from bug 134105, right?

Comment 11

[Arthur Edelstein [:arthur]]

(In reply to Patrick McManus [:mcmanus] from comment #10)
> Comment on attachment 8764758 [details] [diff] [review]
> 0001-Bug-610896-Enable-network.proxy.socks_remote_dns-by-.patch
> 
> Review of attachment 8764758 [details] [diff] [review]:
> -----------------------------------------------------------------
> 
> I think you need to sort out the socks4 thing from bug 134105, right?

Thanks for having a look at this.

As I understand it, the main issue with SOCKS4 is the following:
1. default socks_remote_dns = false means SOCKS4 silently leaks users DNS requests
2. default socks_remote_dns = true means SOCKS4 fails but avoids leaking DNS requests

I would argue that #2 is preferable. I think many users unfamiliar with the fine distinctions between SOCKS versions will be surprised to know that not all connection data passes through their SOCKS4 proxy. The browser should only be leaking DNS requests if the user has given explicit permission.

Unfortunately, I don't believe there is a good way for a SOCKS client to distinguish a SOCKS4 from a SOCKS4a proxy. Otherwise, we could make SOCKS4a/5 always proxy-resolving and SOCKS4 always off.

Is this the SOCKS4 issue in bug 134105 you're referring to? Or do you have a different concern?

Comment 12

[Patrick McManus [:mcmanus]]

I'm not convinced that we should accept a regression for existing socks4 configs over this issue.

We could.. add a > socks4 checkbox and/org PAC identifier.. or maybe some kind of automatic fallback if socks over dns didn't work.. something to avoid a regression.

Comment 13

[mdn]

It seems like socks4 support should really be removed. Here are some things I would say are reasons to remove it:
* No clear specification body to identify when it is deprecated. (socks4 seems to just come out of some paper, afaict there are no w3c/rfc/ietf/other specifying bodies for that particular version of the protocol socks5 has an rfc that can at least be obsoleted if necessary).
* Generally superior, more featureful replacements are available.
* This bug has been open an inordinate amount of time (althought it is a baby compared to bug #134105).
* The UI does not clearly state what the effect of this bug will be.

I believe that the existence of this bug is probably actively harming the privacy of people who may be unable to diagnose when this feature is not working as intended. For those people, failure is not a regression.

Comment 14

[Sukhbir Singh]

(In reply to Patrick McManus [:mcmanus] from comment #12)
> I'm not convinced that we should accept a regression for existing socks4
> configs over this issue.
> 
> We could.. add a > socks4 checkbox and/org PAC identifier.. or maybe some
> kind of automatic fallback if socks over dns didn't work.. something to
> avoid a regression.

Can you explain a bit by what you mean by "> socks4 checkbox"? Also the UI does not seem to have a different checkbox for SOCKS4a, so assuming a user selects SOCKS5 and checks remote DNS, and then later selects SOCKS4, they will be using SOCKS4a. Is that correct?

Also, as comment 13 says, are there enough users to maintain support for SOCKS4? Put differently, is it worth blocking this bug for SOCKS4 support while potentially harming other users?

IMO we should set this pref to true because it's probably safer to fail for a few users rather than leak for most of them.

Comment 15

[Patrick McManus [:mcmanus]]

(In reply to Sukhbir Singh from comment #14)

> 
> Can you explain a bit by what you mean by "> socks4 checkbox"? Also the UI

That is the remote dns checkbox - which I mistakenly forgot was implemented already.

Comment 16

[Patrick McManus [:mcmanus]]

What we need to accomplish to accept a default-remote-dns patch is some mechanism that does not regress existing socks4 installs. I'm not sure what that looks like.

Comment 17

[Arthur Edelstein [:arthur]]

(In reply to Patrick McManus [:mcmanus] from comment #16)
> What we need to accomplish to accept a default-remote-dns patch is some
> mechanism that does not regress existing socks4 installs. I'm not sure what
> that looks like.

Unfortunately, as far as I understand it, there is no simple way to automatically distinguish SOCKS4 servers from SOCKS4a servers. When a SOCKS4a-style connection attempt fails, there are two possibilities:
* the SOCKS server doesn't support SOCKS4a but only supports SOCKS4
* the SOCKS server supports SOCKS4a, but the connection failed for other reasons

So, the simplest solution I see is to enable remote DNS for SOCKS5 by default, but leave the default for SOCKS4 as local DNS.

Here is one way to do that. Suppose we delete the pref "network.proxy.socks_remote_dns" from `all.js`, so its value is, by default, "undefined". Users who had left the "Remote DNS" checkbox unchecked (meaning they had the default socks_remote_dns value) will have their socks_remote_dns value changed from "false" to "undefined".

So after such a patch we would have created three possible values for network.proxy.socks_remote_dns: "undefined", "false" and "true". And there would remain two possible values for network.proxy.socks_version: "4" and "5", where "5" is the default.

Here are the 6 possible states with pre- and post-update values for socks_remote_dns, the value of socks_version, the proposed new behavior for the "SOCKS v4/SOCKS v5" radio buttons and the "Remote DNS" checkbox, and the corresponding DNS mode:

pre-   post-update          socks_version  radio     checkbox     DNS mode
===========================================================================
false  undefined (default)  4              SOCKS v4  unchecked    local
false  undefined (default)  5              SOCKS v5  checked      remote
       false                4              SOCKS v4  unchecked    local
       false                5              SOCKS v5  unchecked    local
true   true                 4              SOCKS v4  checked      remote
true   true                 5              SOCKS v5  checked      remote

Note the interesting behavior of the "Remote DNS" checkbox when socks_remote_dns is undefined. If the "SOCKS v5" radio button is selected (as is the default), then the checkbox displays as checked. If the "SOCSK v4" radio button is then selected instead, then the checkbox becomes magically unchecked.

If the user then toggles the checkbox, either checking it while "SOCKS v4" is selected, or unchecking it while "SOCKS v5" is selected, then we set socks_remote_dns as a user-defined pref with the appropriate true/false value.

(This solution allows for a possible future implementation of a SOCKS4 fallback mechanism, for the socks_remote_dns undefined pref state. In that mechanism, SOCKS4a would be attempted for each connection, and then, provided SOCKS4a has never previously been seen to work during the session, we fallback to SOCKS4. But I think this fallback approach is complicated and we should first do the easy thing and solve the problem for SOCKS5 as described.)

Patrick, Sukhbir-- how do you feel about this approach?

Comment 18

[Masatoshi Kimura [:emk]]

I propose a simpler UI; radio buttons to select SOCKS4, SOCKS4a, or SOCKS5. SOCKS5 will always use remote DNS when it is set from the UI.
If people absolutely requires to disable remote DNS on SOCKS5, they can disable it from about:config.

Comment 19

[Arthur Edelstein [:arthur]]

(In reply to Masatoshi Kimura [:emk] from comment #18)
> I propose a simpler UI; radio buttons to select SOCKS4, SOCKS4a, or SOCKS5.
> SOCKS5 will always use remote DNS when it is set from the UI.
> If people absolutely requires to disable remote DNS on SOCKS5, they can
> disable it from about:config.

I like this idea. So then the prefs and UI would work as follows:

socks_remote_dns
pre-   post-upgrade         socks_version  radio      DNS mode
===============================================================
false  undefined (default)  4              SOCKS v4   local
false  undefined (default)  5              SOCKS v5   remote
       false                4              SOCKS v4   local
       false                5              SOCKS v5   local
true   true                 4              SOCKS v4a  remote
true   true                 5              SOCKS v5   remote

Comment 20

[Sukhbir Singh]

(In reply to Arthur Edelstein from comment #19)
> (In reply to Masatoshi Kimura [:emk] from comment #18)
> > I propose a simpler UI; radio buttons to select SOCKS4, SOCKS4a, or SOCKS5.
> > SOCKS5 will always use remote DNS when it is set from the UI.
> > If people absolutely requires to disable remote DNS on SOCKS5, they can
> > disable it from about:config.
> 
> I like this idea. So then the prefs and UI would work as follows:
> 
> socks_remote_dns
> pre-   post-upgrade         socks_version  radio      DNS mode
> ===============================================================
> false  undefined (default)  4              SOCKS v4   local
> false  undefined (default)  5              SOCKS v5   remote
>        false                4              SOCKS v4   local
>        false                5              SOCKS v5   local
> true   true                 4              SOCKS v4a  remote
> true   true                 5              SOCKS v5   remote

I think this is a good idea as well, because it handles both the issues (SOCKS5 safe defaults and SOCKS4 support.)

Comment 21

[Malcolm Smith]

For what it's worth, I was looking at how other browsers handle SOCKS.  IE supports SOCKS4 only (no 4A) and Chrome supports 4 (no 4A) and 5 (with server side name resolution.)  So it looks like the other approach to solve the issue of not being able to detect 4A support is to not support 4A; then the decision tree gets simpler.

Comment 22

[Arthur Edelstein [:arthur]]

(In reply to Malcolm Smith from comment #21)
> For what it's worth, I was looking at how other browsers handle SOCKS.  IE
> supports SOCKS4 only (no 4A) and Chrome supports 4 (no 4A) and 5 (with
> server side name resolution.)  So it looks like the other approach to solve
> the issue of not being able to detect 4A support is to not support 4A; then
> the decision tree gets simpler.

This is an attractive idea from a simplicity standpoint, but if Firefox drops 4A support altogether then an update will degrade privacy for existing 4A users, right?

Comment 23

[bonjour]

I live in Iran and the internet is heavily censored here. I noticed this Firefox anomaly of failing to work through proxies when other browsers succeeded until I dug in and found about the network.proxy.socks_remote_dns setting which must default to true. Here is how a simple dns lookup works on my side:

$ nslookup 
> bbcpersian.com
Server:		192.168.1.1
Address:	192.168.1.1#53

Non-authoritative answer:
Name:	bbcpersian.com
Address: 10.10.34.34
> server 8.8.8.8
Default server: 8.8.8.8
Address: 8.8.8.8#53
> bbcpersian.com
Server:		8.8.8.8
Address:	8.8.8.8#53

Non-authoritative answer:
Name:	bbcpersian.com
Address: 10.10.34.35
> 

The mysterious 10.10.34.35 is the address of the government captive portal warning users that they are denied access. You see that changing the name server has no effect as requests are tracked by deep packet inspection.

Comment 24

[BugBot [:suhaib / :marco/ :calixte]]

The bug assignee didn't login in Bugzilla in the last 7 months.
:sgalich, could you have a look please?
For more information, please visit auto_nag documentation.

Comment 25

[Sergey Galich [:serg]]

Dragana, can you please take a look?

Comment 26

[BugBot [:suhaib / :marco/ :calixte]]

Clear needinfos that are pending on inactive users.

Inactive users most likely will not respond; if the missing information is essential and cannot be collected another way, the bug maybe should be closed as INCOMPLETE.

For more information, please visit BugBot documentation.