Information Security Stack Exchange is a question and answer site for information security professionals. It's 100% free, no registration required.

Sign up
Here's how it works:
  1. Anybody can ask a question
  2. Anybody can answer
  3. The best answers are voted up and rise to the top

I have a security concern. As we know, many public hotspots redirect you to a login screen when you try to surf the first web site.

For example, if I connect to such a hotspot and then visit https://www.facebook.com (from a computer where I'm already logged in that site) I get redirected to the hotspot login screen, without any certificate warning in my browser.

Obviously, the initial HTTPS request made from my browser contains my session cookie ("Cookie:" HTTP header).

While doing the redirection to the login screen (ICMP or DNS based redirection), will the hotspot know my HTTPS request content, and so, my session cookie?

I assume that a malicious hotspot can read my first HTTPS request:

  • When the browser tries to connect to facebook.com:443, it will do the certificate handshaking;
  • The hotspot will reply sending a valid IP-based certificate, so, the hotspot will impersonate "facebook.com" and will read my original HTTPS request content;
  • After that, it may reply with a 301/302 redirect to the hotspot HTTPS login screen, without any warning in the browser client.

In this way, it will be possible for a hotspot to know the content of the first HTTPS request?

share|improve this question
    
I'd appreciate some tcpdump or browser's network console output (with personal information xxx-ed) as basis for a specific discussion. – try-catch-finally Jan 3 at 7:51
up vote 29 down vote accepted

If you visit HTTPS sites and get redirected without any warnings then the problem is that your browser doesn't correctly validate certificates - a good browser would display a warning as the captive portal's certificate does not contain the domain you wanted to visit in its common name field.

A possible vulnerability would be if you visit the site over HTTP, but there are solutions to mitigate this such as the Secure Flag on cookies that tell the browser not to send this cookie over HTTP - and HSTS which makes the browser automatically convert your HTTP requests to the site into HTTPS requests, in addition to preventing you from bypassing the certificate error if an HTTPS connection can't be made.

share|improve this answer
    
Additionally, if you were trying to load the site over HTTP but the site always redirects to HTTPS, that would not be a vulnerability - the captive portal could easily redirect you, but it also couldn't see your cookies since the browser would only send them over HTTPS. – immibis Jan 3 at 1:07

The behavior is browser dependent. If the browser will actually send the HTTPS request intended for Facebook to the captive portal, then it is clearly a browser vulnerability. But there are other ways to handle the situation.

I have recently had to use a network with a captive portal a few times. And in those cases I started Chromium which happened to have had a couple of Facebook tabs open from a previous session.

What happened was that a proper error message was displayed. But at the same time Chromium opened a new tab which accessed a specific HTTP URL with the actual intention to get hijacked by the captive portal. As soon as I was past the captive portal, the Facebook tabs would automatically reload and this time not get an error.

So it appears Chromium detects the presence of a captive portal, opens it safely, and finally detects once you are past the captive portal.

Similar captive portal detection exists in Android and iOS, though it is not tied to the browser but rather happens as part of associating with the access point.


I see a few misconceptions in your understanding of how captive portals are working. The captive portals I have come across certainly worked in a different way.

No interception was done for DNS traffic. As long as you used the DNS server provided through DHCP, your computer is allowed to do DNS lookups without restrictions without having accessed the captive portal.

No ICMP tricks are pulled either. Rather one of the routers on the legitimate path between your computer and the server will hijack the TCP connections to port 80. Once the TCP connection has been hijacked a redirect to the captive portal will be sent to the browser. In proper implementations this redirects to a HTTPS URL and somehow include information about the original URL such that you can be sent back there later. The entire communication with the captive portal is performed using a legitimate certificate for a domain name that actually belongs to the captive portal.

This approach works for HTTP - but not for HTTPS. The router performing the hijacking will not have a valid certificate for the site you are accessing, so in any secure browser you would get a certificate warning if the same hijacking was done for HTTPS.

There are three ways to get around this not working for HTTPS:

  • Rely on users ignoring security warnings and accepting that their private information will be intercepted even after being presented for a very verbose warning about the risk.
  • Rely on users understanding how it all works and on their own open an HTTP URL in order to be hijacked and then know to go to the original HTTPS URL after having passed the captive portal.
  • Let client software detect the presence of captive portals and deal with it appropriately. This still relies on the users being able to spot if a captive portal is attempting to perform phishing attacks, but at least doesn't leak any cookies.
share|improve this answer
    
Chromium connects to three random domains at startup in order to detect redirects on the network (source) - that may be the mechanism used by Chromium when it opens a new tab to the captive portal. – Benoit Esnard Jan 3 at 17:29
    
@BenoitEsnard That is not going to detect redirects by hijacking HTTP requests, which is how most captive portals work. The reason it won't detect those is that resolution of those random domains will fail, so there will never be an HTTP request to hijack. It can detect if something strange is happening to DNS, but I haven't seen any captive portals operate that way. – kasperd Jan 3 at 17:58
    
@BenoitEsnard DNS requests can be hijacked, but that's not what captive portals do. – kasperd Jan 3 at 18:29

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.