29

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?

  • 23
    Related: neverssl.com promises to never redirect or even support SSL, specifically to allow captive portals to redirect you away. – BoppreH Jan 30 '17 at 19:19
  • 4
    @BoppreH: Was example.com insufficient in some way? – Mehrdad Jan 31 '17 at 10:46
  • From what I see a lot of hotspots in the UK simply don't care about https traffic and serve them fine (meaning you can essentially use any https-only site), even before you could login on their http captive portal. – SztupY Jan 31 '17 at 11:43
  • @Mehrdad Sure, for a very simple reason: example.com doesn't make that promise at all. – Daniel Wagner Jan 31 '17 at 18:41
  • 1
    @Mehrdad in the unlikely event that "example.com" enables HTTP Strict Transport Security in the future, browsers will attempt to navigate straight to "https:// example.com" regardless if you typed "http://" or not. In that case you would get a certificate error. – BoppreH Jan 31 '17 at 19:03
27

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.

  • Yep. Safari uses a similar approach - their URL is captive.apple.com/hotspot-detect.html – ceejayoz Jan 30 '17 at 18:36
  • So they have a self signed certificate? But if thats the case I would get a warning right? Cause I dont – NULL Jan 31 '17 at 21:43
  • @NULL what OS/browser do you use? If your OS/Browser detect a captive portal, you will be redirected to the portal page, you will be redirected to the portal page without certificate warning. – Tom Jan 31 '17 at 22:02
  • @Tom I use Ubuntu/Firefox. – NULL Feb 1 '17 at 16:35
  • This doesn't really redirect though, it relies on cooperation from the OS or browser. – André Borie Feb 2 '17 at 22:27
27

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.

  • 1
    But I don't get a warning when I connect to the hotspot. I type google.com when connected to the hotspot and am redirected to their page without a single warning. – NULL Jan 30 '17 at 17:40
  • 16
    @NULL google.com expands to http://google.com, thus it is no encrypted connection in the first place. Google has only implemented HSTS (ie. connect via HTTPS immediately) on www.google.com. Thus a redirect from google.com is easily done. – GiantTree Jan 30 '17 at 18:00
  • 4
    @GiantTree If I type google.com on my hotspot I made with hostapd it redirects to https and says no valid certificate. – NULL Jan 30 '17 at 19:36
  • 3
    Perhaps this is a combination of the behavior of your browser, and the hotspot? I can imagine the browser might try http:// google.com, and if it ends in a redirect, go there - otherwise if it fails it could then also try https:// google.com. I'm speaking purely about possibilities though, I know nothing of the actual behavior of the different webbrowsers, only that something like that could be reasonable. – daboross Jan 31 '17 at 0:49
  • 2
    Browser plugins could make a big difference too. I'm thinking especially of httpsEverywhere (@DaboRoss) – Chris H Jan 31 '17 at 10:26
2

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.

1

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.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.