How Legitimate Wifi Hotspots redirect https requests

Question

I have been looking into how https and ssl protect the user from captive portals.

If a client tries to access https://www.google.com and the hotspot does not provide a valid certificate it prevents the user from connecting.

How then do hotspots like xfinitywifi redirect all requests, https or not, to their login page? They have a certificate for wifi.xfinity.com but not for google so shouldn't the browser not connect?

EDIT: The answers below are very informative and I have learned a lot but I still do not understand this aspect: in my case with Xfinity hotspots the user does not have to ignore a warning because there is none.

It seamlessly transfers https sites to its own login site without warnings. I know that the test site that I go to is https. Why is this?

Answer 1

Most hotspots redirect with invalid certificates.

Browser/OS use heuristics to detect that behavior.

This determination of being in a captive portal or being online is done by attempting to retrieve the webpage http://clients3.google.com/generate_204

https://www.chromium.org/chromium-os/chromiumos-design-docs/network-portal-detection

MacOS and iOS use http://captive.apple.com/hotspot-detect.html (thanks @ceejayoz )

For example, android will display a notification to redirect the use to the portal login page.

Answer 2

Most of them just use their own hotspot certificate and hope the users click through the warning and connect anyway. Personally when I see such a warning and I know it's a captive portal I cancel the request and type in an HTTP URL I do not care about such as http://redirect.me.away and let the portal do its thing over HTTP. Once logged in, I retry my HTTPS request which now works.

Most of the time, I avoid them though - filling up their stupid signup forms isn't worth my time, especially given the often poor connection they offer. Maybe one day we'll have an EAP-Enterprise hotspot network where you register once and then your device connects automatically with an username/password and it all operates seamlessly in the background.

Answer 3

Captive portals essentially act as a man-in-the-middle, redirecting client requests to a different site (their login page). Technically this is the same kind of behavior that HTTPS tries to prevent, because that’s what the bad guys do on unsecured HTTP connections.

Thus, when you can connect to an HTTPS site from a captive portal without a warning and without having logged into the portal before, one of the following has happened:

1. The captive portal does not intercept SSL traffic but allows it through. As a result, you are served the target page immediately, without ever having loged in. However, from the provider’s point of view, that largely defeats the purpose of having a captive portal in the first place.
2. One of the CAs in your trusted CA list, or a sub-CA verified (directly or indirectly) by one of those root CAs is rogue (or got hacked—though the latter is unlikely if the WiFi operator is even remotely legit). As a result, the hotspot either has a wildcard certificate (matching any server name) or can issue arbitrary certificates which are accepted by your browser. As a result, you type in an HTTPS URL and instead get the login page without any warning.

The second example is an inherent weakness in the design of certificates: your browser/OS vendor (or, in the case of company devices, your system administrator) has deployed a CA certificate on the machine, essentially claiming “this CA will never issue certificates for any server to anyone other than the legitimate operators of that server). Unless you verify each CA manually and remove questionable ones (which is nearly impractical for an individual), you’re blindly trusting their assertions.

If none of the above two cases apply, one of the following would happen:

1. The connection would fail (due to an unreachable server) until you connect to a plain HTTP server, get redirected to the login page and log in
2. You would receive a warning about an invalid certificate: either the server name does not match, or because the certificate is not from a trusted CA. If you ignore this warning, you would get the login page.

Answer 4

There's one thing the captive network can't do: Redirect to its own page while returning the correct server certificate. In principle, there are those possibilities: (a) not redirect https at all. (b) redirect with a self-signed certificate. (c) return its own certificate, so https negotiation will fail. (d) immediately kill any connection attempt with https.

Since switching networking code on iOS from http to https, I found more than one captive network immediately killing any connection attempt. That would be a rather strong indication to an application that there is a captive network. The application can then use better detection by visiting one of Google's or Apple's URLs that are provided for this purpose and if they don't respond as expected, then you definitely have a captive network. The application can go from there and launch a browser or let to user go to settings.

I don't know what browsers do exactly, but they can detect that https was rejected, and automatically visit an http page that goes to the login site.

Answer 5

It's possible Xfinity simply operates some "mini" certificate authority (CA) somewhere who's sole purpose is absolutely none other than to sign an auto-generated redirect

HTTP/1.1 302 Found
Location: https://wifilogin.xfinity.com

(on-the-fly) as belonging to whatever https://<some-website> the user originally intended to access.

So, for example, if an Xfinity-unrecognized device attempts to access https://www.google.com via some xfinitywifi access point, Xfinity will simply send them that HTTP response signed by that "mini" CA as if it was legitimately from the "real" google.com. Once the user logs in and Xfinity recognizes his/her device, internet service simply resumes as usual...

**Edit: Could operating a "mini-CA" for such a limited role/function pose some kind of significant security risk?