Computers are increasingly mobile and, to serve them, more and more public spaces (cafes, airports, libraries, etc.) offer their customers WiFi access. When a web browser on such a network requests a resource, it is implicitly trusting the hotspot not to interfere with the communication. A malicious computer hooked up to the network could alter the traffic, however, and this can have some unpleasant consequences.
HTTP Man-In-The-Middle (MITM) attacks
Consider your typical online banking session: you type “www.mybank.com” into the address bar, hit enter, and wait for the site to load. When it shows up, you enter your password, do your banking, then log out. This process is more-or-less automatic for many people, and the subtleties of the process disappear in the background. More specifically, these are the steps for logging into the bank’s site:
- You type “www.mybank.com” into the address bar and hit enter.
- The browser assumes “www.mybank.com” should be requested over HTTP by default, so the initial request is unencrypted.
- The server at “http://www.mybank.com” responds with an HTTP redirect to “https://www.mybank.com”
- The secure connection is established, and a login page is served via HTTPS.
- You enter your password and do your banking.
It is only after the first few swift (and often unnoticed) steps that the user is presented with a secure connection. In a rogue hotspot, “www.mybank.com” might resolve to an attacker’s server (instead of the real thing) and the HTTPS connection may never happen. Many users might not notice this and end up logging into an attacker’s website.
HTTPS is intended for both channel encryption, to thwart eavesdroppers, and for server authentication. In the hotspot banking MITM situation, you may simply assume that no errors indicates a safe connection but in all reality the server has not been authenticated! After all, you’re not presented with any warnings or UI indicators saying the site is an attack site. If you’re a diligent user, you can always click Firefox’s site identity button to find out whether or not the site has authenticated itself and whether it’s encrypting to prevent eavesdropping, of course. It’s hard to remember (and time consuming) to do that every time, especially when you’re used to logging into certain trustworthy sites automatically. And in fact, a fake bank’s site may even have a little lock icon next to the login box that assures the user he is logging into a secure site — many legitimate banking sites unfortunately do the same thing.
Asking the Browser to use HTTPS Only
To stop this kind of man-in-the-middle attack, where an HTTPS site is mimicked over HTTP, Collin Jackson and Adam Barth proposed something called ForceHTTPS in 2008. This is a browser feature that allows web sites to tell a browser to always request it via HTTPS, and never unencrypted HTTP. It was intended to help eliminate the redirect from HTTP to HTTPS and minimize the chance of an insecure attack as described above.
We like the idea of ForceHTTPS and are working on implementing it as “ForceTLS” in Firefox with hopes it will reduce occurrences of MITM attacks and generally improve user security. We built an add-on as a first step prototype of the feature that works in a similar fashion to the original design by Jackson and Barth. Instead of using cookies, however, we’re asking sites to send an HTTP header “X-Force-TLS” with any securely-transmitted response. The name of this header will change in the future, but for now we’re using “X-Force-TLS” as the experimental header that, when present, means:
- The browser should only attempt to access that domain via HTTPS
- How long this requirement should last. For example, a server can ask the HTTPS-only request to expire after three days. This expiration timer can be reset or changed every time data is served to the client by providing a new HTTP header.
- Whether or not subdomains of the requested site (images.mybank.com, or login.mybank.com for example) should also be forced into HTTPS
ForceTLS can be used for more than just protection against evil hotspots; it can also be used to harden web applications against accidental unencrypted requests. Many popular web apps can be used over both secure HTTPS and insecure HTTP connections; while you’re given the choice to pick HTTPS instead of HTTP, it’s possible that a large web app might have a HTTP URI referenced from some subtle corner of its code (by accident of course), and with Force TLS employed, this would quietly get upgraded to HTTPS and prevent exposing any unencrypted data on the network.
Check out our prototype, and tell us what you think! The browser extension and source code are available on AMO (https://addons.mozilla.org/en-US/firefox/addon/12714).
Sid Stamm
Securinator
Ken Saunders wrote on
David Illsley wrote on
Daniel Veditz wrote on
hugo wrote on
jmdesp wrote on
hugo wrote on
voracity wrote on
voracity wrote on
Ivan Ristic wrote on
Daniel Veditz wrote on
Daniel Veditz wrote on
hugo wrote on
Sid Stamm wrote on
David Dreghorn wrote on
David Dreghorn wrote on
David Dreghorn wrote on
Sid Stamm wrote on
David Dreghorn wrote on