Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

This is why sites choose to stay vulnerable to Firesheep

google.com

Post reply on HN
Print view View original

71–80 of 143 posts

Re: This is why sites choose to stay vulnerable to Firesheep

#71

Post by mike-cardwell »

_b8r0 wrote: post #67
mike-cardwell wrote: post #61

Earlier quoted context omitted.

That is the solution to protect websites from the current iteration of FireSheep. It doesn't fix the underlying problem though. If a version of FireSheep comes out that can do MITM we might have bigger problems. The solution to the problem is SSL on every page.

I'm not sure I'm parsing your post correctly, but as I understand it you're talking about third party websites accepting responsibility to protect you over an insecure network connection. If that's the case, then I think you're mistaken. Certainly SSL is not required on every page, and MITM tools have been around for some time (including fairly friendly ones like Cain - http://www.oxid.it/ ). At the end of the day co…

I do think websites should try to protect their users over an insecure network connection, yes.

Re: This is why sites choose to stay vulnerable to Firesheep

#72

Post by hannibalhorn »

eru wrote: post #60
nikcub wrote: post #52

Earlier quoted context omitted.

Wifi connections should probably all use WPA2, even at coffee shops if you just write the password on the wall, it defeats the purpose - everyone who logs in is on the same network again, just like a public network

Everyone being on the same network isn't too much of a problem. They still can't read each others traffic. See http://en.wikipedia.org/wiki/IEEE_802.11i-2004 or http://en.wikipedia.org/wiki/Wi-Fi_Protected_Access#WPA2 Every device negotiates its own keys with the access point.

Very common misconception, but it's still a problem. Any client with the network password can capture the initial key negotiation, and then decrypt the client's subsequent traffic. You can enter the network password in Wireshark: http://wiki.wireshark.org/HowToDecrypt802.11 .

Re: This is why sites choose to stay vulnerable to Firesheep

#73

Post by A1kmm »

kneath wrote: post #45
djcapelis wrote: post #42

Earlier quoted context omitted.

Absolutely, but the protection SSL helps with is it actually forces the attacker to compromise hot-new-metrics whereas without SSL you can just skip the first part of step 2 and just do "send malicious js" through a MITM without ever having to go compromise any of the services involved.

Unless they're using Safari which doesn't have a mixed content idea. My point is that it doesn't fix anything at all. Like filling 8/10 holes in a bucket of water. It's still going to leak out.

It is the webapp developer who ultimately decides whether or not there is mixed content, not the browser. If you don't mix content in your webapp, an attacker who controls the network shouldn't be able to change your content (not even to inject references to new untrusted HTTPS or plain HTTP servers), or that of trusted service providers. The browser needs to implement SSL securely, but even users with a browser with no mixed-content warning benefit from there being no mixed-content.

The mixed content warning helps to warn the developer of the site of the problem, and let users of browsers that support it know that they are not fully protected.

Re: This is why sites choose to stay vulnerable to Firesheep

#74

Post by mapgrep »

mike-cardwell wrote: post #36
al_james wrote: post #22

There has got to be a sensible way around this. It seems overkill to require every pageview to be over HTTPS, even for otherwise public sites. For example, should these public discussion pages be over HTTPS on hacker news? On my site I am planning the following: operate the login page over HTTPS and issue two cookies. One is HTTPS only and other other is for all pages. The public (non HTTPS) cookie is only used for i…

This is just dangerous. Example. If news.ycombinator.com implemented this dual cookie method. A man in the middle could intercept the page I'm looking at now, where I'm entering this comment in a textarea. They could modify the underlying form to post to the same page as the update form on the profile page, and set a hidden email field. Then when I hit the "reply" button, even though I'm posting to a HTTPS page, I'm…

Wait, if you've got the capability to intercept and rewrite arbitrary http forms, couldn't you just rewrite the homepage of Google.com the same way? The "action" attribute on the form gets changed to https -mybank- dot com slash profile, hidden fields are inserted, etc, and when the user clicks "Search" he's actually updating aforementioned profile page.

If this is possible, then the dual cookie method would seem to make sense.

Re: This is why sites choose to stay vulnerable to Firesheep

#75

Post by thwarted »

kneath wrote: post #7

This is a problem we (GitHub) are facing in a big way right now. Google Charts doesn't offer https alternatives, so almost all our users get a big "this site is going to steal all your private information" (mixed content warning). We chose to roll out SSL first, then deal with the hard problem of mixed content warnings (building ridiculous image proxies) later. I think a lot of developers underestimate how big of an…

