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

51–60 of 143 posts

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

#51

Post by zmmmmm »

mickeyben wrote: post #19
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…

We discovered the exact same issue and rolled back few weeks ago. The worst is that the default selected choice in the modal box is to not load anything.

The IE8 warning is the most confusing sentence I've ever seen. Even I as a veteran of 13 years of web programming have to read that thing 3 times to know which button to press to make it load the damned stuff.

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

#52

Post by nikcub »

Udo wrote: post #34
kijinbear wrote: post #26

Earlier quoted context omitted.

While your frustration is understandable, I think you're speaking from the perspective of a tech-savvy person and not the average user. If browsers began accepting all free / self-signed certificates, it would be only a matter of time before something like "Firesheep FX" came along and permitted random strangers to MITM anybody's SSL session. Some of us can notice when that happens, but most people won't have a clue…

> If browsers began accepting all free / self-signed certificates [...] Right now, browsers are accepting any unencrypted old HTTP connection without any warning, while non-verified securely encrypted connections are actively prevented. Tech people can circumvent the block, but normal users cannot. Nor do they have any reason to because the warning they are being shown sounds like the end of the world, while any unse…

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

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

#53

Post by kneath »

zmmmmm wrote: post #49
kneath wrote: post #29

Earlier quoted context omitted.

1. Include https://hot-new-metrics-startup.com/tracker.js 2. hot-new-metrics-startup gets hacked. Sends over malicious js 3. Your page is no longer secure. https certificate remains. We can argue semantics, but I guess I'm more concerned about the end result than semantics.

The problem is that you asserted it is "just as easy". It certainly might be possible for the attacker to compromise a specific server that you have chosen to trust - but that's a much higher barrier to an attacker than performing MITM on an open Wifi connection which doesn't require them to compromise any server.

Okay, here's another "just as easy" scenario:

1. You include http://google.com/trusted.js on a https page

2. Someone goes to a cafe, opens up your website with Safari while someone is performing a MiTM attack on that file.

3. No warnings, your user is compromised.

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

#54

Post by _cbsz »

pyre wrote: post #44
_cbsz wrote: post #20

Earlier quoted context omitted.

The warning isn't spurious, by the way. A man in the middle could inject evil JS into urchin.js (or whatever the equivalent is now) just as easily as he could inject it into your site's JS; the page is not secure.

How is 'mixed content' any more dangerous than unencrypted HTTP? Why is the user not warned every time they go over an un-encryped connection?

I am not going to argue for the correctness of this position, but presumably it's because the "secure" icon (e.g., the little lock) is absent.

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

#55

Post by kijinbear »

Udo wrote: post #34
kijinbear wrote: post #26

Earlier quoted context omitted.

While your frustration is understandable, I think you're speaking from the perspective of a tech-savvy person and not the average user. If browsers began accepting all free / self-signed certificates, it would be only a matter of time before something like "Firesheep FX" came along and permitted random strangers to MITM anybody's SSL session. Some of us can notice when that happens, but most people won't have a clue…

> If browsers began accepting all free / self-signed certificates [...] Right now, browsers are accepting any unencrypted old HTTP connection without any warning, while non-verified securely encrypted connections are actively prevented. Tech people can circumvent the block, but normal users cannot. Nor do they have any reason to because the warning they are being shown sounds like the end of the world, while any unse…

OK, I see what you mean. If you're suggesting that websites protected with untrusted certificates should be treated as if they were plain HTTP sites, then I agree with you. Chrome crosses out the "https" part of the URL if the page contains insecure elements. Something similar might be the right way to treat untrusted certificates.

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

#56

Post by zmmmmm »

kneath wrote: post #53
zmmmmm wrote: post #49

Earlier quoted context omitted.

The problem is that you asserted it is "just as easy". It certainly might be possible for the attacker to compromise a specific server that you have chosen to trust - but that's a much higher barrier to an attacker than performing MITM on an open Wifi connection which doesn't require them to compromise any server.

Okay, here's another "just as easy" scenario: 1. You include http://google.com/trusted.js on a https page 2. Someone goes to a cafe, opens up your website with Safari while someone is performing a MiTM attack on that file. 3. No warnings, your user is compromised.

Any browser which doesn't warn about that in some way is essentially broken. (Yes, I see you cited Safari as one, but it must the the only one as far as I know - it does remove the padlock, but that seems pretty inadequate ...)

EDIT: I do take your point in that I think IE is the only browser that actually blocks the content. The others warn about it but still load it, by which time, of course, the damage is done.

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

#57

Post by [deleted] »

nikcub wrote: post #52
Udo wrote: post #34

Earlier quoted context omitted.

> If browsers began accepting all free / self-signed certificates [...] Right now, browsers are accepting any unencrypted old HTTP connection without any warning, while non-verified securely encrypted connections are actively prevented. Tech people can circumvent the block, but normal users cannot. Nor do they have any reason to because the warning they are being shown sounds like the end of the world, while any unse…

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

[deleted]

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

#58

Post by mike-cardwell »

BrandonM wrote: post #23
harshpotatoes wrote: post #11

Earlier quoted context omitted.

I think he's arguing that since both twitter and facebook (and other unnamed sites) do not use adsense, but are still vulnerable to firesheep, there must be another reason why developers don't update the security for their website.

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

Unfortunately, Facebook's XMPP service doesn't utilise SSL either. They hash the password, but everything else is trivally decodable on the wire. Plus there was the hole in Facebook chat which exposed your conversations to your friends earlier this year. Possibly the worse IM system in existence.

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

#59

Post by kijinbear »

michaelhart wrote: post #46
kijinbear wrote: post #26

Earlier quoted context omitted.

While your frustration is understandable, I think you're speaking from the perspective of a tech-savvy person and not the average user. If browsers began accepting all free / self-signed certificates, it would be only a matter of time before something like "Firesheep FX" came along and permitted random strangers to MITM anybody's SSL session. Some of us can notice when that happens, but most people won't have a clue…

> The difference between free and $10/year is bigger than most of us think it is. > I agree with you that we need some good free CAs https://www.startssl.com/ Supported by just about every browser. Entirely free. A fellow Hacker News user linked to it in a similar thread. I was impressed :)

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

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

#60

Post by eru »

nikcub wrote: post #52
Udo wrote: post #34

Earlier quoted context omitted.

> If browsers began accepting all free / self-signed certificates [...] Right now, browsers are accepting any unencrypted old HTTP connection without any warning, while non-verified securely encrypted connections are actively prevented. Tech people can circumvent the block, but normal users cannot. Nor do they have any reason to because the warning they are being shown sounds like the end of the world, while any unse…

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.

Post reply on HN