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

91–100 of 143 posts

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

#91

Post by agl »

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…

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 some Google sites) imposes that on others.

So, I suppose that `we don't consider it a problem' is roughly correct regarding warning dialogs: the answer is not to mix content. The problem is that it's clearly too difficult to do that. (The inability of networks to cache public resources over HTTPS is also an issue and possibly one which we'll address.)

Lack of SSL on the Chart's API is a new one, but I'll look into it now that I know that it's a problem.

As for the rest of the problem: fixing stuff is hard. Miraculous answers invariably tend to be so only in the eyes of the conceiver. We'll keep plugging away.

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

#92

Post by anigbrowl »

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…

Agree 100%. I wasted most of a day (in increments over several weeks) worrying about whether I had screwed something up at my end, tweaking my gmail settings, analyzing TCP traffic and so on. A little bit of information from Google's end would have saved me hours of needless security anxiety.

Lack of complaint != contentment. I am pretty annoyed to hear of this indifference to users' peace of mind.

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

#93

Post by thwarted »

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…

That's good to hear. But considering that only now is SSL considered to be "important", because of FireSheep, it would have been nice to have a major player like Google seriously consider/suggest/lead the dialog on solutions here, even if some of them are "hard" or unworkable. It's nice to have options, or know what the options are. Or even to say "there is no solution, create systems that don't mix protocols".

I mean, when I went back and summarized my experience at Velocity to the rest of my team, that this question was glossed over as it was led to some audible guffaws. Because we've all been dealing with users for years who don't know how to deal with the UX of this problem.

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

#94

Post by benblack »

boyter wrote: post #70
jules wrote: post #10

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

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 ericflo is pointing out, a small number of sites deploying HTTPS would go a long way to achieving the goal of a more secure Internet for all.

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

#95

Post by patio11 »

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…

This is a problem we (GitHub) are facing in a big way right now

This also broke Bingo Card Creator something fierce when I rolled out SSL support. It was the reason I hadn't had it previously, and I knew it was going to be a problem going in, and I tested for it, and I still managed to hose two pages which were critical to my business for most of a week.

Figure on a 40~50% drop in conversion from a non-technical audience on IE if they get one of those popups, by the way. It is the worst possible place to be: not enough to trigger an automated "Oh cripes!" from the website, but big enough to murder business results.

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

#98

Post by tlrobinson »

kneath wrote: post #29
chrisbroadfoot wrote: post #27

Earlier quoted context omitted.

> 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.

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.

Saying you can hack an analytics company's servers is cheating. I can just say I can hack GitHub's servers. Or obtain a root SSL cert. Or crack SSL.

If you don't trust a company and their competency at security you probably shouldn't be using their service for anything sensitive. You can't assume that your users aren't on hostile networks vulnerable to MITM attacks, etc.

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

#99

Post by boyter »

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…

I totally agree. In those cases I usually point people in the direction of TOR and the like. The orginal poster just asked if HTTPS was the only way to get around Firesheep, and the answer of course is no it isn't.

I still think HTTPS is the best way forward (never said anything to dispute that), but right now if you want speed (tor is slow!) and still want be safe, a SSH tunnel is the way to go.

Besides, anyone reading Hacker News is probably comfortable with creating a SSH tunnel, or learning how to do so :)

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

#100

Post by tlrobinson »

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.

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