Unfortunately just encrypting the login page would not protect user accounts from Tunisia's ISP. The ISP can just sniff your session cookie and hijack your session instead. They won't be able to change your password but they can read and write all your other data.
The only real protection here is to go full SSL and not forget to set the SSL only flag on session cookies. Even then, you only have to wait till Tunisia buys a forged certificate for Facebook.
Sorry, either either the autolinker or I screwed up that post. My point was that if people cared about security, they could have been visting the facebook login page by manually typing HTTPS in the first place.
I don't use FB, but someone on Slashdot was saying it likes to reply with every link going to http anyway. Based on my experience with Twitter and other sites, this sounds very plausible.
No mixed content warnings here though. The ISP is editing the login page to include JavaScript that posts the password back, seemingly, to Facebook at http://www.facebook.com/wo0dh3ad. Being a man in the middle, the ISP can capture all requests to this non existent URL and harvest the passwords. The browser can't suspect a thing.
If you mean using the browser or OS password mechanism, then sure, if you're logged in as the user you can access their secrets.
But this doesn't should not be true for "remember me" cookies. Those just need some identifier.
At any rate, you still need "talent": to know where the person is, when they're going for coffee, ability to access their machine without bystanders asking questions, etc.
If you control any firewall or router along the way you can inject iframes which retrieve any url you like and run script in the same-origin context. Except for "https only" sites, but note that Microsoft helpfully provides the government of Tunisia with a trusted root CA in their products. Try https://www.certification.tn/ . I wonder if it's a code-signing cert?
> Microsoft helpfully provides the government of Tunisia with a trusted root CA in their products
Isn't this rather huge news? Why did they do this sort of downgrading hackery when they could do a more elegant (and slightly more transparent) man in the middle?
A) It's better to avoid using your capability even if you have it.
B) Probably a lot of users prefer Mozilla, though it may defer to the system store on Windows anyway, I'm not sure.
C) For the same reasons it's a pain for FB to use https everywhere, it's a pain for Tunisia to set up SSL interception on their outbound connections. There are certainly off-the-shelf boxes which can do it though.
If you have access to a Windows machine, visit http://bit.ly/eWYRbA in IE then check your personal cert store for Agence Nationale de Certification Electronique
Nope, nothing of the sort.
The government has absolute control over the internet infrastructure here, and they manipulated the page's markup on the fly (or maybe the served an already modified and cached copy) when requested.
I don't see how Javascript is to blame here, which is I think what the author is implying with the "game over" link to slides about JS insecurity.
This attack only worked because the attacker could subvert the same-domain origin policy, by posting usernames and passwords to a page at the facebook.com domain (but which was routed to an attacker's host at a lower level.) The security failure happened at a lower layer than where Javascript security would be responsible.
Nope, at the time of these incidents, I could request GMail's login page over HTTP, though the login form action pointed to a HTTPS url. This was fixed a day or two later though. Same with Yahoo.
The only real protection here is to go full SSL and not forget to set the SSL only flag on session cookies. Even then, you only have to wait till Tunisia buys a forged certificate for Facebook.