Project: chromium Issues People Development process History Sign in
New issue
Advanced search Search tips
Note: Color blocks (like or ) mean that a user may not be available. Tooltip shows the reason.
Starred by 13 users
Status: Duplicate
Merged: issue 87100
Owner: ----
Closed: Jul 2012
Cc:
Components:
EstimatedDays: ----
NextAction: ----
OS: ----
Pri: 2
Type: Bug

Restricted
  • Only users with Commit permission may comment.



Sign in to add a comment
SSL error page for mail.google.com behind captive portal
Reported by kenmoore@google.com, Feb 3 2011 Back to list
Encountered on Chrome OS, but I was advised by Dan Erat to post the bug on Chromium site.

Chrome OS Version  :  0.9.128.14
Chrome Version     :  8.0.552.344
Type of computer   :  Mario DVT
Network info       :  hotel wifi with captive portal


What steps will reproduce the problem?
1. sign into captive portal
2. let computer go to sleep past authentication window (in my case overnight)
3. sign back in from lock screen
4. go to mail.google.com

What is the expected output?
Should get some form of "You are not connected" message

What do you see instead?
scary SSL error

 
Labels: -Area-Undefined Area-Internals Internals-Network
Cc'ing the SSL braintrust.

My guess of what's happening is, the portal is hijacking DNS to redirect you to a specific ip address to sign in. You are probably going to https://mail.google.com instead of http://mail.google.com, therefore we will try connect to port 443 for this webserver, which will present some certificate with the incorrect credentials for mail.google.com, hence we throw up the interstitial page.

Assuming my analysis is correct, the question is, what to do here? Maybe we need to hijack the intranet redirector detection code to see if the portal is playing these DNS games with us (all hostnames probably resolve to the same ip). If an omnibox / refresh / otherwise user-generated URLRequest resolves to same ip address, then we can probably guess that the portal is playing this DNS trick on us, and use that as a signal to do a different behavior (redirect to http? show a different interstitial page?)
Comment 3 by agl@chromium.org, Feb 3 2011
Yes, it's almost certainly a captive portal. I'd welcome patches which catch this case and offer to send the user to http://example.com in order to get the portal page.
Comment 4 by wtc@chromium.org, Feb 3 2011
Status: Untriaged
I wonder if captive portals are all located on a standard
private IP address such as 192.168.0.1.  If so, that would
be another signal we can watch out for.
I've seen them appear in all the RFC1918 private ranges - but I've also seen situations where the captive portal is presented as a public IP and URL that the portal whitelists for outbound connections. I do think that detecting along the lines of the intranet detection may be able to catch the case.

For what it's worth, there was some discussion about this in the httpbis working group that has been picked up in the apps-discuss group - http://lists.w3.org/Archives/Public/ietf-http-wg/2011JanMar/0086.html - which looks to implement a new HTTP status code to signal when a captive portal in play. There was also discussion about using a DHCP-Option based approach.

While it's still very early in the draft stage, it might benefit from a major browser vendor willing to implement / assist with the process. It's at least something to keep an eye on, since this problem affects generally any client using HTTP/HTTPS, many of which are non-browsers these days.
Comment 6 by wtc@chromium.org, Feb 4 2011
Thanks for the info.  A new HTTP status code won't help
this bug because we get the SSL certificate name mismatch
error before we can send an HTTP request.

By the way, I'm sure we already have a bug report on this
problem.  We should mark this bug as a duplicate.
wtc: The status code was more in line with the intranet detection behaviour. If the detector gets the new status code, then it's known that a captive portal is involved and to direct users to there. It's an alternative to detecting if the IP addresses resolve to the same address is all I was suggesting, and it includes more context information about the captive portal address.
Adding Peter for intranet redirector expertise.

How do we distinguish captive portals from the landing pages that ISPs insert for misspelled domains? As I recall, the intranet redirector was added for that particular case. As I understand, both captive portals and ISPs trying to put up ad-filled landing pages for misspelled domains will resolve unknown domains to the same ip address. I guess the difference is that a "well-known" hostname, such as the search engine's hostname, should resolve to the private IP in the captive portal case and to the real public IP in the ISP misspelled domains case.

