Last Comment Bug 652928 - manual proxy SOCKS configuration change doesn't have (immediate) effect
: manual proxy SOCKS configuration change doesn't have (immediate) effect
Status: RESOLVED FIXED
:
Product: Core
Classification: Components
Component: Networking (show other bugs)
: 18 Branch
: x86 Windows XP
: -- normal (vote)
: mozilla18
Assigned To: Patrick McManus [:mcmanus]
:
: Patrick McManus [:mcmanus]
Mentors:
: 806193 819851 845772 (view as bug list)
Depends on:
Blocks: 701562 845772
  Show dependency treegraph
 
Reported: 2011-04-26 12:51 PDT by Andrew
Modified: 2013-03-27 11:35 PDT (History)
12 users (show)
See Also:
Crash Signature:
(edit)
QA Whiteboard:
Iteration: ---
Points: ---
Has Regression Range: ---
Has STR: ---
-
wontfix


Attachments
patch 0 (1.36 KB, patch)
2012-09-01 13:05 PDT, Patrick McManus [:mcmanus]
jduell.mcbugs: review+
akeybl: approval‑mozilla‑esr17-
Details | Diff | Splinter Review
Log (36.11 KB, text/plain)
2012-09-11 07:53 PDT, Jerry Baker
no flags Details

Description Andrew 2011-04-26 12:51:06 PDT
User-Agent:       Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0
Build Identifier: Mozilla/5.0 (Windows NT 5.1; rv:2.0) Gecko/20100101 Firefox/4.0

When manual proxy configuration for SOCKS is changed to a different host/port, Firefox continues to use the old setting for some time.

More details:

* if there are some HTTP connections opened using the old setting, FF seems to start using the new configuration only after all of them time out. (It means that if new connections are opened before this happens, they are opened still using the old setting, and FF later waits for them to time out as well. Hence, for more complicated pages loaded (with new connections periodically opened), the change sometimes never takes effect.)

On the other hand, if the old proxy setting is not working, and it was used by trying to load some page, the new setting is actually never applied.

Nevertheless, FF's behavior regarding this is not completely deterministic - the rules above don't apply without exception

* what sometimes helps: some combination of stopping the loading of pages under way / clearing 'Browsing & Download History', 'Cookies', or 'Cache' of 'Clear Recent History'

* what almost always helps: when changing the configuration, switching also SOCKS version to be used. Then the changes are (almost always) respected immediately

* what always helps: restarting Firefox

* what doesn't help: switching to a different proxy setting ('No proxy' etc.) and back (however, those different proxy settings work fine)

* tried also for FF 4.0 on different computer with Windows Vista (32-bit), confirmed

Reproducible: Always

Steps to Reproduce:
1. set up working SOCKS proxy in Configure Proxies to Access the Internet / Manual proxy configuration, confirm, and load some web page revealing the way you are connected to the Internet
2. change the SOCKS proxy configuration (specify different host and/or port, but leave the SOCKS protocol version to be used the same), confirm
3. reload the page to see that FF is still using the old setting. Only if you let FF be for several seconds without any activity and reload the page afterwards, the new setting will be used for the connection

(Remarks: steps 2 and 3 must be performed within several seconds after loading the page in step 1; the testing page should be rather simple, otherwise many HTTP connections are opened, and the delay after which all of them would be closed can be very long.)

or

1. set up wrong SOCKS proxy in Configure Proxies to Access the Internet / Manual proxy configuration, confirm, and try to load some page to get the 'The proxy server is refusing connections' error message
2. change the SOCKS proxy configuration to a correct one (leaving the protocol version unmodified), confirm
3. wait for any amount of time and reload the page - the error message appears again (indicating that FF is still using the old proxy configuration)

Actual Results:  
described within 'Steps to Reproduce'

Expected Results:  
described within 'Steps to Reproduce'
Comment 1 (mostly gone) XtC4UaLL [:xtc4uall] 2011-04-28 12:20:20 PDT
Moving to Core for further Investigation.
Comment 2 Jerry Baker 2012-08-29 15:09:48 PDT
Verified using 8/19 nightly.

Steps to Reproduce
1. Set up a SOCKS proxy.
2. Configure Firefox to use a SOCKS proxy on a different port.
3. Try to load a page and receive an error (so far so good).
4. Change proxy prefs to correct port and press "try again" or try to load any page for that matter.

Result:
Firefox continues to try to connect to SOCKS proxy on old port until Firefox is restarted.
Comment 3 Patrick McManus [:mcmanus] 2012-09-01 13:04:05 PDT
Andrew - thanks for the original report. I'm sorry it took 14 months to get really looked at.

Jerry - thanks for verifying it with an up to date build; that put it on my radar.

