555551 - Session restore functionality is broken by captive portal software

Status: NEW

(Firefox :: Session Restore, enhancement)

Description

[Michael]

User-Agent:       Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091116 Gentoo
Build Identifier: Mozilla/5.0 (X11; U; Linux x86_64; en-US; rv:1.9.1.5) Gecko/20091116 Gentoo

If you have saved your session in a Mozilla web browser (eg: Firefox, Seamonkey), the functionality is broken if you are behind a captive portal system or proxy that uses authentication with a web form (such as Novell).  After being disconnected, the user is prompted to login to the captive portal again on all of their tabs.

As a developer of captive portal software, it would be nice if there was a *standard* way that I could report to web browsers that a captive portal is intercepting their request, and that the user should prompted to login on only *one* of their browser tabs, and then the captive portal reports back to the browser once the user is logged in again to restore the remainder of their tabs.

So for pages that result in being put in a captive portal login page, the following header could be set:

  X-Captive-Portal: login-required
  X-Captive-Login-URI: https://captive.example.com/login/

And once the user is logged in, another HTTP header can be sent:

  X-Captive-Portal: authenticated

And then the login window can be closed and the tabs restored.

The browser could mimic the behaviour of Microsoft's Network Location Awareness service by attempting to connect to a site like http://www.msftncsi.com/ncsi.txt (except have the page hosted by Mozilla, eg. conntest.mozilla.org) as a connection test to prevent an external website from sending those headers fraudulently.

The system should also provide a ribbon or other notification in order to allow the user to force the browser to restore the entire session regardless of what the server reports, an option to disable captive portal detection, and also to support captive portal implementations that do not use these headers.

Reproducible: Always

Steps to Reproduce:
1. Open some websites in tabs and save your session.
2. Log out of a captive portal.  This can be as simple as a timeout causing it to occur.
3. Attempt to restore your session.
Actual Results:  
The session is generally entirely lost, and there are login prompts on every tab.  The ability to restore the session depends on the captive portal software in use.

Expected Results:  
The browser should detect the presence of a captive portal and prompt for a login once before restoring the remainder of the tabs.

Additional custom captive portal states could also be supported through this mechanism, to be checked on browser startup through the ping-back mechanism.  For example:

  X-Captive-Portal: disabled
  X-Captive-Message: You have exceeded your internet quota usage.  Please visit the captive portal page in order to purchase additional quota.
  X-Captive-URI: https://captive.example.com/top-up/

A captive portal software could send a notification to the browser that internet access has been disabled for some reason, and a URI to visit for more information.

Comment 1

[u279076]

Adding UX-FEEDBACK.  Paul, this is a pretty unique case.  I'm not sure how to gracefully handle these sorts of situations.

Comment 2

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

CCing Alex - I know he was looking for a bug like this before.

