Slashdot Mirror


Firefox Extension HTTPS Everywhere Does What It Sounds Like

climenole writes "HTTPS Everywhere is a Firefox extension produced as a collaboration between The Tor Project and the Electronic Frontier Foundation. It encrypts your communications with a number of major websites. Many sites on the web offer some limited support for encryption over HTTPS, but make it difficult to use. For instance, they may default to unencrypted HTTP, or fill encrypted pages with links that go back to the unencrypted site. The HTTPS Everywhere extension fixes these problems by rewriting all requests to these sites to HTTPS."

29 of 272 comments (clear)

  1. noscript? by Cmdr-Absurd · · Score: 3, Informative

    noscript has a means of doing this on a per-site basis. Wildcards are accepted.

  2. NoScript has done this for years by Coopjust · · Score: 5, Informative
    http://noscript.net/features#options

    Preferences for enhancing HTTPS behavior and cookies:
    Force the following sites to use secure (HTTPS) connections - a space-separated list of site patterns

    Then again, if you don't trust the NoSript author after the controversy, this might be a good alternative. I figure NoScript is under more scrutiny than any other extension and the author learned his lesson.

  3. Default to HTTP? by SpazmodeusG · · Score: 5, Insightful

    Geez. What kind of poorly written site would do something like quietly defaulting to unencrypted HTTP on a HTTPS request.

    https://www.slashdot.org/

    1. Re:Default to HTTP? by Burz · · Score: 4, Insightful

      O RLY?

      Try using Slashdot (or most other sites) all day in an airport or at a cafe with your laptop, then see how long it takes for someone to start F-ing around with the Javascript that your browser is receiving in the clear. And then there are those lovely residential ISPs that screw with your web pages for not very different reasons.

      The EFF wants to see the web prepared for an assault that looks likely to intensify.

      BTW, there is such a thing as being too cheap.

    2. Re:Default to HTTP? by e2d2 · · Score: 3, Insightful

      You're shit out of luck because _we_ pay the bills here and _we_ build the websites so yes it's not being out of line to think that we should control how it's delivered. Take your entitlement to someplace that honors that currency. I'm a hacker too, but this whole "I want everything in the world my way" shit is getting old. Live with it, or don't. But it's not an "issue" in any way as far as I'm concerned. Don't like it? Go elsewhere.

  4. Much needed extension by Jojoba86 · · Score: 5, Informative

    Oh wow, this is awesome. I've used greasemonkey scripts with facebook but it's pretty ugly, seems to load the http page before the https page. This sounds perfect. Here's the link https://www.eff.org/files/https-everywhere-latest.xpi which is missing from TFS.

    1. Re:Much needed extension by Fnkmaster · · Score: 5, Funny

      Hmm... if you are trying to encrypt your communications with *Facebook* something tells me you are worrying about the wrong people getting their hands on your personal data.

  5. Does what it sounds like... by Nick+Fel · · Score: 5, Insightful

    ...except not "everywhere", just major sites.

    1. Re:Does what it sounds like... by Tim+C · · Score: 3, Insightful

      It can't be *everywhere* as not every site provides HTTPS access. You could go through a proxy, but that would only encrypt traffic between you and the proxy (and would of course introduce a potential bottleneck if it was a general-use proxy)

  6. Re:Link? by Anonymous Coward · · Score: 5, Informative
  7. Does What It Sounds Like? by Culture20 · · Score: 4, Informative

    It can't work unless these sites already have an https version. If they redirect all 443 traffic to 80 like /., then it does nothing. It might work for facebook since it has a couple pages that allow https, but I'm sure things like their photo servers are probably http only.

  8. firefox doesn't really make it easy for the users by roman_mir · · Score: 5, Interesting

    Firefox itself does not really make it easy for the users or for admins to use https everywhere.

    I just made a small site, it's for a business, that runs everything through https, I redirect http to https completely. Firefox 3.6.3 on Windows had no problem running the site. IE on windows couldn't open the encrypted pages, Firefox 3.5 on any GNU/Linux distro couldn't open them either, to fix this, I had to add this to /etc/conf.d/ssl.conf : SSLInsecureRenegotiation on

    That fixed the IE and FF3.5 on Linux problem.

    Here is the description of this flag from apache mod_ssl directive description page:

    SSLInsecureRenegotiation Directive
    Description: Option to enable support for insecure renegotiation
    Syntax: SSLInsecureRenegotiation flag
    Default: SSLInsecureRenegotiation off
    Context: server config, virtual host
    Status: Extension
    Module: mod_ssl
    Compatibility: Available in httpd 2.2.15 and later, if using OpenSSL 0.9.8m or later

    As originally specified, all versions of the SSL and TLS protocols (up to and including TLS/1.2) were vulnerable to a Man-in-the-Middle attack (CVE-2009-3555) during a renegotiation. This vulnerability allowed an attacker to "prefix" a chosen plaintext to the HTTP request as seen by the web server. A protocol extension was developed which fixed this vulnerability if supported by both client and server.

    If mod_ssl is linked against OpenSSL version 0.9.8m or later, by default renegotiation is only supported with clients supporting the new protocol extension. If this directive is enabled, renegotiation will be allowed with old (unpatched) clients, albeit insecurely.
    Security warning

    If this directive is enabled, SSL connections will be vulnerable to the Man-in-the-Middle prefix attack as described in CVE-2009-3555.
    Example

    SSLInsecureRenegotiation on

    The SSL_SECURE_RENEG environment variable can be used from an SSI or CGI script to determine whether secure renegotiation is supported for a given SSL connection.

    I wonder if there are other ways of making this work with my other directives:

    SSLEngine on
    SSLCipherSuite HIGH:MEDIUM:!aNULL:+MD5

    SSLVerifyClient none - I am thinking about switching it to 'require' right now, but will have to test all browsers with it again, but have to do it I think.

    Oh, and getting it all to run together with apache httpd with mod_ssl + mod_jk + apache tomcat is quite a hassle.

    But most unfortunate thing about FF is how it treats the self-signed certificates. It shows it as an SSL ERROR, to which exceptions must be made for the user to be able to enter the site. Can FF developers think about this fact for like longer than a second? It is not an error to run a site with a self-signed certificate, it is a configuration choice and it provides an important role to the site: encrypted traffic for login and for the data transferred to and from the client.

    Why is FF showing this to the users as an error? This is not an error, this is by design and it is a special case of usage. Who is not frustrated by the browser treating self signed certificates as if they are some sort of a disease? They provide an important role - a way to secure communications between the server and the browser.

    Can this be looked at, because I am SURE this prevents various sites from using encrypted traffic in the first place and it is a BAD thing, not a good one. All traffic needs to be encrypted, but especially user name/password traffic shouldn't be sent around in plain text.

    Name it what it is: an exceptional case of using security to encrypt traffic, a case where the site may not necessarily be what it wants to be seen as, but at least the traffic is actually encrypted. It's terrible if someone comes to your site just to see: SSL ERROR on it, OF-COURSE admins don't want THAT message to be shown on their sites, why do you think so few sites do security properly?

  9. forcing views of the hompage by SuperBanana · · Score: 5, Informative

    I don't care about ads on his site.

    I care about being forced to update NoScript every few days, each time being forced to load his site. I've got another extension, a Flash downloader that does the same thing. They're both either the world's worst programmers, or they're intentionally releasing updates just to drive traffic to their homepages.

    It's also incredibly irritating to get interrupted almost every time I go to restart Firefox!

    1. Re:forcing views of the hompage by Anonymous Coward · · Score: 5, Informative

      From the FAQ [http://noscript.net/faq]:

      2.5
      Q: I don't like NoScript redirecting the browser on its release notes page every time I upgrade it. Is there any way to prevent this?
      A: First time you install NoScript and every time you upgrade it to a newer major version, Firefox opens an additional tab containing the NoScript welcome page, where you can read the release notes, the latest announcements and an introduction to the most important NoScript features (plus a link to this very FAQ...)
      If you feel you don't need such heads up, you can disable this feature by clicking the NoScript icon, selecting Options and unchecking "Display the release notes on update" in the "Notifications" tab.
      Notice that if the above "fix" doesn't work or, worse, you keep being redirected on the welcome page every time you restart Firefox, chances are there's something (like a buggy extension) preventing your preferences from being saved: you may need to follow this advice, then.

    2. Re:forcing views of the hompage by Coopjust · · Score: 3, Informative
      http://noscript.net/faq#qa2_5

      Q: I don't like NoScript redirecting the browser on its release notes page every time I upgrade it. Is there any way to prevent this?
      If you feel you don't need such heads up, you can disable this feature by clicking the NoScript icon, selecting Options and unchecking "Display the release notes on update" in the "Notifications" tab.

      He's intentionally driving traffic to his page, but you can disable it easily (it used to require about:config, but it was a boolean that was fairly easy to find).

    3. Re:forcing views of the hompage by j.sanchez1 · · Score: 4, Informative

      about:config
      set noscript.firstRunRedirection to false

      --
      Speedy thing goes in; speedy thing comes out.
  10. Does NOT work for Slashdot.org by Anonymous Coward · · Score: 5, Interesting

    Unfortunately. No https for slashdot.org - why not Slashdot? Comments on politically orientated stories from "sensitive" countries does not deserve to be encrypted? You should know better Slashdot

    1. Re:Does NOT work for Slashdot.org by Lingerance · · Score: 4, Informative

      That's a subscriber feature.

    2. Re:Does NOT work for Slashdot.org by FriendlyLurker · · Score: 5, Insightful

      That's a subscriber feature.

      So to narrow down people posting politically sensitive stories (say, whistle-blower type stories) from a country, it is merely necessary to cross check banking records against payments to Slashdot. Slashdot should know better.

    3. Re:Does NOT work for Slashdot.org by ConceptJunkie · · Score: 4, Interesting

      It's not /.'s job to provide a secure means for posting politically sensitive stories. It would be nice if that's possible but that's not what they are in the business of doing, so I don't think it's fair to suggest /. "should know better".

      I'm sure they know perfectly well, and I'm sure that the decision support HTTPS this way is also an economic and technological decision. /. is a business, not a charity, and not a public service (although it provides public service as part of its business model). If /. advertised itself _primarily_ as a forum for free, uncensored speech or a forum for communicating with people in less free circumstances then it's a fair cop.

      It's one thing to suggest /. _should_ do this (and I think they should, all things being equal), but it's another to say (or imply) it is wrong for them not to.

      On the other hand, like Microsoft, busting on /. is fun and often justified, so I wouldn't mind piling on. They're such insensitive clods!

      --
      You are in a maze of twisty little passages, all alike.
    4. Re:Does NOT work for Slashdot.org by ultranova · · Score: 4, Insightful

      /. is a business, not a charity, and not a public service (although it provides public service as part of its business model).

      Every time I hear "is is a business, therefore it doesn't have to care about anything besides profit" I turn a little more to the left. Seriously, did CEOs mistake Soviet propaganda as instruction manuals or something?

      It's one thing to suggest /. _should_ do this (and I think they should, all things being equal), but it's another to say (or imply) it is wrong for them not to.

      If it's not wrong for them to not do something, then why should they do it?

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    5. Re:Does NOT work for Slashdot.org by FriendlyLurker · · Score: 3, Informative

      It's one thing to suggest /. _should_ do this (and I think they should, all things being equal), but it's another to say (or imply) it is wrong for them not to.

      You might be right. However we do not have to look far (e.g "Thailand Shuts Down 43,000 More Websites", or "FBIs Facebook Monitoring Leads To Arrest In England" both a few stories back) - to see that social network sites like /. are being sniffed, scanned, intercepted and profiles built up for normal citizens all around the world. 43,000 Websites have been shutdown or blocked in Thailand, and it would be naive to think they wouldn' also t sniff plain-text posted on those websites from Thai based IP's to identify problematic Thai citizens, who now may be on government watch list's - just waiting for a visit from local authorities, firing from Gov departments, or any other manner of persecution the regime see's fit to deal out.

      It might not be Slashdot's job or responsibility to offer even the most minimum technological security https offers to users - but it may reflect pretty poorly on Slashdot as a technology orientated social networking site - if they do not set a good example in the proper use of technology, who will?

  11. Self-signed certs are vulnerable to MITM by tepples · · Score: 5, Interesting

    It is not an error to run a site with a self-signed certificate

    A man in the middle could insert his own self-signed certificate, decrypting the traffic from your site and reencrypting it with his own key pair, and users would be none the wiser. One workaround is to start your own CA, sign its root certificate with PGP, and distribute that cert to your users to install. But then that starts to depend on the PGP web of trust, which in turn depends on air travel to get keys signed.

    1. Re:Self-signed certs are vulnerable to MITM by swillden · · Score: 4, Insightful

      It is not an error to run a site with a self-signed certificate

      A man in the middle could insert his own self-signed certificate, decrypting the traffic from your site and reencrypting it with his own key pair, and users would be none the wiser.

      So that just means that the site isn't secure. Fine. FF shouldn't display the lock icon, or color the address bar. But that's no reason to treat the connection as an error. The appropriate thing to do is to present the site as insecure (which it is), but to go ahead and encrypt the link. Ideally, FF should go one step further and use SSH-style server key history. Silently (or with a small "new key, do you want to accept it?" dialog) accept and use the self-signed certificate, and then puke hard if the certificate ever changes without good reason (i.e. old cert expired or was replaced with a proper certificate).

      By making these small changes, browser makers could significantly increase the average security of the web, so that sites that will otherwise have to go with unencrypted HTTP can use HTTPS -- even if MITM attacks are still possible, and if security shouldn't be relied upon, this sort of "opportunistic" encryption can make casual snooping significantly harder. That's a good thing.

      --
      Note to ACs: I usually delete AC replies without reading them. If you want to talk to me, log in.
    2. Re:Self-signed certs are vulnerable to MITM by roman_mir · · Score: 3, Interesting

      You are still missing the point. There is no SSL Error, there only needs to be an SSL Warning: self signed certificate.

      The users are given certificate numbers as well as user names / temporary passwords. They are instructed to check that the certificate is correct when the browser makes the connection or to install certificate if they can by themselves.

      --

      Every single person replying to me has completely ignored this issue:

      SSLInsecureRenegotiation on

      which is a much more important one - regardless of whether the certificate is signed by CA or not, the MITM is still possible and my business model actually fixes this but not technologically, it fixes it operationally.

      Nobody is talking about it here at all, looks like they don't get it. IE and earlier FF versions cannot even make the connection unless this flag is on.

  12. It is based on NoScript, in fact by Anonymous Coward · · Score: 5, Informative
    From TF (and missing) A:

    Our code is partially based on the STS implementation from the groundbreaking NoScript project.

  13. I see two things wrong w/ this... by HTMLSpinnr · · Score: 3, Informative

    1. For classic shared hosting solutions using name based hosting, I can almost guarantee if you hit https:///, you're going to hit someone else's virtual host. Many cheap hosting providers w/ limited public IPs will load up domain names on a single IP/Port, but still provide secure hosting to one domain name (on the same port) for shopping cart checkout under a different domain name. Using such a plugin in this use case would not work so well. Then again, would most "smaller sites" really be worthy of encryption in the first place?

    2. Not every site is designed w/ the same content root in http vs https. Switching from http to https may completely break if the file structures under the two virtual hosts (potentially entirely separate in Apache) aren't identical (i.e. pointing to the same directory). I'm not touting that this is a best practice, but would be completely feasable if you wanted to keep specific content from being accessed via http and didn't want to bother with mod_rewrite or equivalent.

    To the poster above who says there's little CPU penalty for SSL, SSL may not be taxing on the client, but hundreds or thousands of sessions on a server (especially one hosting an app, DB, and Apache) may be another story. Why is someone's assumed paranoid that someone will see that they're reading about cars or home theater equipment on a forum worth requiring a service owner to scale his hardware to the next level to maintain acceptable performance (assuming this phenomenon is multiplied hundred-fold)?

    --
    $ man woman *
    -bash: /usr/bin/man: Argument list too long
  14. mod this guy up by Sloppy · · Score: 4, Insightful

    How ridiculous is it, that people get their bank's identity vouched for by a third party they have never met and don't know anything about, when the bank could just put up a fingerprint sign in their lobby and on their paper statements? And people say using a CA is more secure, and less vulnerable to MitM? Really?!?

    --
    As copyright owner of this comment, I authorize everyone to defeat any technological measure which limits access to it.