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

121–130 of 143 posts

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

#121

Post by othermaciej »

zmmmmm wrote: post #56
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.

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.

Our theory is that an SSL site including non-SSL content is no better or worse, in terms of security, than a completely non-SSL site.

What is the purpose of warning more prominently in the scenario described, than in the scenario where the user goes to a non-SSL site in the first page, or is redirected from an SSL login form to a non-SSL page?

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

#122

Post by _b8r0 »

mike-cardwell wrote: post #71
_b8r0 wrote: post #67

Earlier quoted context omitted.

I'm not sure I'm parsing your post correctly, but as I understand it you're talking about third party websites accepting responsibility to protect you over an insecure network connection. If that's the case, then I think you're mistaken. Certainly SSL is not required on every page, and MITM tools have been around for some time (including fairly friendly ones like Cain - http://www.oxid.it/ ). At the end of the day co…

I do think websites should try to protect their users over an insecure network connection, yes.

That's an interesting though. Where do you draw the line? Should websites protect users who don't have AV, firewalls or share user accounts?

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

#123

Post by al_james »

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…

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 prevent anyone rewriting a form to submit to a new endpoint.

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

#124

Post by _stephan »

benblack wrote: post #94
boyter wrote: post #70

Earlier quoted context omitted.

You can also SSH tunnel out to a secure server, which is what you should do on any public network that isnt under your control. It won't protect you from man in the middle attacks on the general internet, or fix the underlying issue with most websites, but it will stop firesheep.

It seems unlikely most users on the Internet could even parse your suggestion, much less execute it. That doesn't make them stupid, just not experts in the subject. Instead they rely on experts, like you, to make the right choices for them in these esoteric matters. While there are any number of ways you might solve this problem, HTTPS is the best available option since clients and servers already support it. As eric…

Getting a VPN account from some service like witopia.net is not rocket science. People just need to be educated that they need a VPN account if they want to use a publicly shared network without compromising their privacy.

(Of course, as boyter pointed out, a VPN connection doesn't protect you on the general internet, but it does protect you where you're most exposed.)

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

#126

Post by samstokes »

thwarted wrote: post #75
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…

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 Chrome (6.0.472.63) seems to have gone back to the padlock-and-cross.

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

#127

Post by iampims »

al_james wrote: post #123
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…

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…

Isn't it why we need to implement xsrf protection on every form?

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

#128

Post by mike-cardwell »

_b8r0 wrote: post #122
mike-cardwell wrote: post #71

Earlier quoted context omitted.

I do think websites should try to protect their users over an insecure network connection, yes.

That's an interesting though. Where do you draw the line? Should websites protect users who don't have AV, firewalls or share user accounts?

I don't think websites should protect users that don't have AV, firewalls or share user accounts no. I also don't think websites should protect users who cross the road without looking both ways. None of those things are relevant to protecting the communications between the website and the user.

If the users machine is compromised, that's the users problem. If the users machine isn't compromised, yet the website can't be accessed over an inherently untrustable network like the Internet, then the website has some flaws that it needs to deal with. SSL is a start. DNSSEC is becoming important too and I will be using it on grepular.com when Verisign signs "com" at the beginning of next year.

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

#129

Post by mike-cardwell »

al_james wrote: post #123
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…

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"

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

#130

Post by tghw »

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.
Post reply on HN