I think it would be awesome to do something like suggested. The only problem I've thought of if where we do it. We probably don't want slow startup by adding another request (though I guess in the grand scheme of things, one extra request wouldn't hurt).

I think if we get on top of this sooner rather than later & figure out how we want the UX to be, we could get something going for a future version of Firefox.

Comment 3

[Michael]

I've now cross-reported this issue to the Chromium bug tracker here:

http://code.google.com/p/chromium/issues/detail?id=43162

I believe this bug effects ALL web browsers with session restore functionality. 

The only browser I've seen that handles captive portals gracefully is iPhone's version of Safari, where on connecting to a network with a captive portal it will prompt the user to enter a password on the spot before allowing it to finish connecting.

Comment 4

[Michael]

It seems I put the wrong link in there to my bug on the Chromium bug tracker.  Now that there's been some activity with the Chromium folks I noticed this and have corrected the URL.

The URL of my bug at Chromium (55283):
http://code.google.com/p/chromium/issues/detail?id=55283

But that issue has now been merged into 52489 because of other people having this issue.
http://code.google.com/p/chromium/issues/detail?id=52489

I've updated the See Also links accordingly in the bug's metadata.

Another thing to think about is how to handle different languages for the messages.  My thought on this was to just send the normal HTTP preferred language headers that are normally sent with such requests.  If the captive portal system wishes to provide translated strings (or has them), then it can send them straight back down in the headers.

Comment 5

[André Pirard]

I met the session restore & multiple Portal Login pages problem too and here are some thoughts...

There were more than 100 http://login...&url=stolen.url
No way to get back to the stolen.url ... but to actually login 100 times.
Don't expect to wait to be at home to try do that, only this will help, partially... !!!
firefox `echo "$1" | sed -e 's/http.*&url=//' | sed -e 's/%3A/:/g' -e 's/%2F/\//g' -e 's/%2E/\./g' -e 's/%3F/\?/g' -e 's/%3D/\=/g' -e 's/%26/\&/g' -e 's/%2D/\-/g'`  (to be continued!!!)
I don't know who wrote that portal, but that's certainly a big bug to fix.

Solutions in the Web browsers have little chance to succeed because
- there are just too many Web browsers to fix
- one cannot have reception desks distribute update CDs for all of them
- nor give the necessary instructions, even less extensive support
- people won't read documentation before use anyway, just FAQ afterwards

The best to avoid all problems is to use WiFi authentication "just like at home".
WPA authentication is very automatic and simple to use on all clients.
It must be possible to use WPA-like authentication on WiFi side and 802.1x on RADIUS side.
Enter password: username/password or just password=username.
And contrarily to a portal password, a WAP password is remembered by the user's system.
Multiple SSIDs can really help, with multiple authentication methods to try in order.
Falling back to a portal if really necessary.

If a fix is really wanted in the Portal here is example logic in hope to prevent stealing Web pages...
Time pages requests arriving during Login phase and reply with Login page only if the previous page request was more than let's say 10 seconds ago.  For the first page, put it on hold for those 10 seconds and reply with Login only if no other requests arrived.   Refinements must exist. 

One simple way to dodge the problem is to instruct the user to 1) disable WiFi (there is usually a switch) 2) launch the browser, 3) let all its activity restoring pages settle down and 4) only then open the WiFi and 5) open a Login page.  But as the reception desk where I hired a WiFi does not even instruct to launch a browser to authenticate, I guess it's hopeless that they could explain that.

Please note that the suggestion in Mozilla Bug 684548 is a Firefox based solution too.
The user is able to start and fill the Login page before he allows any other page to to start.

Comment 6

[Michael]

