Objective: make fix for bug 521467 available to users Set: pref("signon.autologin.proxy", true); People who prefer the old behavior can toggle the pref. The pref was always intended to be true by default. It was only temporarily false, because of bug 521467 comment 45. I don't see any concrete problem, though.
It may be better to make this a (GUI) preference. (I'll try this out, see Bug 223636 comment 38)
Reported Bug 910670 for adding a disabled-by-default preferences option for proxy autologin. I think it can get confusing if autologin is enabled by default. If the user has not made the conscious choice to bypass the login screen, the lack of a login screen would be disorienting. Also, users won't know that the act of saving a password causes the prompt to not appear anymore.
Do other browsers offer similar functionality?
(In reply to :Gavin Sharp (mostly away until Sep 13; use firstname.lastname@example.org for email) from comment #3) > Do other browsers offer similar functionality? Nope. Not Chrome and IE, AFAIK. A lot of us engineer this functionality by setting up a second instance of CCProxy or squid as an non-auth proxy and chain it with the main proxy. But most browsers by default don't autologin to proxies. I'm not sure of this, but I believe that theydon't have a pref for this euther.
Gavin, rationale is in bug 521467 comment 0. If the user has such a proxy configured, he has to log in *every time* he starts the browser. If the user habitually closes the last window, as many do, that means he has to log in very often and is highly annoying. I don't see a considerable downside that would outweight this problem. The browser is unusable without logging in to the proxy, so there's no alternative. The password is already stored anyway (the patch and pref doesn't change that), so there's no security problem. (And if you are in an edge case where this behavior is a problem, you can still change the pref back to false, or delete the stored password.)
That makes sense, though I'm not sure that we can call those other cases as "edge" cases. Proxies are used for many, many purposes; one major use is to give the user access to an intranet (in which case login isn't necessary on startup). The other thing is that other browsers don't do this, so, like I said, this can be disorienting. But my concerns above aren't too major; I think your reasons are still valid and we should go through with this :) One way that should alleviate all remaining concerns with the edge cases is to implement the UI pref I mentioned in comment 2 -- that will be seen by anyone setting up the proxy and ought to be a good enough visual cue indicating that this will happen.
> other browsers don't do this (So we can have a competitive advantage. If we did everything like the others, we have no reason to exist anymore.) > I think your reasons are still valid and we should go through with this Thank you.
(In reply to Ben Bucksch (:BenB) from comment #7) > > other browsers don't do this > > (So we can have a competitive advantage. If we did everything like the > others, we have no reason to exist anymore.) Sure, that's another reason why I agree with this, but that doesn't stop it from *possibly* being disorienting. Remember, current FF does this too. It's a possible concern, that's all. : Until I discovered the hidden pref I was annoyed by the proxy prompt a million times a day. So was everyone else in the institute.
I quite understand the benefit. I'm trying to understand the downsides. So far it seems like there aren't really any. Presumably a MITM attacker could steal the password, but as I understand it there's no easy way for users to detect a MITM situation, so the incremental risk is minimal (we should perhaps investigate better protection against MITM proxy password stealing, but that seems unlikely to be very common?).
From what I remember: Without this, the HTTP query goes 403 Forbidden, we show password prompt (Firefox auth dialog UI), with hostname shown password prefilled (because the user had already stored it before, independent of this fix). The user clicks OK, and we resend the original HTTP query. With this patch, the user doesn't have to click OK. That's all. The user can't do checks. All the dialog shows is the hostname and realm. A real MITM would forge that, so no help. If the proxy is another host (I can't see how that would happen, but that's the only change the a user would actually see in the dialog), we wouldn't pick this password, because it hangs off the host, so we wouldn't send it. So no problem there. A potential problem is when the password on the proxy server changes. We'd submit the old password, it would fail with 403 Forbidden, which looks the same as no password, and we'd submit again. Loop. But IIRC, we thought of that case in bug 521467 and prevent this with special code. So that shouldn't happen either. All of this is "IIRC", because this is too long ago (2.5 years) for my small brain.
(In reply to :Gavin Sharp (use email@example.com for email) from comment #9) > I'm trying to understand the downsides. The only one I can think of (mentioned this above), is that it's a disorienting change. Users used to the old behavior will be confused. Some users may want to turn it off, but that probably is a teensy minority. > Presumably a MITM attacker could > steal the password, As far as proxies go, this vulnerability is always there (has nothing to do with autologin) The password is only sent if FF gets a 407 error (Proxy auth required or some such). And it will only get this error for sites which it is configured to use the proxy for. Without autologin, the user will be prompted for the password if it has not been provided previously in the session. If he provides it, then the website works. If not, then he will get a 403 or similar error. I haven't heard of any auth proxies that give something particularly useful when you give the wrong password (not providing a username/password gives a 407). Under the assumption that the user *wants* to visit the page, the password will always be sent. With autologin, the website loads without any prompt. The only case where there is a *new* MITM vulnerability provided by autologin is when the user is made to open a proxied page unwillingly. (I.e, if the intranet site internal.institute.edu redirects to en.wikipedia.org and the user doesn't want to open an internet site). This is a very ... rare case. I can't imagine any case where I'd want to use ONLY the non proxied network due to fear of MITM, and that I willingly visit a malicious non proxied site that sets me up for an MITM by opening a proxied site. > but as I understand it there's no easy way for users to > detect a MITM situation, so the incremental risk is minimal (we should > perhaps investigate better protection against MITM proxy password stealing, > but that seems unlikely to be very common?). There isn't a way to protect from MITM for HTTP proxies. Captive portals, yes, but not HTTP proxies. The protocol is a very standard one, and securing it would require a change in the protocol. There are ways the *infrastructure* can protect itself against MITMs (http://security.stackexchange.com/q/34879/7497, or using an HTTPS proxy http://security.stackexchange.com/q/23561/7497, or just switching to a captive portal), however the end user, when forced to use an HTTP proxy, must resign himself to the MITM vulnerability for the proxy credentials.
(In reply to Ben Bucksch (:BenB) from comment #10) > From what I remember: Without this, the HTTP query goes 403 Forbidden, we > show password prompt (Firefox auth dialog UI), with hostname shown password > prefilled (because the user had already stored it before, independent of > this fix). The user clicks OK, and we resend the original HTTP query. 407 usually, for most proxies. Sometimes a 403. A crazy sysadmin may configure the proxy to return 418, but otherwise 407/403 is standard behavior. > A potential problem is when the password on the proxy server changes. We'd > submit the old password, it would fail with 403 Forbidden, which looks the > same as no password, and we'd submit again. Loop. But IIRC, we thought of > that case in bug 521467 and prevent this with special code. So that > shouldn't happen either. No loop, I tried that out myself recently, and autologin prompts if it gets a 407. As far as I can see, the logic is as follows: - Browser requests page behind a proxy from the proxy - Server sends back a 407 - Autologin sends (wrong) password - Server sends a 407 again (or is it a 403?) - Autologin realises that there's a problem, and shuts itself off for the tab - User is prompted. He can now enter the new password (and save it)
Any verdict of this? Should we flag for sec-review? We have three options here: - Implement this with UI (bug 910670): This gives users with concerns an easy way to go back. - Implement this, without UI - Just implement the UI: No security concerns, but does clutter the UI and it' better if replaced by a default option. As far as I can tell, no other browser has this config option, and the behavior is to prompt the user every session. IE is a bit different, since Windows does proxy management on its own side, if you've already logged in to the proxy for the Windows session, you need not login again for IE (IIRC, haven't used IE in a while). I think this behavior can be carried over to firefox by using the "system proxy" preference.
Manish, we should just enable it. There is no reason not to. There is a big reason to do it: Avoiding to massively hassle the user. It makes no sense to store a password and then still bother the user on every single browser start (!) with a prompt, asking to confirm a password we already have. If there really is an edge case where this is a problem, the admin can easily disable it with the pref.
(In reply to Manish Goregaokar [:manishearth] from comment #14) > We have three options here: > > - Implement this with UI (bug 910670): This gives users with concerns an > easy way to go back. > - Implement this, without UI > - Just implement the UI: No security concerns, but does clutter the UI and > it' better if replaced by a default option. Bug 910670 is already fixed, so we should just flip the default pref value in this bug.
Patrick--are you ok with changing the pref here? AFAICT it's mostly a UI issue, but maybe I'm missing a security angle.
(In reply to Ben Bucksch (:BenB) from comment #0) > It was only temporarily false, because of bug 521467 comment 45. I'm still a teeny bit wary of enabling automatic login, but not objectionably so. FTR... The only security angle I can think of is if someone is relying on using the auth prompt as a permission prompt (eg to limit access to/from a closed network, or to limit XSS to something behind the proxy). But I think that's still practically ok as the current situation is not robust. My rationale keeps coming back to the fact that proxy auth is basically a one-time thing per session. Once you've done it, even with a prompt, it stays active until you either quit the browser or manually do a History --> Clear Recent History --> clear "Active Logins". [At least I assume that nukes proxy auth; it certainly does for HTTP auth.] So the only way to rely on using the prompt this way requires the human operator to be extremely fastidious with quitting/clearing once their desired task is done. Realistically this would be terribly error-prone and ineffectual security practice. As a more concrete example: In the current world, if you're browsing an evil page that unexpectedly triggers access to an authenticated proxy, the prompt will indeed give a savvy user the opportunity to say "whoa!" and deny access. But that seems extremely unlikely -- I'd expect that a user would almost always have authenticated earlier in their session for usual/legitimate reasons, and so browsing an evil page later on wouldn't trigger the prompt again. This mostly applies to HTTP auth, as well, although it's much more plausible that the prompt may serve as a speedbump to a site you rarely login to. For proxies, the far more common case is that the proxy is simply required for all external internet access. [Even 15 years ago, when I worked on firewall proxy software, using a proxy to get _into_ an intranet was uncommon. And now everyone uses VPNs for that.]
Justin, I think the most common usage of HTTP proxy auth is within corporations, where the proxy is on the perimeter between corporate network and the Internet. All Internet traffic goes through the proxy. I guess the reason why it's authenticated is to attribute traffic to specific users, in a way that doesn't rely on IP address->user mapping. It simply fits in their infrastructure. In this setup, the fact that the user has to do some manual action for proxy auth isn't an intentional security feature, but a nuisance. If you have setup where you really want that prompt, you can still have it by flipping the pref (possibly hidden). I think that situation is very rare, though.
> to attribute traffic to specific users (E.g. the old "You watched news/youtube/monster.com during work time. You're fired!")
(In reply to Jason Duell (:jduell) from comment #17) > Patrick--are you ok with changing the pref here? AFAICT it's mostly a UI > issue, but maybe I'm missing a security angle. I think this is really a front end call - so feel free to ignore my 2 cents. But I wouldn't make the change. It is way too easy to send out credentials unprompted from one network onto another when you switch networks just by moving your laptop or your phone.. and its always plaintext bearer basic auth tokens right now so that's doubly bad if you can easily get them to be emitted. that objection would be null if we were connected to the proxy over TLS - bug 378637. I'm actually working on that feature.
(In reply to Patrick McManus [:mcmanus] from comment #21) > It is way too easy to send out credentials > unprompted from one network onto another when you switch networks just by > moving your laptop or your phone. This is basically what I mentioned in comment 18... This is presumably already happening today, because unless a user is extremely careful about quitting the browser / clearing stored logins, switching networks doesn't clear anything. And so loading a web page (or waiting a moment for, say, an already loaded Twitter to make a new XHR) will send out proxy creds.
actually daniel and steve are working on a changed network trigger right now for doing this kind of state clearing. This should go on the list of things to observe it.. (open connections, dns, etc are the obvious first things).
Is this going to be landed soon? I need to sign off the feature from bug 910670 for 30 Beta and it will be with no use if I sign off it and then just remove it after this will land.
Created attachment 8412458 [details] [diff] [review] Change pref to true
Comment on attachment 8412458 [details] [diff] [review] Change pref to true As said in initial description, this was false only as temporary measure. See original bug 521467.
Comment on attachment 8412458 [details] [diff] [review] Change pref to true Review of attachment 8412458 [details] [diff] [review]: ----------------------------------------------------------------- based on comment 16 r=gavin r=mcmanus
checkin-needed, hg commit message: " Automatically log in to HTTP proxy that needs credentials -- Bug 646452, bug 521467, r=gavin r=mcmanus Some proxies need a username/password. Some internal corporate networks have such a proxy. In practice it is often merely to account what which employee does on the Internet. Such users need to log in whenever they start the browser, which obviously is very often. We already store the password, but we don't use it. This change flips the pref to actually use that password. If some setups/corporations have a problem with this, they can change the pref back to false for their users. "
https://hg.mozilla.org/integration/mozilla-inbound/rev/426526ce4367 To make life easier for those landing on your behalf, please make sure future patches include commit information. Thanks! https://developer.mozilla.org/en-US/docs/Mercurial_FAQ#How_can_I_generate_a_patch_for_somebody_else_to_check-in_for_me.3F
hi all. i am pretty new how do I apply the patch ?
(In reply to pbugzilla from comment #31) > hi all. > i am pretty new > how do I apply the patch ? If you have the source for Firefox, you can apply this patch with `patch -p1`, and recompile. This isn't a patch that can be applied to a normal firefox install.