Slashdot Mirror
How Facebook Responded To Tunisian Hacks
jamie writes "Facebook's security team opens up, shedding light on a revolution that could become a parable for Internet activism. Quoting: 'After more than ten days of intensive investigation and study, Facebook's security team realized something very, very bad was going on. The country's Internet service providers were running a malicious piece of code that was recording users' login information when they went to sites like Facebook. By January 5, it was clear that an entire country's worth of passwords were in the process of being stolen right in the midst of the greatest political upheaval in two decades. Sullivan and his team decided they needed a country-level solution — and fast. Though Sullivan said Facebook has encountered a wide variety of security problems and been involved in various political situations, they'd never seen anything like what was happening in Tunisia.'"
I believe the ISP changed the facebook login page to execute additional javascript to grab the entered password before it was sent off, encrypted, to the fb server. But then again I didn't RTFA...
Once again, our friends at the EFF are ahead of the curve. Their HTTPS Everywhere extension, released a few months ago, probably would have beaten this attack by Tunisian security services, or at least made their jobs much harder.
Here's the extension: https://www.eff.org/https-everywhere
Work that donate button a little while you're there.
Hardware costs would soar if they switched entirely to HTTPS. There is an entire industry making crypto co-processors to handle the load that millions of concurrent HTTPS connections place on an infrastructure.
SSL accelerators are useful for offloading the CPU-heavy part of the SSL transaction: the RSA key-exchange part. The rest of the secured connection is quite light, particularly when using a fast cipher like RC4. The RSA part can be sped up by using shorter keys (e.g. a 1024-bit key, rather than 2048 or 4096-bits), while still providing modest security (anything is better than nothing).
That this guy, a Google employee, said the following about SSL:
In January this year (2010), Gmail switched to using HTTPS for everything by default. Previously it had been introduced as an option, but now 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.
If you stop reading now you only need to remember one thing: SSL/TLS is not computationally expensive any more.
If you go to https://facebook.com/ you do view an encrypted home page. But all of the links to everything are just non-encrypted http. Unless you copy each link, paste it into the address bar, and prepend 'https://' to it (or write a browser script to do the same) then most of your facebook session will not be secured.
Or just find a CA that is either sympathetic to your cause or subject to your coercion.
read and weep. A list this long and spread through so many different countries is not the way to run a tight ship security wise.
note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
FWIW, since Chrome on Windows re-uses some (maybe all?) of IE's networking layer, you can use Chrome instead of IE to reproduce this. There is a caveat - you need the "Update Root Certificates" program which was included in Windows XP SP2.
This page has a nice writeup of the problem and mentions that Vista or higher behave differently (not really better, just differently).