HTTPS Everywhere: Firefox plugin that switches on crypto whenever it's available

The Electronic Frontier Foundation and The Onion Router (TOR) project have teamed up to release a new privacy-enhancing Firefox plugin called HTTPS Everywhere. It was inspired by Google's new encrypted search engine, and it ensures that whenever you visit a site that accepts encrypted connections, your browser switches into encrypted mode, hiding your traffic from snoops on your local network and at your ISP. HTTPS Everywhere covers Google search, Wikipedia, Twitter, Identi.ca, Facebook, EFF, Tor, Scroogle, DuckDuckGo, Ixquick and other smaller search engines. It's still in beta (what isn't?) but I've been running it all morning with no negative side effects.

Encrypt the Web with the HTTPS Everywhere Firefox Extension (Thanks, Hugh!)

31

  1. It disabled my FB chat. Too tired to fool with it at the moment, so I’ll figure it out later.

  2. There is a certain amount of irony when I click on the EFF link in the article and my copy of Firefox displays this message:

    This Connection is Untrusted

    You have asked Firefox to connect
    securely to http://www.eff.org, but we can’t confirm that your connection is secure.

    Normally, when you try to connect securely,
    sites will present trusted identification to prove that you are going to the right place. However, this site’s identity can’t be verified.

  3. My problem with SSL is that (as I understand it) by exchanging crypto keys you positively ID yourself every time you use it. Not a problem for most users but if they are using TOR they probably want to have some plausible deniability. This will be great only when you trust the sites you visit.

    1. rebdav: SSL (or TSL) is about the server identifying itself. There are keys negotiated for the session, but when the session ends, *poof*, the keys are gone.

        1. It’s slightly more complicated than that; a properly configured client and server will indeed provide “perfect forward secrecy” that is immune to eavesdropping, replay attacks and session hijacks.

          If the client has a permanent key loaded (which is generally only true in corporate environments where the equipment owners specifically want to identify clients) the session keys are predictable, which compromises security in order to provide reliable identity. If the server’s keys are compromised (either purposely or not) you cannot possibly tell from the client side that you are subject to eavesdropping.

          And anyway, none of that matters if you want your oppressive government to be unaware of your surfing habits. Your IP address must be used in order for data to be delivered, and the enemies of freedom can trivially locate you by IP in close to real time.

          Just remember that free people are armed, and slaves are not. That’s your only real guarantee of free speech right there; a well-educated, well-informed, well-armed society has historically been the best hedge against tyranny. Too bad the USA has given up on all but the last of those three components… an armed, misinformed ignoramus may be free, but s/he doesn’t generally make any positive contribution to society really.

    2. @rebdav: That’s not how SSL works. Each side can present certificates unilaterally, and normal websites don’t ask clients for their certificates – you won’t even have a client certificate unless you’ve generated one.

  4. FB chat works fine now. I love it when things magically fix themselves without me having to do anything.

    1. Nasty, I’m having a little cognitive dissonance here. You are security conscious enough to want all your traffic encrypted and yet you are using Facebook?

  5. Great idea, but when running it you can’t get into your all of Google’s features. I had to deactive it.

  6. Note that encrypted connections use more CPU on both client and server, which will increase power consumption and hence CO2 emissions. Your secrecy has an environmental cost, albeit a small one.

  7. @Chesterfield It’s not necessarily a dissonance. The security-conscious people could be people like corporate network admins — and the FB users could be the network users (employees, etc.). That’s how it is in my office, anyway. We’re not allowed to go on FB, so they’ve blocked access to it (and a lot of other sites) with filtering software. Only, they forgot to block access to these sites via https connections. So, in my case, connecting this way is an easy way to get around our IT guy’s attempt to keep us away from many of these sites.

    1. There is some minor misinformation in the article you linked. For example, TLS and SSL are not the same thing, even though TLS implementations can and will fail down to SSL (if they aren’t purposely configured to prevent that).

      But the gist of it is correct: anyone who can introduce software on your client machine without your consent can compromise it without your knowledge.

      1. TLS is *mostly* SSLv3, so I won’t hold that as being “misinformation”, per se.

        Also of interest is a system called tcpcrypt (the paper is going to appear at USENIX this summer). The problem with TLS/SSL is that they are computationally expensive to implement on server, and harder to integrate with applications. tcpcrypt is trying to get what’s known as “opportunistic encryption” for everything that uses the TCP protocol for transport.

        I personally hope that it succeeds at its goals.

  8. Thanks for the tip, I blogged the story on my own blog too.

    Now why doesn’t Boing Boing offer encryption with this extension? :-)

  9. This would make me even happier if eff.org were DNSSEC-signed. I’m surprised they haven’t done that yet.

  10. Oh gods yes! I’ve been arguing that this needs doing for ages, but I thought that first there’d need to be an agreed HTTP header saying “Encryption Available” or something.

    With the UK government, and others, now legally requiring our ISPs to snoop on our web activities as a matter of course, I absolutely think this should become a standard part of browsers.

    And Boingboing should have an https version, of course.

  11. Not providing https to your viewers is like an ISP requiring their users to connect via telnet instead of ssh: it’s just insane.

    And yet, everyone does it… because everyone else does it.

  12. I hope Starbucks new ‘3rd home’ free wireless initiative uses https .. just imagine all those pw’s being vacuumed up by sniffers.

    1. Wifi encrypts at a lower level than web encryption: they encrypt the individual packets, rather than encrypting the data that the packets carry. So they don’t use https.

      I’m not sure completely open wifi can encrypt the data: I don’t know enough about the wifi protocols. My gut feeling is that open wifi = insecure wifi. This is supported by the warnings windows throws up when you connect to open wifi.

      1. Your gut is correct. Use only secure protocols when you are on an insecure connection; personally, I recommend tunneling everything to a known secured node over SSH. If you have the remote node’s SSH host key already loaded into your system (to prevent MitM) it’s safe.

        If people track your IPs they will think you are always in the same place, no matter where you really are, since your traffic will appear to come from your SSH host. It’s like using NAT from inside a large private network in that respect.

  13. Couple of things: Seems like you need a ruleset for each site you’re going to. This is a little unfortunate as I was hoping to discover sites that used encryption that I was previously unaware of.

    If that is the case then NoScript offers this option on the last page of their preferences for individual sites.

    Also, you could just bookmark the secure versions of these sites.

  14. I have developed a browser based Javascript encryption method and system that is
    100% secure (resists MITM, DNS spoofing etc.). The server side load is the same
    as HTTP (with no h/w devices etc.)

    The fundamental idea is to transmit encrypted content to a hidden HTTP iframe.
    Which then sends it to a HTTPS iframe using window.postMessage() (in HTML5) or
    via cookies. Since the HTTPS iframe is secure it cannot be tampered with, it
    also contains the decryption keys. The HTTPS iframe then proceeds to decrypt the
    message and renders it on the page.

    Please read (before you dismiss it is impossible!):
    http://www.research.rutgers.edu/~ashwink/ajaxcrypt/

    I am looking for Javascript and HTML experts to convert it into a library
    (LGPL).

    Thanks,
    Ashwin

Comments are closed.