Every now and then, the question pops up from someone who has implemented a captive portal for his or her guests and the guests get these annoying security warnings:
How do we to get rid of these annoying warnings?
Let's start from the beginning. Captive portals are those welcome pages that you see if you connect to a Wi-fi hotspot when you are in a public place like an airport or your favorite fast-food restaurant. Why are we seeing these security warnings in our browser when using the hotspot? The short answer is that the web has rapidly adopted encryption. Recently, with a big acceleration after the Snowden revelations, we have seen an increase in websites that have moved to HTTPS (SSL Encryption). The reason for implementing HTTPS is to prevent eavesdropping, intercepting, impersonation and the alteration of website traffic. A Captive Portal works by intercepting, impersonating, and altering the connection between client and web server. So, in essence, a captive portal is a Man-in-the-Middle attack. It has good intentions, but it is a Man-in-the-middle all the same.
With a captive portal, the Wi-Fi solution (AP or controller) intercepts the connection that a user makes to, for example, Facebook or Google. The AP responds to the request as if it was the original website: it steps between the end-user and the official website. This is needed to let the user's web browser redirect to the captive portal page so the end-user sees the welcome page of your company and can accept terms or log in. This worked pretty well when Facebook, Google, and most of the internet still had their landing pages unencrypted (HTTP). On an unencrypted HTTP connection, you can intercept and impersonate without the end user even noticing. On a secure HTTPS session, you can't because the web browser detects that the connection was hijacked by something between the user and Facebook. The AP cannot present the correct Facebook web server SSL certificate with the result that the browser will pop up that security warning.
In the early days, Internet Explorer, Firefox, and even Chrome made it pretty easy to connect to a website that presented a bad certificate, even though this is a security risk. In fact, even big companies taught users to ignore security warnings, resulting in the fact that most users automatically clicked on the 'Yes, I know this is bad, I have been told this is stupid, but I'm clicking anyway because otherwise I don't get to my favorite funny cat movies, so I do anyways' warnings. Please note, security warnings and look and feel may differ per product.
Modern web browsers have made it more difficult to bypass those security warnings. You are now blocked and need to open an obscure menu item with 'other' or 'advanced' options to get to the 'ignore the warning' button and connect anyway.
This effectively makes a simple portal redirect practically impossible.
To make things even worse, sites can instruct your browser to only allow access if the connection is secure and all certificates match perfectly. This is called HTTP Strict Transport Security (HSTS), and works by adding a special header that indicates that a site uses HSTS. So your browser will refuse to connect on HTTP, and refuse access if there are issues with the certificate. The hidden option is disabled, making it impossible for the end-user to continue.
This HSTS completely breaks our HTTPS redirect for the captive portal for sites that implemented it. Many users will have their starting pages at Facebook or other big sites that have implemented this level of security. Basically, this means we can no longer use the captive portal redirect for HTTPS websites, and, very likely, that will only get worse in the future. A current workaround is to ask users to connect to a non-secure website, I use cnn.com for that, but this will only work as long there are enough non-HTTPS websites. This is a poor workaround, as it requires end-users to perform an additional manual action to make it work when all they want is their funny cat videos!
So what now?
Here are a few suggestions:
- Completely disable the captive-portal – I do realize that this is not the ideal solution you were looking for when you started reading this blog.
- Allow HTTPS traffic through the captive portal, and only redirect HTTP traffic. Might not be ideal as we just concluded that most of the big websites are migrating to HTTPS.
- Block HTTPS traffic instead of redirecting it. Yes, I know that many managers and customers request you to configure this, but in practice, it does more bad than good. From my point of view, it is better to have no (in)secure connection at all, than to get a security warning that most end-uses do not understand or even can get around. The captive portal detection in you operating system, you know, those automatic popup notifications that you need to log when connecting to a guest network, might eventually trigger and redirect you to the captive portal via HTTP.
Then there is a new standard in the work, RFC7710. This defines an extension to the DHCP protocol such that the captive portal location can be provided during the IP address assignment, eliminating all the guessing and probing that we need to do with today's captive portal detection. The current status of this standard is 'proposed', so it may improve things in the future. More on RFC7710 here.
Summary
You might have started reading this post with the hope that this post would have solved all your redirect warning issues. Okay, I know that may not be the case, but I hope now you have at least some understanding about what is causing these redirect issues and your available options.
If you want to disable the HTTPS redirect on your ArubaOS controller, go into the captive portal Firewall policy and remove the rule that does the redirect:
Same applies to the captiveportal6 for IPv6 or the derived policies that you may have made.
