At a high level HSTS (HTTP Strict Transport Security) is a policy that, when enabled, forces a browser to use an HTTPS connection over a HTTP and allows for the SSL certificate to be cached on the browser for a predetermined length of time. With HSTS enabled, clients are protected from protocol downgrading, man in the middle attacks, and cookie hijacking. Most modern browsers (Google Chrome, Mozilla Firefox, Microsoft Edge) come preloaded with a list of sites supporting STS (Strict Transport Security). Along with the pre-configured list built into browsers, developers can take it upon themselves to enable this policy on their sites. Once enabled a timeout will be sent with the HTTPS header that contains a HSTS TTL “
Strict-Transport-Security: max-age=31536000
”. The certificate received from the site will be honored until the timeout expires. Future attempts to access the site will reference the certificate and, if the certificate does not match, the browser will not allow the connection to site to be established.For a more in depth HSTS description check out Troy Hunt's post Understanding HSTS.
So how does HSTS break captive portals? HSTS enforces the use of HTTPS. It enforces this using two methods that where mentioned earlier the HSTS header or STS preload lists in the browser. When a user connects to a captive portal and launches their browser, normally the wireless controller would intercept their Internet request and a redirect is sent back to the client. This redirect to the captive portal will obviously be a different CN than their original request so, many times, this creates an SSL error. Many users have become numb; accepting the error and continuing to the portal. But HSTS is a little different.
Bottom line for users connected to a captive portal today:
- If the user visits an HTTP site, they are immediately redirected to the captive portal. This works regardless of what browser they are using
- If the user visits an HTTPS site that does not use HSTS, they receive a warning. If they click "Continue" they are redirected to the captive portal. This works regardless of browser
- If the user visits an HTTPS site that does use HSTS and they are using the browser that supports HSTS they are dead-ended. The only way to get redirected to the captive portal is to visit a different site. Many people have https://www.google.com or Facebook set as their homepage. Both of these sites use HSTS so this might confuse some users.
This issue of not being redirected to a captive portal affects every wireless vendor. As more and more sites use HSTS, getting a proper redirect becomes harder. Hopefully the wireless vendors are sitting on the working group for this new standard and are pushing hard to get it ratified.
In the long run, if something is not done, enterprises will quit using captive portals if it becomes really tough to get a proper redirect. But for now, being forced to use captive portals, I have not seen a sure fire technical way of getting around the issue. But you can get around the HSTS errors through communication and policy.
For example:
I am considering turning off HTTPS redirection all together. What this does is create a predictable environment for the users and the system admins. By not redirecting HTTPS you take the confusion of redirection issues based on SSL certificates, HSTS, or any new security the browsers builds in and level the playing field. Then in the case of using a sponsored portal, the email notification that is sent to visitor and/or person being visited can include the verbiage, "If you are not redirected to the guest portal please type a non secured HTTP website into your browser".