it's one of the reasons. probably not the only one.
This is why sites choose to stay vulnerable to Firesheep
21–30 of 143 posts
Re: This is why sites choose to stay vulnerable to Firesheep
#22There 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 identification (e.g. welcome messages and personalisation). However, all requests that change the database in any way are handled over HTTPS and we check to make sure the user has the secret HTTPS cookie as well. Often forms submit to a HTTPS backend and then redirects back to the public page over HTTP. Also, all account information pages (sensitive pages) will be over HTTPS.
This way, the worst that can happen via cookie sniffing is that someone can see pages as though they were someone else. In your case, this is not much of a risk.
Re: This is why sites choose to stay vulnerable to Firesheep
#23Earlier quoted context omitted.
I don't understand your argument here--are you saying we shouldn't mind if the vulnerable sites aren't Facebook or Twitter?
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.
Re: This is why sites choose to stay vulnerable to Firesheep
#24This 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 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.
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 problem with this. Other browsers like Firefox (correctly) cache these assets on disk if Cache-Control:public is set, thereby un-encrypting the asset.
The error may not be spurious, but it sure doesn't mean the page is secure or not.
Re: This is why sites choose to stay vulnerable to Firesheep
#25This 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…
Hmmm... I see what you are saying, but (for example) godaddy offer basic SSL certs for $10. Not a huge price for anyone.
Re: This is why sites choose to stay vulnerable to Firesheep
#26This 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…
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 unless the browser presented them with a big scary red warning.
However, I agree with you that we need some good free CAs. The difference between free and $10/year is bigger than most of us think it is. Fortunately, there are registrars such as Gandi which will give you free certificates with every domain.
Re: This is why sites choose to stay vulnerable to Firesheep
#27Earlier 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.
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.
Re: This is why sites choose to stay vulnerable to Firesheep
#28Is there an alternative to HTTPS?
Re: This is why sites choose to stay vulnerable to Firesheep
#29Earlier 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.
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.
Re: This is why sites choose to stay vulnerable to Firesheep
#30Earlier quoted context omitted.
hes saying that most sites that use adsense do not require a login, thus do not need https. he is somewhat correct, but not enough for google to just ignore this issue.
There are sites that make use of sessions without forcing you into using an account. These are also vulnerable.
Well, sometimes for strange values of "vulnerable".
Some of my sites use Apache::Session over non secured http connections, which makes them technically "vulnerable".
The only practical thing an attacker can do with those session ids though, is to mess with some custom visitor tracking in my management backend. So perhaps my information about whether a particular inquiry visited my terms and conditions page or my privacy policy page will be wrong. I can live with that.