(In reply to André Pirard from comment #5)
> There were more than 100 http://login...&url=stolen.url
> No way to get back to the stolen.url ... but to actually login 100 times.
> Don't expect to wait to be at home to try do that, only this will help,
> partially... !!!
> firefox `echo "$1" | sed -e 's/http.*&url=//' | sed -e 's/%3A/:/g' -e
> 's/%2F/\//g' -e 's/%2E/\./g' -e 's/%3F/\?/g' -e 's/%3D/\=/g' -e 's/%26/\&/g'
> -e 's/%2D/\-/g'`  (to be continued!!!)

This is just insane to expect someone to do.  As you've pointed out, this would be software-specific.  In my case I'm someone who *is* writing a captive portal software, I want to come up with a solution that can please everyone, and hopefully other captive portal vendors will pick up on it.

> Solutions in the Web browsers have little chance to succeed because
> - there are just too many Web browsers to fix

Apple have already started to fix this in iOS.  I understand this is a big undertaking but all the browser vendors managed to (mostly) co-operate with implementing HTML5.  I'm going to Chromium and Mozilla first because they're browsers I use and being open source they're more likely to incoporate these kinds of changes.

Given my past discussions with Microsoft employees, they're more likely to do something "if everyone else is doing it".

> - one cannot have reception desks distribute update CDs for all of them

True, but Firefox and Chrome both agressively engage in automatic updates.  We're also talking about a fix that break compatibility with existing portals, this is more of a case of "this will make your experience better" not "this is the only way to do this".  Captive portal softwares will still emit normal HTML messages as well.

> - nor give the necessary instructions, even less extensive support
> - people won't read documentation before use anyway, just FAQ afterwards

If a browser didn't support these headers, it wouldn't matter.  They'd still emit a normal HTML page which handles legacy browsers.

> The best to avoid all problems is to use WiFi authentication "just like at
> home".

This isn't a great solution, because you have to go for the "lowest common denominator".  There's lovely use cases like:

- I use captive portal software on networks that accept both wired and wireless connections.
- I use captive portal software with devices that don't support complex authentication mechanisms (gaming consoles).
- I use captive portal software to take credit card (or other payment) information and use it to bill the user.

Unfortunately these require multiple networks and complex instructions.  It'd be easier to have a captive portal page that says "hey, we do XXXXXX with our network, here's how you login or gain access".

> WPA authentication is very automatic and simple to use on all clients.
> It must be possible to use WPA-like authentication on WiFi side and 802.1x
> on RADIUS side.

Doesn't work with wired clients or gaming consoles.

> And contrarily to a portal password, a WAP password is remembered by the
> user's system.
> Multiple SSIDs can really help, with multiple authentication methods to try
> in order.
> Falling back to a portal if really necessary.

Multiple SSIDs == training issue.

> If a fix is really wanted in the Portal here is example logic in hope to
> prevent stealing Web pages...
> Time pages requests arriving during Login phase and reply with Login page
> only if the previous page request was more than let's say 10 seconds ago. 
> For the first page, put it on hold for those 10 seconds and reply with Login
> only if no other requests arrived.   Refinements must exist. 

This doesn't help because Firefox for example makes a request to the update services and phishing filters on startup, as well as the OS itself may make requests to test connectivity (Windows for example does this).

> Please note that the suggestion in Mozilla Bug 684548 is a Firefox based
> solution too.
> The user is able to start and fill the Login page before he allows any other
> page to to start.

That's essentially what I want to happen -- Firefox to do some simple detection that says "hey all my requests are being sent to a portal", and the portal (optionally) to say "hey I'm a portal and this is why I'm eating all your requests, treat me differently".

Comment 7

[André Pirard]

Sorry I have very limited time for this.
Please refer to the preceding messages to expand my short quotes.
>> firefox `echo "$1" | sed -e 's/http.*&url=//' | sed -e 's/%3A/:/g' -e
>> 's/%2F/\//g' -e 's/%2E/\./g' -e 's/%3F/\?/g' -e 's/%3D/\=/g' -e 's/%26/\&/g'
>> -e 's/%2D/\-/g'` (to be continued!!!)
> This is just insane to expect someone to do. ...
Of course I'm not suggesting cartoon symbol swearing in a user's manual :-)
I was forced to use it by "that portal".  I complained loudly.
I did not use the word "insane" but I sort of agree with you.
> Multiple SSIDs == training issue.
The *only* instructions for "that portal" were how to select the correct SSID (no mention of browser).
As everybody was doing it, I suppose it's doable.
Name them "laptop", "game console", "whatever".
Any attempt to further explain that SSID selection would resemble the ubiquitous
Slide the cursor named "keyboard repeat rate" to adjust the keyboard repeat rate.
>> The best to avoid all problems is to use WiFi authentication "just like at
>> home".  (WPA interfacing RADIUS)
> This isn't a great solution, because you have to go for the "lowest common
> denominator".  ... wires, limited gaming consoles etc...
1) Please note that I'm addressing the session restore problem on WiFi hotspots for laptops (95+%).
I don't reject other usage. With portals: gaming consoles etc. do not have the same requirements.
The SSID can select which.
2) Yes it's a great solution because WPA makes a secure WiFi.
Much of what I sent through "that insecure portal" could have been captured by any kid with a plain sniffer, no encryption, no password, no need to spend hours guessing one with aircrack.
3) Yes "like at home WiFi" is the best bet to have a surprise-proof sit-and-work network.
If a gaming console prevents their home WiFi to use WPA, they'd better sell it on eBay.
BTW, I'm no gamer but where I helped installing WiFi what the kids used was Nintendo DS which is OK on WPA but wouldn't work with a portal.  Same with someone sitting to do just his e-mail and finding no network.
> Microsoft, Apple, Mozilla, automatic updates...
I certainly would prefer to have to deal just with my portal software rather than, in addition, become volunteer support for a myriad of browsers and Web users of all kinds.  I always warn against "automatic update" as the best way to have one's program suddenly stop working and "latest version" the same on request by support.
>> If a fix is really wanted in the Portal here is example logic in hope to
>> prevent stealing Web pages...
>> Time pages requests arriving during Login phase and reply with Login page
>> only if the previous page request was more than let's say 10 seconds ago.
>> For the first page, put it on hold for those 10 seconds and reply with Login
>> only if no other requests arrived. Refinements must exist.
>
> This doesn't help because Firefox for example makes a request to the update
> services and phishing filters on startup, as well as the OS itself may make
> requests to test connectivity (Windows for example does this).
I would ponder "Refinements must exist" thoroughly.
It's no big deal if just two 2 or 3 pages open instead of 50 as long as, unlike "that portal", one allows to BACK to the previous page and, unlike "that portal", the login page contains the necessary instructions.

