9 ms·
This is why sites choose to stay vulnerable to Firesheep
- yanw 16y agoFacebook and Twitter don't run Adsense, it's mostly run on content sites that don't require you log into them.
- ericflo 16y agoI don't understand your argument here--are you saying we shouldn't mind if the vulnerable sites aren't Facebook or Twitter?
- ryanto 16y agohes 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.
- ericflo 16y agoMost content sites have login systems that people use to customize their experience, post comments or upload content, etc. Millions and millions and millions of people are logged into content sites and are vulnerable to this attack. Also, I disagree on the premise that adsense is mostly used on content sites. It's used on all kinds of websites.
- elliottcarlson 16y agoMost notably would be the oodles of forums out there that are ad supported and require logging in.
- gregmuellegger 16y agoThere are sites that make use of sessions without forcing you into using an account. These are also vulnerable.
- bigiain 16y agoWell, 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.
- harshpotatoes 16y agoI 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.
- BrandonM 16y agoFacebook has an HTTPS version, but Facebook Chat doesn't work over HTTPS.
- mike-cardwell 16y agoUnfortunately, Facebook's XMPP service doesn't utilise SSL either. They hash the password, but everything else is trivally decodable on the wire. Plus there was the hole in Facebook chat which exposed your conversations to your friends earlier this year. Possibly the worse IM system in existence.
- tlrobinson 16y agoFacebook's HTTPS site is utterly useless. 1. Go to https://www.facebook.com/ https://www.facebook.com/ 2. Log in. 3. Immediately you get redirected back to http://www.facebook.com http://www.facebook.com WTF?! 4. Click logout. 5. Go back to https://www.facebook.com/ https://www.facebook.com/ 6. This time you get redirected to https://ssl.facebook.com/ 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 on? The only way I'm able to log out is by deleting the facebook.com cookies. I'm on Safari 5.
- benblack 16y agoIrrelevant contrarian opinion that adds nothing to the debate, but indicates with certainty I am more interested in being pedantic and scoring points than having a useful discussion.
- tptacek 16y agoSuccessfully executed.
- kneath 16y agoThis 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 impact this warning is on users, especially on browsers like IE that throw up a dialog on every page that has this warning. Developers understand that it's not that big of a deal — but to a user, it looks like the site is full of viruses, malware and is going to steal all your bank account information.
- ericflo 16y agoNot only that, but in IE it's a modal dialog. You can't do anything (even switch to another tab) until you've acknowledged the scary warning.
- templaedhel 16y agoThats why I use IE6. No tabs, no problem.
- SoftwareMaven 16y agoIt's good to have a solid reason to keep IE6 around. I'd hate for it to go away!
- ryanto 16y agoYup, 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 will let you use the map api behind https.
- 16y ago
- jules 16y agoIs the solution to Firesheep to have every logged in page in https? Or is this not necessary?
- DrStalker 16y agoAny 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.
- mike-cardwell 16y agoThat is the solution to protect websites from the current iteration of FireSheep. It doesn't fix the underlying problem though. If a version of FireSheep comes out that can do MITM we might have bigger problems. The solution to the problem is SSL on every page.
- iuguy 16y agoI'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/ http://www.oxid.it/). At the end of the day companies such as Facebook, Twitter et al have a moral (and in some cases legal) obligation to protect the information assets you uploaded to their systems from compromise. Likewise it is not unreasonable that you take certain steps to protect yourself. The current version of FireSheep is a real known threat. We don't know what might be in future versions. For protecting against Session ID theft, SSL and the secure flag on cookies are the way to go. Certainly for data that doesn't need to be secure (such as static publicly available graphics), there's no need to use SSL for the majority of use cases. The use of SSL for delivering dynamic client side code (such as HTML or Javascript) is an interesting issue, but ultimately the user has to bear some responsiblity for their own actions somewhere along the line. Not every network is insecure, not every browser has to support a zillion and one insecure means of using Javascript. Rather than using SSL on every page and expecting the web sites to do the heavy lifting, consider not using insecure bearer networks, or some sort of means of securing insecure Internet links such as a VPN or SSH tunnel.
- EricButler 16y agoWhile sites wait for services such as adsense to support SSL, adding a second Secure cookie and requiring on sensitive pages and to perform destructive actions can help reduce risk to users. Depending on the site, it may be OK to skip showing ads on a few authenticated pages. Wordpress implemented this in 2008: http://ryan.boren.me/2008/07/14/ssl-and-cookies-in-wordpress-26 http://ryan.boren.me/2008/07/14/ssl-and-cookies-in-wordpress... This won't protect against active attackers, but is definitely a step forward and will make a full transition easier in the future, when possible.
- technoweenie 16y agoWe spent about a week trying this on GitHub. It works pretty well as long as you have no ajax requests. We were basically left with this option: 1) Lose the ajax (and spend a significant time redoing bits of the site) 2) Scary iframe hacks. 3) SSL Everywhere. I feel like we made the best choice (I certainly don't mind removing any chance we'll have adsense any time soon :). It cleaned up a lot of logic based around determining which pages were important enough to require SSL (admin functions, private repos, etc). It's brought on some other issues though. Safari and Chrome don't seem to properly cache HTTPS assets to disk, for one. This is an old problem: http://37signals.com/svn/posts/1431-mixed-content-warning-how-i-loathe-thee http://37signals.com/svn/posts/1431-mixed-content-warning-ho... . I'm not too worried about increased bandwidth bills on our end, I'm worried about having a slower site experience. We're also seeing users complain about having to log in every day. Are browsers not keeping secure cookies around either?
- drivingmenuts 16y agoHonestly, how many sites are aware that they are vulnerable? It seems like you assume that because the security-oriented 0.5% of the web knows about it, the rest of the web should, too. For most people, just making sure that their site runs at all is quite enough for them to handle, and keeping current on the latest vulnerabilities is way down on the list. Additionally, fixing a site takes time. How long has Firesheep been out? A week? Two? You should realize that for many sites, even those staffed by very competent tech people, a month is the minimum amount of time for immediate action.
- harshpotatoes 16y agoI agree that most of the web is probably ignorant at best of most security vulnerabilities. But, keep in mind that firesheep is not exploiting a new vulnerability, but an old one that has been known about since probably early 2000. Firesheep is new in that it is automating the work of other programs (which were admittedly a little less user friendly).
- drivebyacct2 16y agoHow many sites (that any of us are legitimately worried about) employ webmaster, developers, system admins or other that DON'T know why SSL/HTTPS is important? You can't honestly be giving facebook, twitter, etc a pass on understanding very basic concepts... (sniffing, http (cookies))? Firesheep has been around for 2+ weeks now, but come on, we've all known this has been possible for forever. I'm 20, and I knew how to do this (and did) /years/ ago. I think Firesheep is just what everyone needed. There are really good reasons why this is taking a long time and it is NOT lack of knowing that this problem exists. That having been said, my laptop is now running a LiveCD of x2go's LTSP client and my desktop computer is running the x2go server. Very near-native performance and total security. (I trust my desktops' endpoint).
- dekz 16y agoI can understand a possible flaw in a websites attempt to provide secure transfer of data, but just disregarding encrypted communication makes me question their title of web developer.
- joshfraser 16y agoit's one of the reasons. probably not the only one.
- al_james 16y agoThere 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.
- mike-cardwell 16y agoThis 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.
- mapgrep 16y agoWait, 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 make sense.
- 16y ago
- tapz 16y agoIs there an alternative to HTTPS?
- CaptainMcCrank 16y agoI read the overclocking ssl posting (http://www.imperialviolet.org/2010/06/25/overclocking-ssl.html http://www.imperialviolet.org/2010/06/25/overclocking-ssl.ht...) & I've been seeing plenty of follow up about how SSL is cheap and easy to scale, but I have yet to see one tutorial that describes actually implementing overclocking SSL or implementing it cheaply. So- to the HN community, is this whole "ssl is cheap" a false meme, or does someone have actual instructions on how to deploy & implement a scalable SSL?
- Groxx 16y agoAn alternative? : http://www.tcpcrypt.org/ http://www.tcpcrypt.org/
- erikano 16y ago> Tcpcrypt is opportunistic encryption. If the other end speaks Tcpcrypt, then your traffic will be encrypted; otherwise it will be in clear text. I like that, as opposed to requiring users to have to install some plugin before they can even talk to the server.
- SpikeGronim 16y agoYou may like it but it really reduces the security. A man in the middle can make it look like you don't speak Tcpcrypt by manipulating the first few packets of a connection. It's the same issue as mixing HTTP/HTTPS - the HTTP parts leave you vulnerable. If encryption is not mandatory then it might as well not be there.
- erikano 16y agoI hadn't thought about that. However, at the bottom of tcpcrypt.org, it said "You're not using tcpcrypt =(" to me, so perhaps this could be used to show a (less obtrusive and less intimidating than browsers do when they detect the lack of SSL for some content on the page) warning to users that they are not using Tcpcrypt.
- Groxx 16y agoWhich requires active attacks, ie MITM. And stopping MITM is essentially impossible - the best you can do is use our current CA setup, which assumes the original download of the certificate you got wasn't hijacked. In preventing passive listeners, like Firesheep, this would work 100% effectively anywhere it can work at all. The only way it reduces security is in making people who don't understand MITM attacks feel they're safer than they are - at absolute worst it's like you don't have it installed.
- trumbo 16y agoWhat's the deal with that page not having any stylesheets? It looks completely broken. Am I the only one seeing this?
- ohwaitnvm 16y agoTurn off adblock and reload the page.
- iwr 16y agoBrowsers should use two kinds of notifications: "encryption on" (green or red) and "certificate is present" (green or red). Websites that do banking or handle sensitive information should be green/green (SSL-on with verified cert), while ordinary websites could be green/red (SSL-on with self-signed cert).
- jasonkester 16y agoTo 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.
- tghw 16y agoThe 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.
- dazmax 16y agoIt's not the same, because with someone's password you can completely lock them out of their account instead of just acting as them.
- tghw 16y agoIn a lot of systems, you can change the password without knowing the old one as long as you're logged in. Others, you can change the email address, only confirm on the new email address, and then get a password reset. So if you really cover all of your bases, and require confirmation at every step, then the least they can do is access your data and generally impersonate you until you log out of that session (which no one does) or the session times out (which it won't, because you're still logged in as them). It's pretty much the same.
- alexyoung 16y agoIt's kind of obvious that a major reason is IPV4. Getting another IP so you can run both SSL and plain HTTP is only going to get harder.
- hapless 16y agoIs there any reason that the web server can't set up an SSL reverse proxy to fetch the adsense ads ? (Obviously cookies would have to be passed-through...) It would cost you more bandwidth, but then there's no annoying warning message about mixed content.