688448 - Clean UX for one-time security exception to do browser authentication

Status: RESOLVED DUPLICATE of bug 562917

(Core Graveyard :: Security: UI, defect)

Description

[WBT]

Mozilla's UI/UX should acknowledge that some networks require browser-based authentication and handle that appropriately, without blocking, scaring, or desensitizing the user.

Steps to reproduce:
1. Connect to a wireless network that has browser-based authentication.
2. Open a browser or e-mail client (FF / TB), which tries to connect to a homepage or an e-mail server.
3. The local network redirects your communication to their authentication server, for the purpose of presenting you with an authentication page instead of the requested one.  

Actual results:
4. You are greeted with various security warnings, popups and interstitials.  It looks like there is something seriously going wrong here, when in reality you're just needing to get to the point where you can authenticate network access.
5. To get around the security warnings, you have to open up the special drop-down to say you understand the risks, and add an exception; the default is to make this a permanent security exception (when you really only need it to be one-time).  A large percentage of users won't know how to do this or to do it at all; they'll assume that they just can't get online using FF/TB and should switch to something else.  Of users that do add the exception, many will leave the default and it'll be a permanent exception. 
6. After seeing these warnings when there's not a significant cause for concern, and requiring users to "overcome" them to make basic use of their client, they are desensitized to these warnings and they become less effective when they should be raising a real red flag.

Expected results:
5. Firefox/TB detects that the redirection/invalid certificate error is due to web-based network authentication.  It might do this by trying to access other servers and seeing the same redirection attempt, by looking at the IP or other characteristics of the redirection site, etc., details to be discussed in the comments below. 
6. The network authentication page is presented to the user, perhaps with a note that the page they are viewing is not the one they requested.  At the very least, the security warning explains that the redirection/cert error could be due to a need for web-based authentication and gives users a visible button to click to do that authentication (adding a one-time security exception). 
7. The user logs in and can proceed with his/her Internet experience as desired.
8. When the user later sees a "real" security warning (e. g. redirection/invalid certificate), they will be more likely to respond appropriately.

Comment 1

[Jo Hermans]

In my daytime job, I have programmed routers with this feature, for both small wireless accesspoints and for big telco routers used by millions of users. I don't think it's really possible to detect this in every case.

- most routers will fix it with a 302 Redirect or similar, but that's not really detectable either. If it happens to be a redirect into your own network or to the router itself (192.168.1.1 for instance), then yes, you can detect it. But I've also seen cases where you were redirected to a completely different webserver (possibly in the network of your telco).

- some routers might server some new content without changing the ip-address. That's not detectable by the browser, not even if the content gets served with a different certificate. Yes, it's possible to hijack !

- some routers might only redirect the very first attempt (for displaying an advertisement or a welcome page), but let the next ones pass. Your point 5 doesn't work here.

You're basically complaining about routers that are using self-signed certificates, which is indeed a problem. But don't confuse it with the redirects.

Comment 2

[WBT]

>I don't think it's really possible to detect this in every case.

Is it at least possible to detect it and handle it well in some percentage of cases greater than 0? 

OR, could we change the warning to tell people that it might be because of a need for browser-based authentication, "click here to do so?"

Comment 3

[Jo Hermans]

(In reply to Jo Hermans from comment #1)

Captive portal detection like in bug 701823, where you can examine the result for a known page, is probably the best solution.

Comment 4

[Brian Smith (:briansmith, :bsmith, use NEEDINFO?)]

I am duping this to bug 562917 because whatever UX we create for that will solve this issue, and somebody (lco) is working on designing the UX.