SSL/TLS and captive portals

Have you ever used public internet at an airport or a coffee shop? Perhaps you have to accept a terms of service before being granted access to the WIFI at your place of work? If so, chances are that you’ve used a captive portal

Captive Portals and SSL/TLS have a curious, and somewhat contentious relationship. After all, intercepting your traffic on the way to its destination is exactly one of the things SSL/TLS prevents! Captive Portals typically work in one of two ways, each with different downsides and limitations. Sometimes, Captive Portals work by handing out a local DNS server via DHCP and initially responding to all queries with the IP of a local server setup to answer the request. Other times, the interception is performed as an HTTP man-in-the-middle attack, usually at the routing level. In either case, if the first site a user hits is an HTTPS site, this poses a critical problem – the owner of the captive portal does not control the global DNS for that name, and thus the connection won’t be trusted! (Of course, if these are managed endpoints, a root certificate could be installed and a terminating SSL/TLS forward proxy could be used without throwing errors on the client-side).

Captive Portal owners are stuck between a rock and a hard place. Either they must ask that a user install a trusted root certificate in their browser (dangerous, and gives the network an inappropriate level of access to the machine), communicate out-of-band that a specific URL must be visited prior to using the internet (safe, but cumbersome) or assume the user will simply proceed past the SSL/TLS error.

As none of these are great options, many popular browsers have attempted to solve this problem in software. Google Chrome for example will make an HTTP request to clients3.google.com/generate_204 when you start your browsing session, in order to attempt to detect the use of a captive portal and display a click-through notification to the user. Apple products including iOS, iPadOS and MacOS with up-to-date software do the same by querying captive.apple.com/hotspot-detect.html. Unfortunately, this detection is spotty at best, and dependent on the captive portal’s implementation to behave in the way the browser detection expects. Additionally, this code path opens new and creative ways for bad actors to compromise machines, some of which may not have even yet been conceived.

Captive Portal implementations can sometimes be bypassed. Note that this information is provided for an academic understanding – don’t be a jerk and try to steal WIFI!

There was a really excellent DEFCON presentation in 2016 on this topic, one I recommend reviewing in detail. www.secplicity.org/2016/08/26/lessons-defcon-2016-bypassing-captive-portals/

Grant Bugher’s attack mostly relied on the fact that many captive portal implementations are lazy, and only block traffic identified as HTTP traffic. Simply by tunneling to something else via SSH (or using a DNS based tunnel like iodine code.kryo.se/iodine/, the traffic was allowed even though the user never made it to the captive portal! Enterprising captive portal makers can ensure their software isn’t bypassed by redirecting all DNS traffic to their own DNS server, and blocking outbound ports other than 80 and 443 for HTTP and HTTPS respectively. This has the added benefit of also making sure that DNS over HTTP or DLS over TLS won’t succeed until the captive portal allows full network access!

Unfortunately, Captive Portals have a long history of being incompatible with popular VPN solutions. It is always recommended that when using public WIFI to leverage a VPN solution which tunnels ALL traffic, to avoid prying eyes on the local layer-2 network segment. Over the years, VPN software, like browser software, has learned to accommodate Captive Portals, as they are unfortunately ubiquitous. For example, Cisco’s AnyConnect will prompt a user that a captive portal is in-use, and relax its requirement (if configured) that a VPN connection is established only until the user is past the Captive Portal. This is far from ideal.

Ironically, web browsers that perform the captive portal detection described above can get confused by forward proxies, such as the ones often used in the workplace! While the detection URLs use HTTP and not HTTPS, something like an explicit SOCKS proxy or a transparent HTTP proxy does not necessarily respond with the response to that URL the browser detection expects! In this case, your network administrator can usually configure an exception, but this can be an annoying problem.