The problem is that the SOCKS proxy host and port is not part of the Connection Manager Hash key, though the fact that it is SOCKS is indeed part of it. That means that after changing your information between socks proxies of the same version old persistent connections will be reused for new proxy information because they hash to the same thing.

patch forthcoming.
Comment 4 Patrick McManus [:mcmanus] 2012-09-01 13:05:55 PDT
Created attachment 657596 [details] [diff] [review]
patch 0
Comment 5 Jason Duell [:jduell] (needinfo me) 2012-09-04 16:45:38 PDT
Comment on attachment 657596 [details] [diff] [review]
patch 0

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

yay
Comment 6 Patrick McManus [:mcmanus] 2012-09-05 05:32:52 PDT
https://hg.mozilla.org/integration/mozilla-inbound/rev/233275bcbdf6
Comment 7 Ryan VanderMeulen [:RyanVM] 2012-09-05 19:41:58 PDT
https://hg.mozilla.org/mozilla-central/rev/233275bcbdf6
Comment 8 Jerry Baker 2012-09-11 07:53:27 PDT
Created attachment 660074 [details]
Log

I'm experiencing a "connection reset" issue accessing Google Docs through my SOCKS proxy using the latest nightlies and I wonder if this patch might be involved. The attached log has the corporate domain replaced with foo.org, but it should be a simple redirect to https://drive.google.com/a/foo.org/. It works in IE and Chromium, but FF nightlies give a connection reset error. It works fine in FF if I disable the SOCKS proxy and access directly.
Comment 9 Patrick McManus [:mcmanus] 2012-09-11 07:58:50 PDT
jerry - can you test it against a pre 9/5 nightly.. even just a quick test with aurora?
Comment 10 Jerry Baker 2012-09-11 08:08:59 PDT
My apologies. It is still an issue in 9/04 Aurora builds.
Comment 11 Patrick McManus [:mcmanus] 2012-10-16 09:28:39 PDT
*** Bug 802065 has been marked as a duplicate of this bug. ***
Comment 12 Eric H. Jung 2012-11-21 05:52:10 PST
FYI, this has been an issue for years, perhaps even going back to pre-1.0 days.
Comment 13 Majken Connor [:Kensie] 2012-11-21 08:36:09 PST
(In reply to Jerry Baker from comment #10)
> My apologies. It is still an issue in 9/04 Aurora builds.

Jerry, the fix was only on the nightly channel then. Can you test in a current Aurora build? (version should be 18.x)
Comment 14 Patrick McManus [:mcmanus] 2012-12-10 05:02:02 PST
*** Bug 806193 has been marked as a duplicate of this bug. ***
Comment 15 Patrick McManus [:mcmanus] 2012-12-11 07:58:43 PST
*** Bug 819851 has been marked as a duplicate of this bug. ***
Comment 16 Sk 2013-01-14 03:20:21 PST
Same issue on latest 17.0.2 ESR
How the heck new versions come out with such a nasty bug?

Do you plan to backport the fix onto ESR?
Comment 17 Sk 2013-01-14 03:21:31 PST
BTW, never had this issue with earlier Firefox up to 10.0.12 ESR. Just installed 17ESR and here we go.
Comment 18 Matthias Versen [:Matti] 2013-02-27 15:54:51 PST
*** Bug 845772 has been marked as a duplicate of this bug. ***
Comment 19 Alex Keybl [:akeybl] 2013-02-28 16:13:13 PST
Patrick - can you prepare a patch for the esr17 branch?
Comment 20 Patrick McManus [:mcmanus] 2013-02-28 17:00:13 PST
(In reply to Alex Keybl [:akeybl] from comment #19)
> Patrick - can you prepare a patch for the esr17 branch?

I don't think that's appropriate - this isn't a regression, despite comment 16.

 as comment 0 says, this was present in ff 4.
Comment 21 Sk 2013-02-28 23:20:13 PST
I've used firefox v1 - v10 up to current 10.0.12 ESR. Never had this issue. Installed 17.0.2 ESR and then 17.0.3 ESR - it is present and easily noticed right from the start.
Comment 22 Alex Keybl [:akeybl] 2013-03-14 17:57:25 PDT
(In reply to Patrick McManus [:mcmanus] from comment #20)
> (In reply to Alex Keybl [:akeybl] from comment #19)
> > Patrick - can you prepare a patch for the esr17 branch?
> 
> I don't think that's appropriate - this isn't a regression, despite comment
> 16.
> 
>  as comment 0 says, this was present in ff 4.

Do you believe Sk only ran into this now because of a recent configuration change on their end? If so, we'll untrack in that case.

I just want us to be sure we haven't exacerbated anything since FF10.
Comment 23 Sk 2013-03-15 01:36:55 PDT
>only ran into this now because of a recent configuration change on their end
I didn't change a thing. I constantly use and change socks in my FF sessions. All FF up to 10.0.12ESR (which is unsupported, but I still continue to use it since 17ESR socks is broken) work as they should. Jumped to 17.0.4ESR - no good.
Comment 24 Patrick McManus [:mcmanus] 2013-03-15 09:21:25 PDT
The bug in the code this patch addresses has always been there - comment 0 cites FF 4 as having the problem. That code remained unchanged until firefox 18, when I fixed it. I confirmed that through hg.

Based on the comments in this bug I did go try the use case on FF 19, ESR 17, and ESR 10. As expected it passed on 19, and failed on 17. It also passed on 10 - consistent with what sk reports.

I do not understand what is different in 10 that makes the test pass. I don't think its a great use of my time to figure it out. Especially given how lightly used socks is.

I applied the patch to 17 and the test passed there as well with the patch (which did not need to be updated in any way).

Those are the facts. I don't have an opinion on whether or not it should be applied to the esr17 tree but I'll set the approval flags so the drivers can decide.
Comment 25 Patrick McManus [:mcmanus] 2013-03-15 09:23:58 PDT
Comment on attachment 657596 [details] [diff] [review]
patch 0

[Approval Request Comment]
If this is not a sec:{high,crit} bug, please state case for ESR consideration: comment 24
User impact if declined: low impact - involves restarting when a lightly used preference is changed. comment 0
Fix Landed on Version: firefox 18
Risk to taking this patch (and alternatives if risky): unknown.
String or UUID changes made by this patch: none

See https://wiki.mozilla.org/Release_Management/ESR_Landing_Process for more info.
Comment 26 Jerry Baker 2013-03-15 10:15:55 PDT
The problem with this bug isn't simply that it requires a restart, but that it's impossible to know a restart is required without monitoring your own network traffic to see if the browser has made the change it says it has. Anybody using a socks proxy for their own protection (from a repressive regime, for example) will be vulnerable if they think they've engaged some basic identity protection and Firefox just keeps sending out traffic as if the change hadn't been made. Edge case? Perhaps. There aren't a lot of Firefox bugs that have the potential to land political dissidents in prison, though.
Comment 27 Patrick McManus [:mcmanus] 2013-03-15 10:21:33 PDT
Jerry - political dissidents should not be running ESR. 

(In reply to Jerry Baker from comment #26)
> The problem with this bug isn't simply that it requires a restart, but that
> it's impossible to know a restart is required without monitoring your own
> network traffic to see if the browser has made the change it says it has.
> Anybody using a socks proxy for their own protection (from a repressive
> regime, for example) will be vulnerable if they think they've engaged some
> basic identity protection and Firefox just keeps sending out traffic as if
> the change hadn't been made. Edge case? Perhaps. There aren't a lot of
> Firefox bugs that have the potential to land political dissidents in prison,
> though.
Comment 28 Jerry Baker 2013-03-15 12:51:35 PDT
(In reply to Patrick McManus [:mcmanus] from comment #27)
> Jerry - political dissidents should not be running ESR. 

Thanks for the tip. I hadn't been aware of that. I would have assumed the opposite.
Comment 29 Sk 2013-03-16 23:38:53 PDT
>Thanks for the tip. I hadn't been aware of that.
Actually, it was a bad tip. Cause FF from v16 till 19.0.1 had multiple issues with proxy support (ntlm issues, and so on: look thru numerous proxy bugs fixed). So the better choice is to use thoroughly tested ESR. Sadly, new FF "rapid" development process shows its' disadvantages, and even ESR release doesn't always help, like in this case.
Comment 30 Alex Keybl [:akeybl] 2013-03-21 15:09:37 PDT
Comment on attachment 657596 [details] [diff] [review]
patch 0

If the risk here is unknown, we obviously can't take the patch on ESR.

Should the patch be landed to m-c for future versions of Firefox/ESR?
Comment 31 Patrick McManus [:mcmanus] 2013-03-21 15:11:33 PDT
(In reply to Alex Keybl [:akeybl] from comment #30)
>
> 
> Should the patch be landed to m-c for future versions of Firefox/ESR?

the patch was landed (coincidentally) on ff18 when it was at m-c stage.
Comment 32 Sk 2013-03-25 05:05:13 PDT
So what.. you gon' leave ESR users with no working SOCKS?
Comment 33 Alex Keybl [:akeybl] 2013-03-27 11:35:27 PDT
(In reply to Sk from comment #32)
> So what.. you gon' leave ESR users with no working SOCKS?

Yes, until the next major ESR version. We do not believe that your user scenario warrants taking unknown risk. We suggest you utilize mainline Firefox to meet your needs.

Note You need to log in before you can comment on or make changes to this bug.