Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×
Firefox Electronic Frontier Foundation Security Social Networks News

HTTPS Everywhere Gets Firesheep Protection 77

Posted by timothy from the mitigating-malicious-mutton dept.
coondoggie writes "The Electronic Frontier Foundation today said it rolled out a version of HTTPS Everywhere that offers protection against 'Firesheep' and other tools that seek to exploit webpage security flaws. Hitting the streets in October, Firesheep caused a storm of controversy over its tactics, ethics and Web security in general. Firesheep sniffs unencrypted cookies sent across open WiFi networks for unsuspecting visitors to Web sites such as Facebook and Twitter, and lets the user take on those visitors' log-in credentials."
This discussion has been archived. No new comments can be posted.

HTTPS Everywhere Gets Firesheep Protection More

HTTPS Everywhere Gets Firesheep Protection

Comments Filter:

  • Does wikipedia work with HTTPS Everywhere now? I had to disable it because of all the 404 error messages I was getting.

    • I did not have problems with accessing Wikipedia, ever. However, the suggestions feature in the search box for Wikipedia as well as Google stopped working ever since 0.2.2 (for me, anyway). 0.9.0 has not rectified this situation.

  • Duh? (Score:3, Funny)

    by girlintraining ( 1395911 ) on Wednesday November 24, 2010 @08:43AM (#34330302)

    Wait, unencrypted signals sent over the air with your password and login is bad? If only someone had told me... /snark

    Seriously though: Unencrypted. Open. Network. Come'on guys.

    • Re:Duh? (Score:5, Informative)

      by The MAZZTer ( 911996 ) <megazzt.gmail@com> on Wednesday November 24, 2010 @08:46AM (#34330326) Homepage
      Firesheep never used login credentials. It never needed to. Session cookies were enough to impersonate another user... so any visit to any HTTP page on any site allowed a Firesheep user to impersonate you on that site in theory (of course if you're logged out this is of limited use, but if you're logged in they can impersonate you without login details).

      • Re: (Score:2, Informative)

        by leptechie ( 1937384 )
        The extension forces requests to be sent over SSL/TLS for all communication, as long as the site supports it. Works on Facebook, even Google searches, so yes this is a useful countermeasure. Of course, it is wholly dependent on the site supporting HTTPS in the first place.

        I've tried similar extensions, and Facebook gladly connects over HTTPS when manually instructed to, but reverts to normal HTTP on pretty much any click, this just keeps the connection on HTTPS regardless of the link target. The only downsi

      • Does that work for Google, too? In other words, can you simply use the session cookie sent when performing a Google search to log into a Gmail session? The former is typically http, the latter https. I'm aware that you can use https for searching, too, I'm just wondering. Isn't there some kind of policy that segregates https cookies from http cookies?

        • Having used firesheep myself, I can tell you that it doesn't work to login to gmail. I was able to sniff my own google account (using a separate computer), but was not able to get past my iGoogle homepage. Attempting to go to gmail prompted a login, even using the firesheeped session cookie. I think I may have tried google docs too, and it also required a login, but I am not sure about that one.

          • Re: (Score:2)

            by Lennie ( 16154 )

            Their is also a bug in Chrome when you start up it will connect to the google.com-domain to check for updates and do so over HTTP and the problem with this is, it will also send the normal cookies associated with google.com. Which might give the attacker enough information to get into your igoogle/gmail account.

    • Re:Duh? (Score:5, Informative)

      by blueg3 ( 192743 ) on Wednesday November 24, 2010 @08:53AM (#34330386)

      Many of the sites that Firesheep attacks use HTTPS for their login, so you don't send your credentials in the clear, but fall back to HTTP for delivery of content. The point Firesheep attempts to make is that this is not sufficient -- your unencrypted HTTP requests contain the session cookie that your encrypted login obtained. The session cookie is just as useful, as long as you make use of it "soon".

  • Stated simply, many web sites just can't handle https.

    • Re:Probably breaks lots of web sites (Score:5, Informative)

      by oodaloop ( 1229816 ) on Wednesday November 24, 2010 @09:04AM (#34330468)
      Um, no. That would be pretty dumb. IF the site has an https page, it directs to that. If not, it doesn't.

      • HTTPS take more processing power to encrypt and decrypt the traffic, frequently enough traffic flowing through marginally usable server will completely crash and burn if all of the traffic were encrypted; it's like normal traffic would cause a site to be /.ed.

        • HTTPS take more processing power to encrypt and decrypt the traffic

          This might be a valid concern for static web pages. But the sorts of web sites with which one would use TLS are more dynamic, to the point where they might be called web applications. How much processing power does HTTPS use compared to what the PHP/Python/Perl/Java app and the database use?

          • it's always in addition to what the PHP/Perl/Python/Java uses. On say slashdot you have multiple servers sliced horizontally so each section can be on a separate server if desired as well as vertically so you have web-servers on the outer layer, Database caches in the middle, and the database itself on the inside; or on other sites you have the web-server and database server all on a host shared by ten or twelve virtual hosts. The load that a slashdot can service probably wouldn't be much of a problem going

            • it's always in addition to what the PHP/Perl/Python/Java uses.

              But how much addition? Would HTTPS increase the CPU load of a typical PHP blog, forum, or wiki engine by 1%, 10%, 100%, or more?

              • SSL uses strong cryptographic encryption, which necessitates a lot of number crunching. When you request a webpage via HTTPS, everything (even the images) is encrypted before it is transferred. So increased HTTPS traffic leads to load increases. Why does my webserver have a higher load, now that it serves SSL encrypted traffic? [apache.org]

                All servers will display an increased load how ever

                In my experience, servers that are heavy on dynamic content tend to be impacted less by HTTPS because the time spent encrypting (SS

                • Re: (Score:2)

                  by Lennie ( 16154 )

                  Yes, a higher load, but the load will only be increased by a very, very small marinal number. Just have a look at what the Google study had to say about it.

                  With the right extension we could even speed up loading of the webpages:

                  http://www.chromium.org/spdy/spdy-whitepaper [chromium.org]

                  Because HTTP does not currently do multiplexing of multiple streams over the same TCP (or TCP/SSL) connection. The only solution that is has is to open several connections and because we need to use TCP-slowstart it can't utilize the availa

      • That sounds like a big opportunity for a man in the middle to tell you your site doesn't support ssl. That's still fine against passive listeners, but wouldn't it make more sense to it like flashblock and noscript do? Force ssl by default, and if that doesn't work ask the user if he wants to go with plain http. That would at least give you the opportunity to say, "Gee, gmail usually has ssl ..."

  • How does HTTPS Everywhere do it? (Score:3, Interesting)

    by Bromskloss ( 750445 ) <auxiliary.addres ... nOspAm.gmail.com> on Wednesday November 24, 2010 @08:50AM (#34330360)

    Does it parse the webpage you are on and rewrite every link to use HTTPS or, better, does it intercept every request Firefox makes and rewrite that before it is sent?

    The reason I'm interested is that I want to create an extension that does rewrites in the latter way described, but don't know how to do it.

    • It's pretty simple, you can often force https simply by typing it in the address bar, if the site has some kind https cert set up, it'll bring you to a secured version of the site. https://twitter.com/ [twitter.com] works and brings to twitter securely, as it does for many mail sites. All you have to do is add a character the html string, which isn't that complicated. For it to really be secure, the server administrator has to secure their site.

    • Re: (Score:1)

      by Kozz ( 7764 )
      If you don't find your answer in forums, there's nothing stopping you from looking into the extension yourself, in most cases. Take the XPI file,change the extension to .zip (presuming you're in windows) and extract its contents. View source of the .JS files, and there you have it.

    • Re: (Score:1, Insightful)

      by Anonymous Coward

      It does the latter. Requests are intercepted and converted according to pre-defined and user-definable rulesets before being sent.

  • SSL = Great
    SSL + some 600 MITM-Orgs your browser "trusts" = Bullshit

    Use HTTPS Everywhere anyway. Great plugin. But forget your much-touted "sense-of-security" because it can't exist in light of the above.

    • Re: (Score:3, Insightful)

      by Logic Worshiper ( 1480539 )

      A self signed certificate would be fine for most of what HTTPS Everywhere does.

      End to end encryption is for stuff that really matters, not facebook and other crap that's public to the internet anyway.

      • Re: (Score:2)

        by Steeltoe ( 98226 )

        You can be fired over someone cracking or spoofing your Facebook identity. I would consider that important.

        Who decides what security is important, really?

      • Re: (Score:2)

        by tepples ( 727027 )

        A self signed certificate would be fine for most of what HTTPS Everywhere does.

        But then how would your users know that your self-signed cert is authentic before installing it into their browsers for the first time? MITM in the wild is a reality [mozilla.org].

        • Re: (Score:2)

          by Lennie ( 16154 )

          DNSSEC is the solution for that, but it will take years before we'll have validating resolves in the browser.

          In studies it has been shows, even many DSL-routers block DNS over TCP or large DNS-packets.

    • Re: (Score:3, Interesting)

      by Onymous Coward ( 97719 )

      Here's a way of handling certs which doesn't rely on those organizations: Perspectives

      http://www.cs.cmu.edu/~perspectives/ [cmu.edu]

      • Re: (Score:2)

        by Lennie ( 16154 )

        I don't know and who validates the response from the Perspectives notaries (the agents in the networks which store this information) ?

        And what about my privacy ? Do they store the information about the sites I visit (they probably say they don't).

        Maybe Certificate Patrol is a good start:

        https://addons.mozilla.org/en-US/firefox/addon/6415/ [mozilla.org]

        It works like SSH, everytime you connect it will tell you if something changed since you last connected. It also will tell you what changed.

  • Actions you must take for firesheep protection (Score:3, Informative)

    by Fnord666 ( 889225 ) on Wednesday November 24, 2010 @09:28AM (#34330744) Journal
    According to the release notes, there are specific actions that you must take to enable some of this protection:

    The 0.9.0 release of HTTPS Everywhere is a new beta version designed to offer improved protection against Firesheep. Most notably, it can provide much better protection for Facebook, Twitter and Hotmail accounts, as well as completely new protection for bit.ly, Dropbox, Amazon AWS, Evernote, Cisco and Github. Unfortunately, in order to obtain maximum Firesheep protection, especially on Facebook, you must take two extra steps:

    • Turn on the "Facebook+" rule. You can do that in the Tools->Add Ons->HTTPS Everywhere->Preferences menu. It isn't on by default, because it can cause Facebook Apps to raise errors. We're still waiting for Facebook to fix this, and the chat problem :(.
    • Install the Adblock Plus Firefox extension too, and use it to block the insecure http:/// [http] adds and trackers that Facebook (and other sites) sometimes include.

    • Re: (Score:1)

      by pyster ( 670298 )
      The release notes maybe incorrect, or dated, as it was on by default for me. the amazon rule is not, and has (buggy) next to it.

  • Assume sites want to prevent firesheep, and do not want https everywhere. Does secure cookies fix this?

    Login via HTTPS, get secure cookie ("the token") . Then on each page load, use this token to sign your request.

    This can be done with existing technology, but requires Javascript.

  • Why not HSTS? (Score:1)

    by Anonymous Coward

    The HTTP Strict-Transport-Security (HSTS) header and its predecessors, X-Force-HTTPS and X-Force-TLS, enable HTTP sites to declare that and how they want to be accessed over a secure connection.
    The HSTS header is not recognized by Firefox 3.x. Firefox 4 supports it but without an UI. The extensions ForceTLS and STS UI deal with that, respectively.
    These extensions should be merged with HTTPS Everywhere. It's unreasonable to expect people to manually enter all the sites they use, and it's equally unreasonable

  • I need to look this up, but does anyone know how to use this on an unjailbroken ipod, or how about the facebook application on the ipod?

    I know the dangers and concerns, but I still use unencrypted wifi like all those that don't even have a clue. I suppose I'm the worst of all... but I bet I'm not alone. It really is amazing how a system with so many vulnerabilities manages to stay together and grow for decades :-P

  • https://twitter.com/ [twitter.com] almost works, but I sniffed the packets using Wireshark and unfortunately they still make one HTTP request, which because the session cookie is not marked secure is sent insecurely along with it. I remember reading that it was made using XMLHTTPRequest.

Slashdot Top Deals

"The medium is the message." -- Marshall McLuhan

Close