32

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?

Community
  • 1
NULL
  • 503
  • 1
  • 5
  • 13
  • 24
    Related: http://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
  • 5
    @BoppreH: Was [example.com](http://www.example.com) insufficient in some way? – user541686 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
  • @DanielWagner: I mean you type it and either it works or it doesn't. As long as it works you don't need another one... – user541686 Jan 31 '17 at 18:53
  • @Mehrdad That's fine for interactive use, but programmatic access is simpler if you don't need to use a "guess-and-check" approach. – Daniel Wagner Jan 31 '17 at 19:00
  • 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
  • @DanielWagner: When exactly is it a good idea to programmatically connect to `neverssl.com`? What would you do with the response? – user541686 Jan 31 '17 at 19:32
  • @BoppreH: Read [my comment](http://security.stackexchange.com/questions/149852?noredirect=1#comment283473_149852) again. – user541686 Jan 31 '17 at 19:32
  • I just observed a new (to me) behavior: when visiting a https site on a captive portal, Chrome v73 opened a new tab with the portal login page. I'm presuming this is Chrome being smart and not some protocol. – w00t Apr 05 '19 at 13:00

5 Answers5

28

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.

André Borie
  • 12,706
  • 3
  • 39
  • 76
  • 2
    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 00: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
  • "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." I think Time Warner/Whoever They Are Now does this with profiles on mobile devices, correct? – Shawn Jan 31 '17 at 18:34
  • 1
    @ThatWebDude possibly, but installing a profile can be risky depending on what changes that profile causes to the system. I'm still waiting for a plain username/password, which would work everywhere (from my new iPhone 7 to `wpa_supplicant` on Linux). – André Borie Feb 02 '17 at 22:26
28

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.

Community
  • 1
Tom
  • 2,063
  • 12
  • 19
  • 1
    Yep. Safari uses a similar approach - their URL is http://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 01 '17 at 16:35
  • This doesn't really redirect though, it relies on cooperation from the OS or browser. – André Borie Feb 02 '17 at 22:27
  • @AndréBorie hotspot do really ask for a redirect with an invalid certificate, but hope for the cooperation of the OS. In the absence of cooperation, it's really a redirect. – Tom Feb 03 '17 at 09:27
  • There's no warning because there's no certs and no https. The test URL (testing for a hotspot) is http, not https. That can be redirected to any other http URL without any warning. If the hotspot wanted to run its captive portal page over https, it would need to deploy a cert for that page that the client would trust. This could be done if the hotspot operator purchased a cert from a CA for this. – Adrien Jun 14 '18 at 00:18
  • There are plenty of hotspots that are configured by some "genius" to let these special addresses through without redirection, to prevent the browser or OS from detecting that it is a hotspot. – gnasher729 Dec 12 '19 at 13:53
  • @gnasher729 when as a client you connect to such a hotspot and see an https warning you can use neverssl.com (a website that do NOT use https so the hotspot can redirect you without warning) – Tom Dec 13 '19 at 14:05
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.
user149408
  • 347
  • 2
  • 9
3

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.

gnasher729
  • 1,823
  • 10
  • 14
0

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?

ManRow
  • 401
  • 1
  • 4
  • 10
  • This would be a HORRIBLE, HORRIBLE idea, and break the internet, and that's not being dramatic. I could apply to be a "mini CA", prove that I'm "trustworthy", get approved, and pretend to be google, or facebook, or a bank, or any other website, and start scamming people by doing a MITM attack, defeating the entire certificate trust chain that the internet is based on. No one does this. Every modern browser, and OS (even mobile ones) has built-in captive portal detection that kicks in the second you connect to a new network, before you get the chance to visit an HTTPS site. – John Jan 29 '20 at 23:38
  • No, this would not break the Internet at all, since (1) this mini-CA is used only to redirect back to a *trustworthy* site, and (2) is operated by a *trustworthy* operator, i.e., Xfinity. Did you notice the emphasis on the word **trustworthy** ? Good, so you should know that you simply won't be able to become a CA at all --- from a *trustworthy* higher CA! But, please do have fun trying though, since you happen to think obtaining a "trusted CA status" is some kind of super easy trivial thing to do! Hint: if it was really that **easy**, the internet would have been "broken" a long time ago! ; ) – ManRow Jan 30 '20 at 00:11
  • At least in the *United States*, I'm not referring to https://security.stackexchange.com/q/213796/25009 – ManRow Jan 30 '20 at 00:34
  • We're talking about a *legitimate* and trustworthy company (an ISP is not just some random fake/scam operation!) operating a mini-CA just to redirect users to a *legitimate and trustworthy* website. If it was really that super-easy and trivial to become a "trusted CA" (certified by another "trusted CA" upstream!), then the internet would have *already* been broken a **long time ago**! Do you really think just anybody can be a trusted CA? Do you see how that would make the very concept of a CA completely useless? – ManRow Feb 01 '20 at 13:37
  • A mini-CA implies a looser process of proving you are trustworthy, or you might as well just become a CA. What you propose involves pretending to be google, or facebook, or anyone else on the fly. There's no way to do that in a limited way - you either CAN generate those certs, or you can't. You're essentially suggesting making it easier for people/companies to become a CA, and specifically allowing those CAs to pretend to be other domains, which no actual CA would do – John Feb 01 '20 at 17:11
  • The term mini-CA was invented by me to imply that they are not in the business of signing public keys for any customers (which is what a non-mini "regular" certificate authority does), but rather just only for themselves -- i.e., just that redirection response. It does not imply a looser set of requirements or make it "easier" for a company to be a CA. Are you really saying there is an **actual official definition** of what the term "mini-CA" means? Because otherwise you're obviously just making up some strawmen – ManRow Feb 01 '20 at 18:02
  • Perhaps you have a different term in mind instead of "mini"-CA? A non-mini regular CA is in the business of signing public keys for other entities. A "mini"-CA -- or feel free to invent another term (??) -- is a CA who's only purpose is to sign a redirection request (as coming from the user's intended target page) to the ISP portal. I called it a "mini"-CA, but perhaps there is a better term? It's not exactly signing someone's long-term public key *like a what a regular CA does*, so perhaps there's another term for it? How about, a "TLS-redirector-certificate-authority"? A TLS-RCA! – ManRow Feb 01 '20 at 18:27