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

101–110 of 143 posts

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

#101

Post by pyre »

erikano wrote: post #63
caf wrote: post #37

Earlier quoted context omitted.

StartSSL ( http://www.startssl.com/?app=1 ) provides free certificates that are browser-recognised.

I've been using StartSSL for quite some time, and only wget has been unwilling to accept it (whereas curl, firefox and chrome have all accepted it): ERROR: cannot verify [site]'s certificate, issued by `/C=IL/O=StartCom Ltd./OU=Secure Digital Certificate Signing/CN=StartCom Class 1 Primary Intermediate Server CA': Self-signed certificate encountered. To connect to [site] insecurely, use `--no-check-certificate'.

Or you could download their certificate locally...

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

#102

Post by tlrobinson »

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.

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 on? The only way I'm able to log out is by deleting the facebook.com cookies.

I'm on Safari 5.

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

#103

Post by iwr »

Browsers should use two kinds of notifications: "encryption on" (green or red) and "certificate is present" (green or red). Websites that do banking or handle sensitive information should be green/green (SSL-on with verified cert), while ordinary websites could be green/red (SSL-on with self-signed cert).

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

#104

Post by mfukar »

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.

Right. Users never do that!

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

#105

Post by ansonparker »

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…

Absolutely. I have run an SSL-only site (https://domize.com) for a few years now.

Other than Google Analytics I can't think of a single other widget/embed/analytics app that has supported SSL out of the box. It's a real shame, but on the other hand I'd bet good money that the web will be 99% SSL within the next 24 months.

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

#106

Post by ntoshev »

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…

The image proxy won't work: Google's js APIs are throttled per IP to prevent abuse.

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

#107

Post by [deleted] »

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…

[deleted]

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

#108

Post by pmjordan »

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 .

If the shared key is known, it's also trivial to install a rogue access point with the same SSID and a transparent, tampering proxy without a realistic chance of anyone noticing.

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

#109

Post by kneath »

tlrobinson wrote: post #100
kneath wrote: post #53

Earlier quoted context omitted.

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.

Yeah, then don't do that, that's the point . Whether you include mixed content in your site is up to you, the developer.

The entire concept of the SSL icon is so that a user can trust a third party (web developer) that they don't know. If it's up to you (the web developer) — it's all up in the air again. And the icon/warnings are pointless. Which is where I've been trying to go with this…

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

#110

Post by kaitnieks »

drivebyacct2 wrote: post #79
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?

This is problematic with services that have limits such as maximum connections per day from a single IP
Post reply on HN