652928 - manual proxy SOCKS configuration change doesn't have (immediate) effect

Status: RESOLVED FIXED

(Core :: Networking, defect)

Description

[Andrew]

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

Moving to Core for further Investigation.

Comment 2

[Jerry Baker]

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

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

Attachment: patch 0

Comment 5

[Jason Duell]

Comment on attachment 657596 [details] [diff] [review]
patch 0

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

yay

Comment 6

[Patrick McManus [:mcmanus]]

https://hg.mozilla.org/integration/mozilla-inbound/rev/233275bcbdf6

Comment 7

[Ryan VanderMeulen [:RyanVM]]

https://hg.mozilla.org/mozilla-central/rev/233275bcbdf6

Comment 8

[Jerry Baker]

Attachment: 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]]

jerry - can you test it against a pre 9/5 nightly.. even just a quick test with aurora?

Comment 10

[Jerry Baker]

My apologies. It is still an issue in 9/04 Aurora builds.

Comment 12

[Eric Jung [:ericjung]]

FYI, this has been an issue for years, perhaps even going back to pre-1.0 days.

Comment 13

[Majken Connor [:Kensie]]

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

[Sk]

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]

BTW, never had this issue with earlier Firefox up to 10.0.12 ESR. Just installed 17ESR and here we go.

Comment 19

[Alex Keybl [:akeybl]]

Patrick - can you prepare a patch for the esr17 branch?

Comment 20

[Patrick McManus [:mcmanus]]

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

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

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

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

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

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]

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

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]

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

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

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

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

So what.. you gon' leave ESR users with no working SOCKS?

Comment 33

[Alex Keybl [:akeybl]]

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