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

111–120 of 143 posts

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

#111

Post by rimantas »

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…

This is all true but it is somehow different from the topic: one cannot do this kind of attack easily just using Firesheep kind of tool. I think sometimes these discussions are carried away to far.

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

#112

Post by jasonkester »

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 while (in terms of total traffic), somebody will log in and post something. That tiny moment could benefit from SSL, since chances are it's happening from a public internet cafe or wifi hotspot. That's the only time a user is actually vulnerable to this sort of attack, so that's when they need to be protected.

But when you look at the internet at a whole, the traffic fraction that needs protecting looks pretty much the same. When you're showing me pictures of cats with funny captions, please don't encrypt them before sending them to me just because you read something about security on HackerNews.

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

#113

Post by halfasleep »

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?

Thinking you have a secure connection when you don't is worse. On (generic hostile network), thinking you can check your mail safely is worse than knowing you can't.

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

#114

Post by aaronbrethorst »

agl wrote: post #91
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…

Well, as I recall, several of the questioners at that session were verging on the point of heckling, so many of the responses were short. But the answer is that permitting mixed content was probably a mistake in the first place, but it's one that we have to live with. The ease of mixing content means that many sites get it wrong (including Google sites, to our shame) and the lack of ubiquitous SSL (again, including s…

How's that free SSL-enabled google maps service coming along? Any chance we'll ever see it without paying umpty-thousands of dollars for the privilege?

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

#115

Post by JoachimSchipper »

kneath wrote: post #109
tlrobinson wrote: post #100

Earlier quoted context omitted.

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…

Eh? SSL provides security against eavesdroppers, network manipulation, etc. - it doesn't help against a malicious site that you actually intended to communicate with.

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

#116

Post by random42 »

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 would have tested the cases for you, but fortunately, I have deleted my FB account. I dont trust them with anything.

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

#117

Post by pilif »

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.

if the AP and the gateway are separate devices, couldn't I just ARP-spoof the gateway and get all traffic on the wireless network sent over to me, regardless of encryption?

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

#118

Post by mike-cardwell »

mapgrep wrote: post #74
mike-cardwell wrote: post #36

Earlier quoted context omitted.

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…

True, as long as the site isn't doing referer checks, which most of them probably aren't. This is yet another argument for why the entire web should be secured with SSL.

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

#119

Post by al_james »

piotrSikora wrote: post #76
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 u…

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

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

#120

Post by al_james »

brown9-2 wrote: post #40
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 un…

We cant serve ads over HTTPS and we make most of our money from ads. So that would be very expensive!
Post reply on HN