@rsleevi: I'm not opposed to supporting a new HTTP response code, but that won't fix the problem for all the many existing captive portals. Perhaps we should discuss with httpbis and fork a separate bug to implement their suggestion? What do people think about that?
The tricky part here is that if you add a "real" domain to the redirector check, that means every user of Chrome will be making a request to that domain on every startup.  That's both a nontrivial server load and a worrisome thing to people who want to make sure their browser isn't sending private data anywhere.  (The latter reason is why, for example, the GoogleURLTracker does not fire if the user's settings don't require it, even though the actual check we make is innocuous.)
Peter, I think you might be jumping to the conclusion that we would be using URLFetcher and actually issue an HTTP request to the "real" domain. I think we could get by with using the HostResolver directly to make sure the "real" domain resolves to a IP address that does not match the same IP for a bogus hostname. For a "real" domain, the DNS response would hopefully be cached somewhere such that it does not cause inordinate load. And I'd hope that a DNS query wouldn't raise any privacy eyebrows.
Issue chromium-os:11578 has been merged into this issue.
Related issue 52489 on detecting captive portals.
nkostylev: I noticed you landed a change for this for ChromeOS (http://codereview.chromium.org/6469027). How are you addressing the concerns pkasting raised in comment 9?
Solution for ChromeOS is an arbitrary solution till we have a reliable captive portal detection.

When we hit ClientLogin service we treat any incorrect response as a possible captive portal case.
We present error message that suggest launching guest session.
Guest session launches with "www.google.com"
In case of captive portal it will redirect to portal sign in page.
This only affects new user sign ins since existing users would authenticate via offline auth and will face captive portal redirect when they are already signed in.
Labels: Mstone-X
Status: Available
Moving to mstone-x until we have a strategy to deal w/ it.
 Issue #114929  has been filed to request the support of captive portals that use HTTP error 511 (a defined by the IETF) to communicate authentication is required and where it is required.

The IETF spec is much nicer than the various approaches discussed there as it can be used to implement authentication on proxies in a reasonably standard and device-agnostic way (without requiring every possible web client to be in a single Active Directory domain).

Contrary to the other sorts of captive portals, a corporate proxy:
1. won't be accessed wirelessly only
2. won't try to hijack the whole DNS
3. won't block access to Intranet resources
4. won't block access to every possible Internet resource (only those the corporate policy says is restricted to specific classes of users that need to authenticate)
5. will have some authentication expiry time: you will need to reconnect after a while (unlike most hotels eternal credentials)
6. won't be unique. Depending on the internal network size the load may be shared by several proxies, ideally placed on several physical sites (to avoid loss of connectivity in case of one physical site going down)

A consequence of 5. is that the proxy won't use a special private IP address (gateways on different physical sites won't even be in the same network ranges), and that auth may not be shared across sites (so the same URL can be freely accessible through proxy farm of site A, where the client already authenticated, and not proxy farm of site B, where it has not authenticated yet).

Therefore it is pretty much useless to hope to detect reliably the proxy by accessing another http URL in case of problems and hoping to get a captive portal. The other URL may not be filtered, or the browser/network stack may decide to go through a path where it's already authenticated, etc

This kind of setup worked fine in the past since IE6 was single-threaded, tried very hard to always pass through the same gateway IPs (leading to user frustration when the chosen path had availability problems and IE wouldn't switch to another), and didn't refuse to redirect https accesses.

A modern browser is much more likely to hit authentication requests, won't accept https redirections, so I don't see how it could be sanely handled except by design similar to the one the ietf specified. Please support that spec in chromium.
Mergedinto: 87100
Status: Duplicate
Project Member Comment 19 by bugdroid1@chromium.org, Oct 13 2012
Labels: Restrict-AddIssueComment-Commit
Mergedinto: chromium:87100
This issue has been closed for some time. No one will pay attention to new comments.
If you are seeing this bug or have new data, please click New Issue to start a new bug.
Project Member Comment 20 by bugdroid1@chromium.org, Mar 10 2013
Labels: -Area-Internals -Internals-Network Cr-Internals Cr-Internals-Network
Sign in to add a comment