0

Some captive Wifi portals require the ability to 301/302 redirect a user to an authentication / terms of service page before permitting access to the Internet.

This is at odds with SSL, which can't be cleanly intercepted by the typical coffee shop offering wifi services to customers. In this case users might get a SSL error when connecting to https://Facebook.com and the certificate is privately issued. Clearly a security no-no.

So now with Wifi + HTTPS, the connection will fail. Smart users can navigate to the "http://" version of the site to "trigger" the redirect, but that is no longer reliable with HSTS, and certificate pinning, since the portal redirect can't be sent.

With growing popularity of HSTS and pinning, many of the websites a user "guesses" will result in a browser error, and no redirection to the local authentication point.

Question

  • What is the ideal mitigation for this? Which specific best practices?
  • Should I consider no SSL on the naked/root, and www domain to perform redirections?
  • Should I have an entirely different TLD for HSTS?

I'm asking so I can make case-by-case usability vs security tradeoffs.

makerofthings7
  • 8,821
  • 28
  • 115
  • 196

3 Answers3

1

As for now, there's no way to cleanly redirect HTTPS. IETF is already working on a solution, and the first milestone is August/2018.

But Android and iOS will detect a captive portal and ask user to login, and Windows/MacOS users will receive a notification too. You can put QR-Codes around with the authentication portal, and people will look around the walls searching for help. Nothing can stand between teens and WIFI nowadays...

ThoriumBR
  • 5,272
  • 2
  • 23
  • 34
  • The IETF has finished work and there is now [rfc8952](https://datatracker.ietf.org/doc/html/rfc8952#section-2.2) linking to [rfc8910](https://datatracker.ietf.org/doc/html/rfc8910) for Captive-Portal Identification in DHCP and Router Advertisements – Rainer Rillke Nov 19 '21 at 08:36
1

I recommend against explicitly dealing with captive portal problems on the server side. Mobile devices include captive portal detection already as does Chrome and I think I've seen it in Firefox too. These existing mechanisms will recognize problems due to captive portals and give the user the ability to accept the necessary conditions etc inside a separate window or even app.

Steffen Ullrich
  • 12,227
  • 24
  • 37
0

It doesn't work. And it's getting increasingly difficult to get round this as more and more sites migrate to HTTPS and HSTS.

http://neverssl.com was explicitly set up to be a site to get round this, but it depends on the user knowing about this site.

On your site there is nothing you can do without explicitly sacrificing the security of your site (i.e. Turning off HSTS and hoping users don't bookmark HTTPS site).

Barry Pollard
  • 4,461
  • 14
  • 26