Many media outlets reported how the Tunisians used Internet and various popular (social) websites to communicate. Facebook, with it’s 500+ millions users world-wide was, of course, the first of them. But it didn’t go as smoothly as we could think.
The Atlantic posted a detailed article, although not very technical, describing how Facebook handled the situation. There were several steps:
- FB “security team” somehow figured out that Tunisian ISPs were intercepting the login and passwords (the HTTP POSTs made on the login page) of the users. I’m not sure how Facebook could do that. Usually that kind of spying is done by using Deep Packet Inspect on any device users have to go through. The end-service (FB in that case) can’t tell there’s a DPI device between it and its users. Any more details on that would be interesting to me.
- Once they identified this security hole, FB set their SLB to enable SSL by default. This is something of note because, even prior to these events, many people criticized the company for not enabling encrypted login pages. A Facebook account’s value is actually quite high. If an account is compromised, an attacker can impersonate a person on literally hundreds of websites using Facebook Connect.
- Last but not least, FB assumed that all the Tunisian accounts were compromised – a pretty safe assumption. Once a user came back to the site, they had to identify people in the pictures linked to their account – to prove they were the legitimate owner of the current account. And then to change the password, to make sure the account was safe again.
The most important part of this, I think, is that FB must have felt very confident in their architecture to go ahead and move a whole country to encrypted traffic by default. One can wonder if they tested in the past or while the events were occurring – or if they tested at all, as we’ve seen plenty of time in the field.