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?

  • 25
    Related: neverssl.com promises to never redirect or even support SSL, specifically to allow captive portals to redirect you away.
    – BoppreH
    Jan 30, 2017 at 19:19
  • 5
    @BoppreH: Was example.com insufficient in some way?
    – user541686
    Jan 31, 2017 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, 2017 at 11:43
  • @Mehrdad Sure, for a very simple reason: example.com doesn't make that promise at all. Jan 31, 2017 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, 2017 at 19:03

5 Answers 5


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


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.

  • 1
    Yep. Safari uses a similar approach - their URL is captive.apple.com/hotspot-detect.html
    – ceejayoz
    Jan 30, 2017 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, 2017 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, 2017 at 22:02
  • @Tom I use Ubuntu/Firefox.
    – NULL
    Feb 1, 2017 at 16:35
  • This doesn't really redirect though, it relies on cooperation from the OS or browser. Feb 2, 2017 at 22: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.

  • 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, 2017 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, 2017 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, 2017 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, 2017 at 0:49
  • 2
    Browser plugins could make a big difference too. I'm thinking especially of httpsEverywhere (@DaboRoss)
    – Chris H
    Jan 31, 2017 at 10:26

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.

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.


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?

  • 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, 2020 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, 2020 at 0:11
  • At least in the United States, I'm not referring to security.stackexchange.com/q/213796/25009
    – ManRow
    Jan 30, 2020 at 0: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 1, 2020 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 1, 2020 at 17:11

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .