I recently read this question, which makes me wonder a follow up question: how is this captive portal likely trying to redirect the user? A highly voted comment does say that it's doing it wrong, after all.

So if one had a legitimate and well intended captive portal, how should it be redirecting users to the portal while keeping in mind user's security and convenience? It's obviously bad for both security and convenience if users are getting a certificate mismatch like in the linked question.

  • There is no good way to use captive portals, so try to avoid them as hell. Other than that mobile OS seem to do a decent job to work around them.
    – eckes
    May 1 '18 at 22:39

Technically a captive portal is always a man-in-the-middle attack. Therefore, all techniques against MitM will and should warn about them, giving the user power to decide whether to trust or not. Some browsers do have captive portal detection, in general temporarily allowing the redirection without showing any page with the original domain.

Contemporary security needs make transparent implementation of captive portals challenging. Thankfully, web browser and OS developers realize the importance of reporting the existence of this intermediate status between being connected to the Internet or not, this way reducing failure cases to a minimum.

From this perspective, redirecting to a separate captive portal login page with a properly signed and matching certificate would be less evil than showing the login page directly with any domain.

Do we have other options?

  • We could perform the redirect only on plain HTTP to avoid the certificate mismatch error. It would still be a MitM, but on a protocol that wasn't designed to detect it. This would have worked perfectly fine before HTTP Strict Transport Security (HSTS) against our protocol downgrade attack, which this kind of captive portal would be.

  • No redirection at all. Simply block all traffic before the user has manually opened the login page URL and logged in. Security maximized, at the expense of convenience. Now, you have to inform your users about this arrangement, which usually means need for extra support. Even if you tell your users with pictures that they need to type this address into address bar, some of them still tries to search the address from Google.

  • Abandon open WiFi and use another authentication methods. No need for captive portal nor login page. Severe need for support. WPA2 enterprise would be technically ideal as you don't need a single pre-shared key, but it's less known to the target group (people using open access WiFi).

At the same time these are the very reason why captive portals still exists. My idea of a suitable replacement for captive portals would be a standardized plain HTTP URL that browsers would try to access when ever something blocking the connection is detected. That page would then perform the redirect to the login page with HTTPS and a proper certificate, and the browser should detect anything else as an attack. But this is just my dream, far from reality. Captive portals will exist as long as they work in practice.

  • 3
    "...would be a standardized plain HTTP URL..." - there is actually a proposed standard intended to provide the needed information via a DHCP or Router Advertisement option - see RFC 7710. Only, it would need to be implemented at the clients :( May 2 '18 at 3:49
  • Nice! Using DHCP means it needs to be implemented at OS level, which makes it slower than any web browser implementation. Definitely a correct path and a wish come true! May 2 '18 at 5:09
  • Given that the browser is not the only application requiring network access (how about mail, VoIP,...) the OS is probably the correct place to care about this instead of expecting every browser and every other network application to somehow deal with it. May 2 '18 at 5:15
  • Sure. It makes the proposal much better, but making a major OS support it isn't as easy as making a major browser adapt new technologies. (My guess is we'll see this first on Android, and that's enough mass for others to follow.) May 2 '18 at 5:36

Unfortunately, there is no perfect solution here, given the fact that the very purpose of TLS is to protect against this kind of attack. But I think the best possible way to go is this:

  • For HTTPS connections, simply block them. Don't try to redirect. This will give the user an error message indicating no internet access rather than a security warning. That is better.
  • For HTTP connections, you should respond with 511 Network Authentication Required:

The 511 status code indicates that the client needs to authenticate to gain network access.


The 511 status SHOULD NOT be generated by origin servers; it is intended for use by intercepting proxies that are interposed as a means of controlling access to the network.

  • 2
    The 511 is a nice addition to be complete, but unfortunately the problem with HSTS domains not getting the response would persist. Indeed, there's no perfect solution that would match all the requirements for both security and convenience. RFC 7710, if widely accepted in the future, would be the closest. May 2 '18 at 11:34
  • @EsaJokinen Exactly. I'm not suggesting 511 solves the TLS problem.
    – Anders
    May 2 '18 at 11:37
  • Yes, it merely provides a protocol specified way to claim that this is not intended to be a MitM attack. May 2 '18 at 11:39

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.