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

31–40 of 143 posts

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

#31

Post by tomjen3 »

Udo wrote: post #17
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…

Exactly. Browser makers (including Mozilla/Firefox to a large degree) are responsible for the fact that HTTPS hasn't become the standard protocol as it should have been years ago. It's not only the unproductive mixed content warning but also the insistence of all browsers to only accept expensively bought certificates and throw a very scary and hard to overcome error dialog if a site uses any other kind of cert. Whil…

Thats what I don't get, why Mozilla doesn't simply remove the root certificate for any organization which charges more than $10 for a wildcard certificate is beyond me.

The verification is the same, there is no good reason it shouldn't be the same price.

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

#32

Post by DrStalker »

jules wrote: post #10

Is the solution to Firesheep to have every logged in page in https? Or is this not necessary?

Any HTTP request that includes the session cookie needs to be secured, otherwise the firesheep user will be able to grab the session cookie and use it in their own requests.

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

#33

Post by NiekvdMaas »

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…

For Google Charts, there is a workaround. Simply change the hostname to www.google.com, example:

  http://chart.apis.google.com/chart?chs=200x200&cht=qr&chl=http://www.adperium.com/ (normal)
  https://www.google.com/chart?chs=200x200&cht=qr&chl=http://www.adperium.com/ (HTTPS)
It's probably not what Google prefers, but this works for us.

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

#34

Post by Udo »

kijinbear wrote: post #26
Udo wrote: post #17

Earlier quoted context omitted.

Exactly. Browser makers (including Mozilla/Firefox to a large degree) are responsible for the fact that HTTPS hasn't become the standard protocol as it should have been years ago. It's not only the unproductive mixed content warning but also the insistence of all browsers to only accept expensively bought certificates and throw a very scary and hard to overcome error dialog if a site uses any other kind of cert. Whil…

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 unsecured connection looks perfectly fine to them. This is something that could be done right now to make everybody more secure, at no cost, but it threatens the business model of companies like Verisign.

Nobody is suggesting that browser makers should display the much-sought-after "lock of absolute protection" icon on any random SSL connection, I'd be fine if they reserve that for paid-for-certs. I'm merely suggesting they show free (or even self-signed) certs the same courtesy as basic HTTP, the most permissive protocol of all time, instead of actively preventing users from using encryption.

I agree with you about the threat of "Firesheep FX" and believe Wifi connections should probably all use WPA2, even at coffee shops where internet access is free. The threat of MITM is real, but the attack can be made more difficult using a number of schemes, and it even includes free certs that offer way more protection than any unencrypted link ever could. Yet, we are currently encouraging unencrypted connections while actively blocking encrypted ones.

If HTTPS could have the same UI mechanisms as, say, an SSH connection I'm convinced the online world would be a much safer place.

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

#35

Post by tomjen3 »

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…

Couldn't you just cache the charts locally, and then serve them directly to the user?

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

#36

Post by mike-cardwell »

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 not posting to the one I think I am, because the page containing the form it's self wasn't protected by HTTP.

I hope I explained that well enough. Mixed content is hard to do right. Forcing every page over SSL prevents anyone making any modifications to any page, and is just inherently safer.

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

#37

Post by caf »

Udo wrote: post #17
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…

Exactly. Browser makers (including Mozilla/Firefox to a large degree) are responsible for the fact that HTTPS hasn't become the standard protocol as it should have been years ago. It's not only the unproductive mixed content warning but also the insistence of all browsers to only accept expensively bought certificates and throw a very scary and hard to overcome error dialog if a site uses any other kind of cert. Whil…

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

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

#38

Post by thadk »

ryanto wrote: post #16
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…

Yup, I agree with you. This is a pretty big problem with a lot of other google services as well. The google maps api for example will not work behind https. Google has publicly said that this is because they want their maps free and open, not behind some page where the user needs to be logged in. This create a huge problem for any site that uses google maps. They do offer a solution though, for $10,000 a year they wi…

For reference, this 2009 post talks about how you need to subscribe to $10,000 Google Maps API Premier to use Google Maps on a private service: http://47hats.com/2009/07/google-maps-the-10k-gotcha/

http://www.google.com/enterprise/earthmaps/maps.html

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

#39

Post by Udo »

caf wrote: post #37
Udo wrote: post #17

Earlier quoted context omitted.

Exactly. Browser makers (including Mozilla/Firefox to a large degree) are responsible for the fact that HTTPS hasn't become the standard protocol as it should have been years ago. It's not only the unproductive mixed content warning but also the insistence of all browsers to only accept expensively bought certificates and throw a very scary and hard to overcome error dialog if a site uses any other kind of cert. Whil…

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

Thanks for the link, I didn't know them. I just tried it. I generated a certificate for a site of mine, uploaded it, changed the config and the cert was pulled by Firefox. However sadly, the authority of StartSSL was NOT recognized by Firefox. This is what it said in the egregious warning dialog:

  *-------.com uses an invalid security certificate.

  The certificate is not trusted because no issuer chain was provided.

  (Error code: sec_error_unknown_issuer)*
StartSSL does not work for me. Unless I did something wrong, which happens from time to time. I verified that the StartSSL cert I installed was downloaded by FF, it just doesn't recognize StartCom as a trusted cert authority (apparently). Can anyone confirm this?

Edit2: You guys were right, thanks! I did paste the intermediate certificate into the wrong file, my bad! It works!

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

#40

Post by brown9-2 »

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…

Is all this extra effort really worth the alternative of just using HTTPS for everything?

Have you really examined the extra cost of 100% https compared with the scheme you've outlined? Sounds like this idea would require a decent amount of effort to identify where to use https, to ensure that each privileged request is using https, etc.

I can see that for some cases it is advantageous to stick to regular http for unimportant requests and use https for the important stuff, but I have a strong feeling that this is only applicable for the minority of use cases and websites.

Post reply on HN