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

131–140 of 143 posts

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

#131

Post by al_james »

mike-cardwell wrote: post #129
al_james wrote: post #123

Earlier quoted context omitted.

Well, I would say its not 'just as dangerous' as a man in the middle attack is harder to set up. Good point though. Maybe this could be solved by including a unique access code with the form that is a hashed value of the user'id and the url that you are submitting to (with salting to make this unguessable). Simply check this value upon submission to make sure it matches the URL seen by the controller. That would prev…

CSRF protection should be implemented even if your entire site is protected by SSL. Also, I didn't say "just as dangerous", I said "just dangerous"

Sorry for misquoting you.

However, with proper CSRF protection your man in the middle argument is not the case is it?

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

#132

Post by jerf »

chrisbroadfoot wrote: post #27
kneath wrote: post #24

Earlier quoted context omitted.

Indeed, the warning has it's merits. That being said the second part of your argument is completely wrong. You can just as easily inject evil JS using an https server and never get the mixed content warnings. The warning serves to indicate to users that some assets (think important-financial-graph.jpg) aren't being served over the same encryption as the rest of the page. But then again, browsers like Safari have no p…

> You can just as easily inject evil JS using an https server and never get the mixed content warnings. Only if the user ignores the "invalid certificate" warning.

Ask tptacek how hard it is to SSL man-in-the-middle attacks in the wild.

Hint: People sell out-of-the-box solutions to the problem.

It's trivial to get certs that browsers won't choke on. You have to more than check for the cert not being "invalid", you have to actually examine it carefully, knowing which cert sellers are trustworthy and which are not. Your SSL lock icon is useless.

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

#134

Post by eru »

hannibalhorn wrote: post #72
eru wrote: post #60

Earlier quoted context omitted.

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 .

Thanks.

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

#135

Post by piotrSikora »

al_james wrote: post #119
piotrSikora wrote: post #76

Earlier quoted context omitted.

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 u…

But then we can't server ads to signed in users which would be a large revenue cut for us.

Of course you can... unless you want to serve ads over HTTP, then indeed, you can't really do that.

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

#136

Post by BrandonM »

tlrobinson wrote: post #102
BrandonM wrote: post #23

Earlier quoted context omitted.

Facebook has an HTTPS version, but Facebook Chat doesn't work over HTTPS.

Facebook's HTTPS site is utterly useless. 1. Go to https://www.facebook.com/ 2. Log in. 3. Immediately you get redirected back to http://www.facebook.com WTF?! 4. Click logout. 5. Go back to https://www.facebook.com/ 6. This time you get redirected to https://ssl.facebook.com/ and you're STILL LOGGED IN. Actually now that I try the same thing with the non-SSL version of the site I have the same problem. WTF is going…

I use HTTPS Everywhere to force Facebook to use SSL. I can't comment on the effectiveness of their site under normal conditions.

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

#137

Post by c00ki3s »

michaelhart wrote: post #62
kijinbear wrote: post #59

Earlier quoted context omitted.

Last time I checked, StartSSL was not recognized by some (slightly old) browsers. I wonder if this issue has been resolved now?

Their root CA was generated in 2006. In theory, any browser shipped before 2006 will not support it unless it was added (through, for example, Windows Updates).IE7+ is supported; I haven't tested (and don't care to test) IE6.

About 3 years back I used them and back then ie6 didnt' work out of the box. And the windows root cert update didn't help either back then.

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

#138

Post by boucher »

samstokes wrote: post #126
thwarted wrote: post #75

Earlier quoted context omitted.

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 con…

Somebody should tell the Chrome team that. A recent version of Chrome changed the mixed content warning indicator from a relatively innocuous "padlock with a cross" to an alarmist "skull and crossbones". We got a lot of complaints about that (due to not yet having built the "ridiculous image proxies" kneath complains about above). It seems like they may have thought better of this change, since my current version of…

I think it actually varies depending on the type of warning, some being considered more severe than others.

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

#139

Post by dazmax »

tghw wrote: post #130
jasonkester wrote: post #112

To be accurate, this is not the reason many sites choose not to go with SSL for everything. The real reason is that most sites don't need to be SSL for everything. I run a travel blogging site, where 99% of all pageviews are from random people off the internet reading people's trip reports and looking at photos. Encrypting all that traffic would do nothing except bog the site for everybody. Every once in a great whil…

The thing that Firesheep brought to people's attention is that the login is not the only thing that needs to be SSL protected. The cookies you get after signing in are often sent in the clear, and that cookie is just as good as your login for gaining access.

It's not the same, because with someone's password you can completely lock them out of their account instead of just acting as them.

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

#140

Post by al_james »

piotrSikora wrote: post #135
al_james wrote: post #119

Earlier quoted context omitted.

But then we can't server ads to signed in users which would be a large revenue cut for us.

Of course you can... unless you want to serve ads over HTTP, then indeed, you can't really do that.

All the advertising networks we deal with only offer HTTPS. Hardly any advertising networks support HTTPS.
Post reply on HN