New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.

Issue 12303 link

Starred by 6 users

Issue metadata

Status: Verified
Owner:
Closed: Jan 2010
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: All
Pri: 3
Type: Bug-Security
M-4

Restricted
  • Only users with EditIssue permission may comment.



Sign in to add a comment

Chrome falls back to DIRECT connections once all proxies have failed.

Project Member Reported by eroman@chromium.org, May 20 2009

Issue description

Chrome has an implicit fallback to DIRECT for proxy lists. This policy is 
different from other browsers (IE and Firefox), which give up rather than 
falling back to direct if it wasn't explicit.

For example, given the proxy list:

"PROXY proxy:6233; PROXY fallbackproxy:6234"

If both of those proxy servers are dead, then IE/Firefox will display an 
error page. Whereas Chrome will try using a direct connection.

So in essense, chrome behaves as if the list were:

"PROXY proxy:6233; PROXY fallbackproxy:6234; DIRECT"

I think it would be best to match this behavior if for nothing else than to 
be consistent/compatible with other browsers.

 

Comment 1 by darin@chromium.org, May 20 2009

Is anyone complaining about this behavior?  My concern is that when switching from 
VPN to no VPN, my proxy config doesn't actually change.  What does change is that I 
am now unable to fetch the PAC URL.  But, our code that detects a changed 
configuration doesn't test the reachability of the PAC URL.  If it did test the 
reachability of the PAC URL, then it would find that the PAC configuration is 
effectively invalid, and it would then be correct to fallback to DIRECT.

So, changing to be strict here is probably not sufficient without also adding code to 
re-fetch or at least test for the reachability of the PAC URL.

Comment 2 by eroman@chromium.org, May 20 2009

> So, changing to be strict here is probably not sufficient without also adding code to 
> re-fetch or at least test for the reachability of the PAC URL.

My proposal wouldn't affect the VPN scenario you just described.
If we fail to configure with PAC would would still fall back to DIRECT.

The change I am describing here is, if we _are_ using PAC, we must respect the proxy list it returns.
So:

function FindProxyForURL(url, host) {
  return "PROXY proxy:6233; PROXY fallbackproxy:6234";
}

Should be functionally different from:

function FindProxyForURL(url, host) {
  return "PROXY proxy:6233; PROXY fallbackproxy:6234; DIRECT";
}

(the first one will not fall back to DIRECT whereas the second one will).

> Is anyone complaining about this behavior?

Not that I know of.

Comment 3 by darin@chromium.org, May 20 2009

> If we fail to configure with PAC would would still fall back to DIRECT.

I meant imagine that while on VPN you succeed in downloading a PAC URL.  But imagine 
also that the proxies listed in the result returned by the PAC script also require 
you to be on VPN.

What will happen if we do not failover to DIRECT is that the user will be unable to 
load pages until they restart the browser or change their proxy configuration to not 
have auto-detect checked.

Comment 4 by eroman@chromium.org, May 20 2009

> What will happen if we do not failover to DIRECT is that the user will be unable to 
> load pages until they restart the browser or change their proxy configuration to 
> not have auto-detect checked.

That case IMO is a logic bug and is covered by < http://crbug.com/12293 >.

When you switch networks we should be re-running the proxy auto-detection. We 
certainly should certainly not be re-using the PAC script from old network since that 
is plain wrong...
Labels: -Pri-2 Pri-3 Mstone-X
Status: Assigned
I'm marking this as a nice to have until someone demonstrates that the current behavior 
affects some users adversely.

I'll leave it to darin and eroman to sort out whether this is actually what we _want_ 
to do.
Sadly, Chrome dump my pac script after a single proxy failure. 

The problem i am experincing here is like this: I specified a local pac file that
will direct connection to Tor. After a proxy failure(for example you forget to start
Tor first). If I bring Tor back online (I confirm Tor works by using another browser
configured to use the same tor as a proxy.). Chome refuse to use the pac file any
more. But attempting to connect to some unknown address. The only solution is to
restart chrome.


Comment 7 by eroman@chromium.org, Oct 19 2009

@zhazhenzhong: Chrome caches failed proxies for 5 minutes. That means after it has failed to connect to the tor 
proxy, it will stop trying for 5 minutes.

Comment 8 by oritm@chromium.org, Dec 17 2009

Labels: -Area-BrowserBackend Area-Internals
Labels Update:

Replace Area-BrowserBackend by Area-Internals

Comment 9 by eroman@chromium.org, Dec 18 2009

Status: Started

Comment 10 by ben...@gmail.com, Dec 18 2009

I'm complaining about this. :-)

As a use case where this behavior does matter:

I use proxy.pac to send personal sites through an SSH SOCKS5 proxy, since I'm on 
unencrypted wifi.  e.g.:

function FindProxyForURL(url, host) {
    var benizi = "SOCKS5 127.0.0.1:23649";
    var direct = "DIRECT";
    if (
        /facebook/i.test(url)
        || /fbcdn/i.test(url)
        || /myspace/i.test(url)
        || /friendster/i.test(url)
        )
        return benizi;
    return direct;
}

I know it's insecure after it reaches the other end of the SSH tunnel, but at least 
I'm avoiding having traffic sent unencrypted over wifi.  When my SSH tunnel fails, 
Chromium happily does that.
@benizi: I agree. That is why I think changing this policy to be like other browsers is 
important, and have already sent out a codereview to do so: 
http://codereview.chromium.org/502068).
Labels: -Mstone-X Mstone-4 SecSeverity-Low
@benizi: thanks :)

We'll pull this change into an upcoming stable release along with the other related 
one. Marking bug as such.
Status: Fixed
committed in r35549.
The following revision refers to this bug:
    http://src.chromium.org/viewvc/chrome?view=rev&revision=35549 

------------------------------------------------------------------------
r35549 | eroman@chromium.org | 2010-01-05 12:09:21 -0800 (Tue, 05 Jan 2010) | 30 lines
Changed paths:
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/base/net_error_list.h?r1=35549&r2=35548
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction.cc?r1=35549&r2=35548
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/http/http_network_transaction_unittest.cc?r1=35549&r2=35548
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_info.cc?r1=35549&r2=35548
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_info.h?r1=35549&r2=35548
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_list.cc?r1=35549&r2=35548
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_list.h?r1=35549&r2=35548
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_list_unittest.cc?r1=35549&r2=35548
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_server.h?r1=35549&r2=35548
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service.cc?r1=35549&r2=35548
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service.h?r1=35549&r2=35548
   M http://src.chromium.org/viewvc/chrome/trunk/src/net/proxy/proxy_service_unittest.cc?r1=35549&r2=35548

Remove the implicit fallback to DIRECT when proxies fail. This better matches other browsers, and simplifies the code.

To better understand what this means, here are some examples how the behaviors will differ for the user:

(1) You start chrome with --proxy-server="foobar:80".
The server "foobar:80" is refusing connections.

  Before: Would fallback to direct after failing to connect through foobar:80.
  Now: Will error-out with connection refused after failing to connect through foobar:80.

(2) You start chrome with --proxy-pac-url="file:///foobar.pac".
The server "foobar:80" is unreachable, and foobar.pac reads:
  function FindProxyForURL(url, host) {
    return "PROXY foobar:80";
  }

  Before: Would fallback to direct after failing to connect through foobar:80.
  Now: Will error-out with connection refused after failing to connect through foobar:80.

(3) You start chrome with --proxy-pac-url="file:///foobar.pac".
The server "foobar:80" is unreachable, and foobar.pac reads:
  function FindProxyForURL(url, host) {
    return "PROXY foobar:80; DIRECT";
  }

  *No change, since the fallback to DIRECT is explicit in the PAC script*

BUG= 12303 

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

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
------------------------------------------------------------------------

Status: Verified
Verified using build 4.0.249.86, on Windows Vista.

Test set-up attached in 12303.zip
12303.zip
1.4 KB Download
Labels: SecImpacts-Stable
Batch update.
Labels: -Type-Bug Type-Security
Project Member

Comment 20 by bugdroid1@chromium.org, Oct 13 2012

Labels: Restrict-AddIssueComment-Commit
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.
Project Member

Comment 21 by bugdroid1@chromium.org, Mar 10 2013

Labels: -Type-Security -Mstone-4 -Area-Internals -SecSeverity-Low -SecImpacts-Stable Security-Impact-Stable Security-Severity-Low M-4 Cr-Internals Type-Bug-Security
Project Member

Comment 22 by bugdroid1@chromium.org, Mar 13 2013

Labels: -Restrict-AddIssueComment-Commit Restrict-AddIssueComment-EditIssue
Project Member

Comment 23 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Severity-Low Security_Severity-Low
Project Member

Comment 24 by bugdroid1@chromium.org, Mar 21 2013

Labels: -Security-Impact-Stable Security_Impact-Stable
Project Member

Comment 25 by sheriffbot@chromium.org, Oct 1 2016

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
Project Member

Comment 26 by sheriffbot@chromium.org, Oct 1 2016

Labels: Restrict-View-SecurityNotify
Project Member

Comment 27 by sheriffbot@chromium.org, Oct 2 2016

Labels: -Restrict-View-SecurityNotify
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
Labels: allpublic

Sign in to add a comment