Comment 8

[Nicolas Barbulesco]

This is a very good idea.
But think of the new Firefox feature that restores form data.
See : https://bugzilla.mozilla.org/show_bug.cgi?id=648683#c38
If the present portal handling flavour of session restoring keeps the form data restoring feature in working order, that will be really great !

(In reply to André Pirard from comment #7)

> It's no big deal if just two 2 or 3 pages open instead of 50 as long as,
> unlike "that portal", one allows to BACK to the previous page and, unlike
> "that portal", the login page contains the necessary instructions.

If the portal page comes without allowing the user to go back to the originally requested address, then this is a bug / wrong design in Firefox.

Comment 9

[André Pirard]

>If the portal page comes without allowing the user to go back to the originally requested address, then this is a bug / wrong design in Firefox.

There's no such bug in Firefox.
Telenet portals simply leave the back page on the stack and you just BACK
Unknown portals hide the back URL in their URL and you must use the insane method above
Fon Belgacom portals seem to have no way at all.

Portals don't seem to care much for returning to the stolen page unless you effectively Login.
50 times or never if you're back at home.

Comment 10

[Nicolas Barbulesco]

(In reply to André Pirard from comment #9)

> >If the portal page comes without allowing the user to go back to the originally requested address, then this is a bug / wrong design in Firefox.
> 
> There's no such bug in Firefox.

Well, in fact there is such a bug in Firefox.

I understand from you that some portals redirect the user in a way that lets the user go back and that some portals redirect the user using a more discreet technique that does not let the user go back.

Let's look at this scenario :

I ask my dear Firefox to go to the address A. Firefox goes to the address A. Using whatever technique, the Web server asks Firefox to go to the address B. Firefox goes to the address B.

The page address has changed. So Firefox must let me go back to the address I originally requested, by clicking the Back button.

> Portals don't seem to care much for returning to the stolen page unless you
> effectively Login.

I trust more Firefox than the portals for caring about the user.

Firefox proudly says his mission is putting the user in control. Fine. :-) 

You seem to have nightmares at losing Web addresses because of portal redirections.

Note that there is this pref in Firefox, in “Accessibility” I think : “Warn me when websites try to redirect or reload the page”. Firefox' help says : “When this preference is enabled, Firefox will prevent websites from redirecting you to another page, or automatically reloading.” Unfortunately, it does not work in all cases. See requests bugs 606286, 687300, 615306, 680565.

Comment 11

[André Pirard]

> Well, in fact there is such a bug in Firefox.
>
> I understand from you that some portals redirect the user in a way that lets
> the user go back and that some portals redirect the user using a more discreet
> technique that does not let the user go back.

No.
In normal operation (after login) they don't "let the user" but they "do" "go back".
Only on the 50 dangling login pages has the user to "go back" or figure "how to" or "why not".
Each have their own method to hide the back URL, BACKable, HACKable or UNUSable.

> “Whenthis preference is enabled, Firefox will prevent websites from redirecting you to another page, or automatically reloading.”

My provider installed a public Fon portal in my private router and that option did not prevent the Login page to come up.  You may probe any public portal without spending a single cent.

There wouldn't be any Firefox bug anyway.
All these talks are digressing much from the most simple solution: WPA2 in portals!

Comment 12

[André Pirard]

> Depends on: 
After reading bug 562917 discussion, I think that this issue must be solved independently of a solution smart guessing Portals, missing a few and needing a Firefox patch when a Portal software changes.

Comment 13

[Tantek Çelik]

(In reply to Michael from comment #3)
> I believe this bug effects ALL web browsers with session restore
> functionality. 
> 
> The only browser I've seen that handles captive portals gracefully is
> iPhone's version of Safari, where on connecting to a network with a captive
> portal it will prompt the user to enter a password on the spot before
> allowing it to finish connecting.

Desktop Safari as of the default on MacOSX 10.7 Lion and later now does this as well.

It detects the presence of a captive portal (with what appears to be a DNS request for apple.com checked against a baked in whitelist of IP numbers), and then presents a pop-up window with the captive portal page.

It continues to check to see if the captive portal has provided actual internet access and once it does, the pop-up automatically goes away (without waiting for it to load whatever transition/welcome page it was going to load etc.).


(In reply to André Pirard from comment #12)
> After reading bug 562917 discussion, I think that this issue must be solved
> independently of a solution smart guessing Portals, missing a few and
> needing a Firefox patch when a Portal software changes.

I agree that this needs to be solved in Firefox independent of how much smarter/better captive portals may get.

Currently when relaunching Firefox after a system restart in a location with a captive portal, I get all my restored tabs loading with captive portal redirects with URLs like:

http://madeline.inria.fr/aaa/wba_inria-guest.html?wbaredirect=http://wiki.csswg.org/spec/cvs
http://madeline.inria.fr/aaa/wba_inria-guest.html?wbaredirect=http://wiki.csswg.org/tools/hg/install
http://madeline.inria.fr/aaa/wba_inria-guest.html?wbaredirect=http://wiki.csswg.org/ideas/functional-notation

EXCEPT when attempting access to an https URL, session restore functionality is REALLY broken by captive portal software.

E.g. I see https://developer.apple.com/xcode/ in the URL bar (instead of a redirect URL like the above), and get the Firefox warning message instead in the window:

[Passport checking official in a yellow icon]

"This Connection is Untrusted

You have asked Firefox to connect securely to www.google.com, but we can't confirm that your connection is secure.

Normally, when you try to connect securely, sites will present trusted identification to prove that you are going to the right place. However, this site's identity can't be verified.

What Should I Do?
          
If you usually connect to this site without problems, this error could mean that someone is trying to impersonate the site, and you shouldn't continue.

"

This is a particularly bad experience as the one button "Get me out of here!" will not help the user get connected, nor does it direct them towards the solution, at the same time scaring them that something very bad is happening, when it is merely a captive portal.

I suggest implementing a solution like what desktop Safari has done and deployed as of MacOSX 10.7 Lion.

Comment 14

[André Pirard]

I believe that the one and only solution for portals is to use WPA2.
That gets rid once for all of all these round and round discussions.
But, of course, insecure portals allow to pick any money easily.

Presently, they are covering the whole of my country with *unencrypted* FON public access.
That isn't stated in their offer, just in hidden words in their small gray letters terms.
I had problems using IMAPS (SSL) over those connections and I called our main operator.
- what port do you use?
- 993 [NB: IMAPS, encrypted]
- ah, we have a much better port for you: 143 [NB: IMAP, unencrypted]
- hey there, that's totally insecure communication
- why do you call if you don't want to do as you're told?
Believe it or not, that's exactly what he said.
Abusing ignorant people.
That's what money drives them into.

Regarding backing to the before-portal page, I said that some just allow the BACK key and that others hide the URL inside another to play the so-called insane game described above.
The totally insecure over FON communication just described doesn't seem to allow any backing.

Comment 15

[André Pirard]

In bug 684548 I suggest: Edit/Preferences/General/Startup/When Firefox Starts:
Always show the Session Restore page.

Portal aware people may use it.
That prevents any page being restored before permission, hence logging in beforehand.
Portal service providers may be asked to recommend it but they won't.

I suppose one may vote for that idea.

Comment 16

[Paul O'Shannessy [:zpao] (not bugmail, email directly)]

(In reply to André Pirard from comment #15)
> In bug 684548 I suggest: Edit/Preferences/General/Startup/When Firefox
> Starts:
> Always show the Session Restore page.
> 
> Portal aware people may use it.
> That prevents any page being restored before permission, hence logging in
> beforehand.
> Portal service providers may be asked to recommend it but they won't.

People can already set it to show the default home page which has a "restore previous session" button on it.

Another interim solution is to set Firefox to not load tabs until selected. Under that setting only the selected tab in each window (and app tabs by default) will be loaded. No other tabs will be loaded until they become the active tab.

Ultimately I think we should go for what Tantek said - something akin to what Safari / OS X is doing on mobile & desktop.

Comment 17

[Nicolas Mailhot]

 
> As a developer of captive portal software, it would be nice if there was a
> *standard* way that I could report to web browsers that a captive portal is
> intercepting their request, and that the user should prompted to login on
> only *one* of their browser tabs, and then the captive portal reports back
> to the browser once the user is logged in again to restore the remainder of
> their tabs.

Well such a way is being defined now by the IETF:
HTTP error 511 Network Authentication Required

Maybe resolving bug #728658 would be sufficient to fix your problem?