Pillar: No-Code OSS
Are captive portals a security challenge?
The original World Wide Web, as envisioned by Tim Berners Lee, embraced openness. But since that effort to standardize ways to represent human readable data to the modern web, a lot of things changed.
The original World Wide Web, as envisioned by Tim Berners-Lee, embraced openness. But since that effort to standardize ways to represent human readable data to the modern web, a lot of things changed. The web now includes payment methods or websites that deal with sensitive information that require a secure channel of communication to avoid things such as credit card fraud. Also, some services offer anonymity and security on the web.
So from the mid 90’s to now, there have been standards to cope with data transmission security. First SSL was implemented by Netscape. Later TLS (both standardized by the IETF) became the accepted way to encrypt communications between computers. It was taken and adapted as a way of encrypting HTTP traffic and HTTPS was born.
When HTTPS was first released, it was limited to payment pages: banks, financial institutions, online shopping carts. Partly because it was where it was most needed, and partly because implementing it – both in processing power and an economic basis – was costly and slow, both for the server and for the client.
Nowadays, processing power is exceptionally cheap, so it’s not a major issue; we have in the palm of our hand the equivalent of supercomputers of the past at a fraction of the cost. Because of that and government regulations, more websites are implementing HTTPS by default. This trend causes the captive portals to struggle, as they cannot send encrypted content without triggering security alarms on the client.
Why Captive Portals are (often) not seen as security hazards
Captive portals get in the middle of a connection between the web browser and the destination server. Usually, they serve to communicate relevant information to network subscribers or to ask for authentication (i.e. a public Wi-Fi hotspot). Also, when necessary, to block other traffic (i.e. if the subscriber has past-due debt)
There are two main ways to intercept traffic:
- DNS spoofing – Tells the browser that the destination host resides on another IP address.
- Traffic interception – Redirects all traffic with destination port 80 from the subscriber to the captive portal host.
In cases where the destination website (requested by the browser) does not use encryption, the captive portal content is served without problems. It can simply serve the page as if it were the original server. But what happens when the website uses encryption? The answer is: It depends.
From a security point of view, captive portals are seen as man-in-the-middle attacks. Even if you use a valid certificate to serve secure captive portal messages through port 443, the web user will still get the certificate validation error. You couldn’t ever get a valid certificate for a domain that is not controlled by you. It’s the way that HTTPS is expected to work. Who’s going to put his personal data on a standard that allows anyone to pose as someone who is not?
In addition, HSTS, a relatively recent standard, allows websites served via HTTP to declare that all future requests MUST BE served from the secure version of the website. This mechanism allows browsers to avoid man-in-the-middle attacks cases that the request protocol is HTTP. For most sites, this works only if the browser has entered the site previously, and picked up the HSTS Headers. Some browsers nonetheless (such as Google Chrome), have a hard coded list of websites that are always requested via HTTPS. Then there is the reality: Captive portals do exist and are more common today, and should not pose a problem as long as they don’t break the security of the protocol.
Then there is the reality: Captive portals do exist and are more common today. They shouldn’t pose a problem as long as they don’t break the security of the protocol.
Browsers and operating systems have been implementing means of detecting if there is a captive portal in place, to warn users of original cause why the website is not working, instead of triggering a security warning.
Read part two of our captive portals series to learn what each browser and OS does to detect captive portals.