During the last Velocity conference, one of the last sessions on the last day was a talk from Google guys about how to make SSL faster, because they had recently turned SSL on for all gmail accounts.

I asked how they deal with the unlocked icon and warning dialogs for mixed protocol content on the page and the response was that people are so used to the popups and the lock being unlocked, that they (Google) don't consider it to be a problem. The response was really short and curt and I felt it was kind of a cop-out.

Re: This is why sites choose to stay vulnerable to Firesheep

#76

Post by piotrSikora »

al_james wrote: post #22

There has got to be a sensible way around this. It seems overkill to require every pageview to be over HTTPS, even for otherwise public sites. For example, should these public discussion pages be over HTTPS on hacker news? On my site I am planning the following: operate the login page over HTTPS and issue two cookies. One is HTTPS only and other other is for all pages. The public (non HTTPS) cookie is only used for i…

You're think about right solution, but you're overdoing it and in the end you're unnecessary complicating very simple thing.

The simplest (and IMHO the best) solution is to have everything served over HTTP for unauthenticated users and everything served over HTTPS for authenticated users (this requires authentication cookie marked as "secure" and regular cookie "authenticated=true" that would redirect authenticated user to HTTPS version of the site in case that he/she would go to the HTTP site).

Re: This is why sites choose to stay vulnerable to Firesheep

#77

Post by SpikeGronim »

erikano wrote: post #69
Groxx wrote: post #66

An alternative? : http://www.tcpcrypt.org/

> Tcpcrypt is opportunistic encryption. If the other end speaks Tcpcrypt, then your traffic will be encrypted; otherwise it will be in clear text. I like that, as opposed to requiring users to have to install some plugin before they can even talk to the server.

You may like it but it really reduces the security. A man in the middle can make it look like you don't speak Tcpcrypt by manipulating the first few packets of a connection. It's the same issue as mixing HTTP/HTTPS - the HTTP parts leave you vulnerable. If encryption is not mandatory then it might as well not be there.

Re: This is why sites choose to stay vulnerable to Firesheep

#78

Post by harshpotatoes »

drivingmenuts wrote: post #18

Honestly, how many sites are aware that they are vulnerable? It seems like you assume that because the security-oriented 0.5% of the web knows about it, the rest of the web should, too. For most people, just making sure that their site runs at all is quite enough for them to handle, and keeping current on the latest vulnerabilities is way down on the list. Additionally, fixing a site takes time. How long has Fireshee…

I agree that most of the web is probably ignorant at best of most security vulnerabilities. But, keep in mind that firesheep is not exploiting a new vulnerability, but an old one that has been known about since probably early 2000. Firesheep is new in that it is automating the work of other programs (which were admittedly a little less user friendly).

Re: This is why sites choose to stay vulnerable to Firesheep

#79

Post by drivebyacct2 »

kneath wrote: post #7

This is a problem we (GitHub) are facing in a big way right now. Google Charts doesn't offer https alternatives, so almost all our users get a big "this site is going to steal all your private information" (mixed content warning). We chose to roll out SSL first, then deal with the hard problem of mixed content warnings (building ridiculous image proxies) later. I think a lot of developers underestimate how big of an…

Could you proxy through your own servers?

Re: This is why sites choose to stay vulnerable to Firesheep

#80

Post by drivebyacct2 »

drivingmenuts wrote: post #18

Honestly, how many sites are aware that they are vulnerable? It seems like you assume that because the security-oriented 0.5% of the web knows about it, the rest of the web should, too. For most people, just making sure that their site runs at all is quite enough for them to handle, and keeping current on the latest vulnerabilities is way down on the list. Additionally, fixing a site takes time. How long has Fireshee…

How many sites (that any of us are legitimately worried about) employ webmaster, developers, system admins or other that DON'T know why SSL/HTTPS is important? You can't honestly be giving facebook, twitter, etc a pass on understanding very basic concepts... (sniffing, http (cookies))?

Firesheep has been around for 2+ weeks now, but come on, we've all known this has been possible for forever. I'm 20, and I knew how to do this (and did) /years/ ago. I think Firesheep is just what everyone needed.

There are really good reasons why this is taking a long time and it is NOT lack of knowing that this problem exists.

That having been said, my laptop is now running a LiveCD of x2go's LTSP client and my desktop computer is running the x2go server. Very near-native performance and total security. (I trust my desktops' endpoint).

Post reply on HN