Facebook Fails at https | Hacker News Reader

Facebook Fails at https

musiform.tumblr.com

57 pointsmuki31 comments

Even before FireSheep, that was known for anybody who cared to try it. The test (enter FB address with https, try to get the next page) doesn't need FireSheep at all to be demonstrated. And FireSheep doesn't do anything new except packaging the existing technology to make it extremely easy for everybody to experiment. But until FireSheep, if I'd tried to explain the problem to anybody, the best I'd get would be "meh." The worst: "you paranoid." Nice to see the change in the attitude.

This. I was trying to explain to my co-workers that this issue has existed for as long as the web has existed and they didn't really understand what I was talking about.

Not until they saw a demonstration video did they believe that it was as bad as I was telling them it was. It is hilarious as a security guy watching "new" exploits come out and watching them go into serious mode since this is a new exploit and it is a bad one and it is going to cause doom and whatnot.

If you can't trust the connection you are on, then time to not use said connection or VPN somewhere. Plenty of places to find hosted VPN services.

> Plenty of places to find hosted VPN services

Care to recommend one? I've had a few unsatisfactory experiences (terrible bandwidth, unreliable servers, etc.) and would love a good recommendation.

I've had good success with BlackVPN. Here's my review (with referral code to get us all free time!): http://www.iqdupont.com/blog/2010/4/19/blackvpn-review.html

Have you tried these guys: https://www.goldenfrog.com/vyprvpn/vpn-service-provider

ibVPN is as good as vyprvpn but is cheaper and has more servers http://www.ibvpn.com/ + it provides free accounts weekly

> find hosted VPN services

So have you solved your problems if you use third party VPN to do the encryption between you and the third party and the mentioned third party also conveniently has your whole data stream unencrypted, no matter from where you connect?

If I get a VPN somewhere I would make sure I trust that endpoint to some degree. Just like I won't be caught surfing on public wifi I don't mind surfing from my home connection as I trust that there is a bit more protection than on a public wifi.

I've known about this for awhile, which is why I use Firefox + HTTPS Everywhere by the EFF, to force encryption on Facebook.

I don't really understand why this is a surprise or that we needed "Firesheep" to make this popular. This is just no-brainer. The ironic thing to me is that Facebook is so popular with colleges, exactly the places where kids sit there with wireshark running, happily gathering data. Firesheep is neat but I am confused as to why it takes this Firefox extension to point this out. I mean, everyone has heard of SSL right? What did we think that was for?

Hilarious outrage. I keep telling people to learn some basic networking ever since I fired up a traffic sniffer on a Lan when everybody was still using POP3. Facebook forcing https on all it's pages won't solve anything, people need to educate themselves before using one of the most complex systems humanity has built.

Perhaps supporting ssl and/or tls across their infrastructure isn't a priority. Why is that a "fail", as you so succinctly put it?

In addition, I'd like to ask the entire world to stop using 'fail' as a noun. It's lazy and incorrect.

I guess you missed the big story today about Firesheep:

http://news.ycombinator.com/item?id=1827928

That doesn't invalidate my point. Supporting SSL is certainly more costly when you're serving content on the scale of FB.

The costs must be weighed against the benefits. Calling FB out as a "fail" is failing to understand all of the issues.

People need to stop repeating this same old false argument. Read http://techie-buzz.com/tech-news/google-switch-ssl-cost.html

"all of our users use HTTPS to secure their email between their browsers and Google, all the time. In order to do this we had to deploy no additional machines and no special hardware. On our production frontend machines, SSL/TLS accounts for less than 1% of the CPU load, less than 10KB of memory per connection and less than 2% of network overhead. Many people believe that SSL takes a lot of CPU time and we hope the above numbers (public for the first time) will help to dispel that."

that dovetails nicely with other posts today on HN about how one can be a great programmer without knowing and understanding the systems fundamentals (ie. C, low level networking...) . Such programmers and their companies are fast in building cute web apps, yet fail to understand/model and as result correctly engineer what happens outside of the web app box supplied by the framework (for example like in this case, how it looks on the wire at transport and application layers)

It's a near certainty that Facebook knew, understood, and accepted this vulnerability, since it's as old as the hills and Facebook employs and works with many smart web security people.

>with many smart web security people

that is exactly my point. "Web security" being treated as a separate area where only specific people specialize instead of being treated as a basic fundamental prerequisite for a web developer.

I'm not following. I'm saying: Facebook certainly knew that if you logged in via a public wireless network that your session cookie could be stolen. They accepted the risk, like many, many other companies do. What do the fundamentals of web dev have to do with this?

But it's not exactly low level though. I mean, any web developer is surely constantly exposed to this in their day-2-day work - e.g just from using HttpFox. How can you build a web site and not know how a session is managed over HTTP?

Joomla. I have a photographer friend who makes websites on the side and she doesn't have a clue how any of it works under the hood.

I don't want SSL for Facebook. SSL is slow, and its only slower the worse your latency. Until SSL is fundamentally changed to be fast, I'm going to avoid it at all costs.

Currently on my production application it adds a minimum of 200ms per request.

This is yet another reason to use a tool like 1password.

Turn on persistent connections on your server, ensure you have session caching enabled on your server, and ensure your servers are sharing the session cache.

Any Facebook employee reading this? That'd be a great thing to fix, and the PR of a positive privacy story about Facebook would probably be welcome.

I'd also love if they enabled encryption for FB chat, even if you used an external client like iChat or Pidgin.

That's a nice app that's linked there, but has anybody made a version for android yet? That would be really fun -- and considering the number of hot spots in major cities would really take things to the next level. ;)

I just tried going to https://news.ycombinator.com/ and got Error 102 (net::ERR_CONNECTION_REFUSED): Unknown error.

Not as badly as billing.microsoft.com

It's kind of shocking that the session vulnerability seems to be so new to so many. It is painfully obvious. It's one of the reasons that many sites demand that you enter your old password before entering a new password (ensuring that, in the event someone steals your session cookie [which includes simply accessing a public PC], at least it's a temporary vulnerability).

This particular entry, however, uses the worn and now ridiculous "fail" meme five different times. Fail.

Whats the point? Sensitive Information like the login page is secured by https (which is a great thing) but why encript the data you don't need to have encripted?

It's (for me) pretty simple. they force the users to use http because the amount of cpu time which is spent for http user is lower than the time for https...

just my two cents

Reading about Firesheep you'd find out that the session cookie is passed in the clear and acquiring that allows you to steal someone's session. This is easy on WiFi. That's why it matters.

Eew... i'm sorry. i didn't realized this point... you're right sir! this behaviour isn't good...

Reply on news.ycombinator.com