Mozilla Security Blog
Categories: Firefox Security

Locking up the valuables: Opt-in security with ForceTLS

mozilla

18 responses

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:

  1.   You type “www.mybank.com” into the address bar and hit enter.
  2.   The browser assumes “www.mybank.com” should be requested over HTTP by default, so the initial request is unencrypted.
  3.   The server at “http://www.mybank.com” responds with an HTTP redirect to “https://www.mybank.com”
  4.   The secure connection is established, and a login page is served via HTTPS.
  5.   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:

  1. The browser should only attempt to access that domain via HTTPS
  2. 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.
  3. 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

18 comments on “Locking up the valuables: Opt-in security with ForceTLS”

  1. Ken Saunders wrote on

    Fascinating. Thanks for continuing to look out for us all. Force-TLS AMO page loaded.

  2. David Illsley wrote on

    It’s an interesting and attractive approach, particularly because it’s so simple.

    It does still have a bootstrap hole, which with private browsing (which presumably has to prevent information from previous sessions leaking into the current one) turns into a reasonable size problem.

    I’m therefore hoping that in parallel, there can be a ForceTLS extension to DNS developed which could (over time, with the deployment of DNSSEC) close that bootstrap hole.

  3. Daniel Veditz wrote on

    I don’t believe the add-on currently takes private browsing into account. It would be consistent with other features if when in private mode we continued to use previously-saved ForceTLS state and didn’t write to disk the result of any ForceTLS headers we encounter while in private mode.

  4. hugo wrote on

    The problem with this approach is that firefox will know that site must be accessable only via https after redirect from http version (in case it is not tampered).

    I would propose to use of domain .bank which would be accessable ONLY over HTTPS and ONLY with trusted certificate. The problem is that other- non-banking sites would like to use such feature. Perhaps use of distinct browser mode for https-only access wouldn’t be such a bad idea…

  5. jmdesp wrote on

    I doubt this will really work as described.
    Most site don’t want to use SSL on all the site. They want to use SSL only on the login screen. It can be on a dedicated host and have ForceTLS but then the MITM can still easily direct you to his bogus login site.

    The way forward is to convince those sites to go all SSL. But this won’t be easy. I think the only way is if one of them starts and advertises that successfully as a competitive advantage.

  6. hugo wrote on

    FireFox should fix two things:
    1) Show warning (or just block) when page tries to load mixed content (like IE does)
    2) Force same origin policy to take protocol (http/https/ftp) into consederation.

    Sure this will break sites, but they will get fixed. FireFox has too big userbase to lose.

  7. voracity wrote on

    Interesting. What if, in response to ‘www.site.com’, you issued *both* requests, http and https, and took the one that responds first without a Location: header? You could optimize subsequent requests by remembering what the site did last time (unless a header directs otherwise).

  8. voracity wrote on

    Hmm, no, recanting the suggestion because it’s the same as ForceTLS, only hacky. The key problem is that we don’t know if the request is for a secure site or not, and they can both be spoofed (in the case of https, it can be spoofed as being non-existant, so validation can be avoided).

    What if we introduced a standard domain prefix like ‘www’ or ‘ftp’, but for https only. Maybe just ‘s’ would suffice? e.g. s.mybank.com. Then we know we should only look for secure sites, and no spoofing or anything else is possible full stop (even if this is the first visit to a secure site, or in a private browsing session, etc.)

  9. Ivan Ristic wrote on

    I think the basic idea, that some sites must be SSL-only, is sound. However, if implemented on its own, there will inevitably be ways to bypass it. Today we have too many components doing their own thing, breaking for others security in the process.

    Several years ago I had this idea of introducing what I called “Secure Browsing Mode”, which is a series of measures that makes web applications again. One of the proposed measures was to require SSL for applications that aim to be secure. Another, to make session hijacking impossible. Another, to make CSRF impossible. And so on.

    Our main weakness is that today there is no such thing as an web application. We only have a set of pages that work together, with some negative security measures (same-origin policies) in place that prevent just any page from interacting from any other page. We need to make web applications first-class citizens on the Web. We need to make it possible to define them, and allow them to control their space, which includes controlling how browsers interact with them too.

    By making the additional security elective we would allow security-conscientious applications to be more secure, and avoid breaking the Web at the same time.

    Perhaps the Mozilla team could have a look at the ideas and see if some of them are worth implementing:

    http://www.modsecurity.org/blog/archives/2006/06/secure_browsing.html

    Direct link to the PDF:
    http://www.modsecurity.org/blog/archives/Secure_Browsing_Mode_Proposal.pdf

    Some of these ideas are being implemented but, again, since the work is done independently, we are not going to benefit to the level we could if the whole thing were designed at once.

  10. Daniel Veditz wrote on

    @hugo: welcome to the bootstrapping problem. We’re making the assumption that the sites people most want to protect from eavesdropping and tampering are those for which they’ve set up accounts. That means they connected correctly at least once, and this header could be set at that time. In addition, careful users could always add “https://” themselves the first time and avoid that initial redirect.

    If a .bank TLD gets set up with the properties you propose we can happily support that, too. The two mechanisms could coexist easily.

    Information stored in a signed DNSSEC record would be another way to communicate this information, but again, that means getting another big technology off the ground before we could build something like this on top of it.

    As to your other comment: I, too, would prefer blocking insecure content over falling back into insecure “mixed” mode, and the same-origin policy already takes scheme into account. To the browser http://foo and https://foo are different sites. To the site, however, it might be the same content with different entry points and of course attackers will flock to the unguarded entry.

  11. Daniel Veditz wrote on

    @jmdesp: We agree, this mechanism is useless for sites which are more concerned about SSL overhead than user safety. Or less snarky, there are already sites which have made the choice to go all SSL, but they still have to worry about their users getting hijacked through that first contact on an insecure network. Important sites like PayPal, Wells Fargo Bank, GMail (if you’ve set the SSL pref), even our own Mozilla Add-ons site. For sites which have already made this investment this feature would make sure it’s not for nothing.

  12. hugo wrote on

    “To the browser http://foo and https://foo are different sites.”

    However, not for cookies, right? 🙂
    Even if you *manualy* can make SECURE cookie not to be sent to http:// version, http:// version still can set cookies sent to https:// version.
    This should be fixed.

  13. Sid Stamm wrote on

    @Daniel Veditz: I just finished adding support for private browsing mode in version 1.0.3 of the add-on, and as soon as it is reviewed by AMO, it will be available for download. (If you can’t wait, it’s available at http://forcetls.sidstamm.com/).

  14. David Dreghorn wrote on

    It might be because I am not the quickest of people when it comes to IT, but I can not tell if there is any difference. I added the add on, and restarted Firfox to see if it would make any difference to the page, it was still http, not https. When I put in https to the site address, I then got the encrypted version.

    If we have to put https in, what is the use of the add on?

  15. David Dreghorn wrote on

    It might be because I am not that quick when it comes to IT, but I can not see any difference. I added the Add-on, but it dont not seem to make any difference as I still got the http version, not the htpps. To get the https version, I had to type in htpps.

    Is there any point to the add-on if we still need to type in htpps? Will this not cause some people to be vulunrable? If people add the add-on and all they get is the http login, they might just think that this is the only page they can get and just type their info in and not look for the https verision, after all if there is one, the add-on should have taken them to it.

  16. David Dreghorn wrote on

    My last 2 comments were deleted, is there a reason fthey were deleted? The first time I put in my web address and the comment was delted, the 2nd time I left it off but thee link was still there if you clicked on my name (no idea how that happend).

  17. Sid Stamm wrote on

    @David Dreghorn:
    If you think the add-on is not working as expected, or there’s a bug, please email the support email address for the add-on listed in AMO (https://addons.mozilla.org/en-US/firefox/addon/12714) and we’ll work with you to fix it.

    Force-TLS doesn’t ‘upgrade’ *all* web sites to HTTPS: it will only upgrade sites that have told your browser they want to opt in, or those sites you have manually entered into the add-on’s settings. Since this is a prototype and very new, I don’t anticipate many web sites yet tell your browser to upgrade them.

  18. David Dreghorn wrote on

    Cheers for the reply (I’m not the most patient of people, ssorry about that).

    I will leave the add on on, I guess we will have to wait a bit for the websites to catch up, hopefuly they will see this as a excelent chance to improve user safety/security.

    Sorry for the double posting.