Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

How Facebook Responded To Tunisian Hacks

Soulskill posted more than 3 years ago | from the occupying-the-town-of-zuckerberg dept.

Facebook 227

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.'"

cancel ×

227 comments

Sorry! There are no comments related to the filter you selected.

Duh (1)

Locke2005 (849178) | more than 3 years ago | (#34986166)

How badly does Facebook's password encryption suck if a man-in-the-middle attack can easily steal everybody's password?

Re:Duh (5, Informative)

Anonymous Coward | more than 3 years ago | (#34986272)

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...

Re:Duh (4, Insightful)

Locke2005 (849178) | more than 3 years ago | (#34986460)

A valid point -- end-to-end encryption in both directions is required. Meaning the calls to always use https actually make sense.

Https as commonly employed isn't enough (2)

Giant Electronic Bra (1229876) | more than 3 years ago | (#34987122)

SSL3/TLS will only protect against MITM attacks if BOTH the client AND the server mutually authenticate. This would require the issuance of a signed certificate to the client, not something that any garden variety retail grade web service does. On the other hand it is quite possible that just using HTTPS would have thwarted the attack simply because it puts a rather higher technical barrier in place and makes it necessary to use more intrusive measures. In any case the point is a good one, HTTPS should be universal for any kind of authentication for a whole raft of reasons.

Re:Duh (2)

kalaudio (1968112) | more than 3 years ago | (#34986628)

It looks to me the attack either wasn't that pervasive, or the solution wasn't that thorough:

Sullivan's team rapidly coded a two-step response to the problem. First, all Tunisian requests for Facebook were routed to an https server. The Https protocol encrypts the information you send across it, so it's not susceptible to the keylogging strategy employed by the Tunisian ISPs.

Https would still be suceptible to keylogging. I won't detail how the attack would be laid out (wouldn't want to inspire potential attackers ;) ), but https won't protect from a keylogging javascript being attached to the login page by an ISP. Do your research on MIM attacks if anyone wants to find out. So, either the solution won't work, or the attack wasn't as cleverly implemented. And let me say which one it is: both. I've just inspected facebook's login page, and it transmits passwords in the clear (in a POST request), protected only by a MIM-vulnerable https implementation. Yet, the article says facebook reports that their workaround "seems to work". It would only work if the attack was poorly implemented.

Re:Duh (1)

h00manist (800926) | more than 3 years ago | (#34986298)

I wonder how they're going to fix it now that the passwords are all stolen already.

Re:Duh (1)

Sponge Bath (413667) | more than 3 years ago | (#34986348)

Send flowers to the funerals of the oppressed exposed by this security breach?

Re:Duh (3, Funny)

Yvan256 (722131) | more than 3 years ago | (#34986408)

Add the character "2" at the end of all current passwords?

Re:Duh (1)

91degrees (207121) | more than 3 years ago | (#34986530)

Inform the user that their password is very likely compromised. Leave it up to the user to change it. They could even deliberately force the user to change their password via an email link.

Re:Duh (4, Interesting)

Anonymous Coward | more than 3 years ago | (#34986572)

Anyone who logged in during the period of time where passwords were being captured was presented with photos and asked to pick the ones featuring their friends. Then they were asked to choose a new password.

Re:Duh (1)

rjstanford (69735) | more than 3 years ago | (#34986640)

The good news is that the answer to your question is spelled out explicitly in TFA...

Re:Duh (3, Insightful)

reaper (10065) | more than 3 years ago | (#34986370)

As bad as every other site that doesn't require https:// for login.

Re:Duh (1)

Critical Facilities (850111) | more than 3 years ago | (#34986546)

Agreed, but this part of the article had me intrigued:

It wasn't a totally perfect solution. Most specifically, ISPs can force a downgrade of https to http, but Sullivan said that Facebook had not seen that happen.

I do not know the ins and outs of internet routing well enough to understand this, but I was alarmed by it. Does anyone with more technical expertise in the area have any insight?

Re:Duh (1)

JoshRosenbaum (841551) | more than 3 years ago | (#34986660)

They may just mean that an ISP can modify the HTML delivered to the user so that the form submit action is set to the http address vs https.

Re:Duh (1)

Jahava (946858) | more than 3 years ago | (#34986696)

Agreed, but this part of the article had me intrigued:

It wasn't a totally perfect solution. Most specifically, ISPs can force a downgrade of https to http, but Sullivan said that Facebook had not seen that happen.

I do not know the ins and outs of internet routing well enough to understand this, but I was alarmed by it. Does anyone with more technical expertise in the area have any insight?

I think it's simple: Facebook allows HTTP logins, but defaults to HTTPS. The ISP could respond to the initial HTTPS request with a redirect to the regular HTTP version.

Re:Duh (3, Interesting)

MichaelSmith (789609) | more than 3 years ago | (#34986702)

The ISP can run a proxy which pretends to be the user from the point of view of facebook and pretends to be facebook from the point of view of the user. It can run an https connection to facebook and forward it to the user as a plain http connection. That way it can record or change anything in the facebook session and the user probably won't be aware that the proxy is there.

The proxy could also run an https connection between the proxy and the user but that is more difficult because encryption software in the browser would alert the user that the proxy is not facebook. However if the browser has been fiddled with its game over for the user on many levels. Lots of people in the third world access the internet from internet cafes. One place I used in Malaysia has a single windows image which is booted across the LAN when a workstation is started. If the Government got their own software on to the server with that image, or changed the template for all the internet cafes then it would be impossible to guarantee security.

Re:Duh (2)

jdogalt (961241) | more than 3 years ago | (#34986720)

Agreed, but this part of the article had me intrigued:

It wasn't a totally perfect solution. Most specifically, ISPs can force a downgrade of https to http, but Sullivan said that Facebook had not seen that happen.

I do not know the ins and outs of internet routing well enough to understand this, but I was alarmed by it. Does anyone with more technical expertise in the area have any insight?

Not like I've RTFA or anything, or even an expert, but my guess is simply the issue of- facebook _allows_ http logins, so all a nefarious government/network need do is break https for the site. I.e. the solution is to not have an unencrypted option, such that if a gov/net breaks https, instead of falling back to an insecure login, people get pissed that they can't use the site at all, and thus it becomes a high profile news story, etc.

Re:Duh (0)

Anonymous Coward | more than 3 years ago | (#34986856)

Facebook (and pretty much all websites) have at least one regular HTTP page that you get when you go to http://www.facebook.com. This is necessary to respond to people visiting the site as http://www.facebook.com, and even if this page is an automated redirect to https://www.facebook.com, it presents the following problem.

Someone between you and Facebook could create a transparent proxy that interacts with you through HTTP and with Facebook through HTTPS. To you, this would mean you never see the little lock on the browser and all the URLs you visit on Facebook will start with "http://". The proxy would intercept and convert any HTTPS links Facebook sent you to HTTP links in the HTML document, and would perform its own HTTPS interaction with Facebook using whatever information you provided through those links returning the response to you as HTTP.

This is likely observable on both ends if it occurs. On the client side, as mentioned, formerly HTTPS operations would all be done through HTTP. On the server side, they would probably see a small pool of IP addresses performing HTTPS connections to them. I suspect it is possible to fake out the servers by setting up the transparent proxy and routers to intercept HTTPS communications to client IP addresses such that it would appear to Facebook that the clients themselves are performing these communications. It should always be evident to clients that HTTPS is not being called by their web browser, but this isn't obvious if you're not looking for it.

Re:Duh (2)

whoever57 (658626) | more than 3 years ago | (#34986452)

How badly does Facebook's password encryption suck if a man-in-the-middle attack can easily steal everybody's password?

The attack may have been a little more sophisticated. Most pages are loaded over a non-encrypted connection. Just the pasword may be sent over an https connection. However, the use of unencrypted pages for everything else allows man in the middle attacks that insert a javascript keylogger into the reply that logs keystrokes directly from the source PC, not from packets as they cross the wire.

That's why FB's response was to respond to all requests from Tunisia using https. That's why GMAIL now defaults to 100% https.

Re:Duh (1)

chemicaldave (1776600) | more than 3 years ago | (#34986538)

How badly does Facebook's password encryption suck if a man-in-the-middle attack can easily steal everybody's password?

How exactly was Facebook supposed to encrypt the users' passwords before receiving them? If you know how to do this then I'll write you a check right now.

Re:Duh (0)

Anonymous Coward | more than 3 years ago | (#34986656)

I'm sorry, obviously you have nevver heard of HTTPS. You are a moron, perhaps?

Re:Duh (1)

chemicaldave (1776600) | more than 3 years ago | (#34986712)

I'm sorry, obviously you have nevver heard of HTTPS. You are a moron, perhaps?

HTTPS relates to the connection between the users and Facebook. It has nothing to do with the way Facebook encrypts the passwords themselves, which is what I was pointing out.

Re:Duh (1)

realityimpaired (1668397) | more than 3 years ago | (#34987178)

Obviously you've never heard of a MITM attack [wikipedia.org] . HTTPS is vulnerable to it.

It *is* possible to encrypt the password for real before the password gets passed to the server, by means of using some javascript with a one-way encryption (think pgp) and a public key, but that would require disclosing the public key as well as the encryption algorithm being used, which isn't very good mojo.

Re:Duh (1)

Magic5Ball (188725) | more than 3 years ago | (#34987198)

To encrypt users' passwords before receiving them, you could run (parts of) your cryptographic algorithms on the client, as TLS, SecurID and umpteen other implementations do. That would render the credentials differently vulnerable to interception via MITM than sending them as clear text.

No professional would sell you such a point solution though, because attaching it to a system that implements the security model you imply would be detrimental to one's reputation if discovered. To my knowledge, as confirmed by TFA, Facebook implements more robust security for authentication than "encrypt[ing] the users' passwords".

Re:Duh (1)

JoshRosenbaum (841551) | more than 3 years ago | (#34987276)

I think I can help a little here. If you aren't using https for logins, then you can do some password hashing tricks to make things much more secure. I developed a similar solution for this at my last job. I checked some other sites to see if they used it when I developed my solution and found that yahoo email did pretty much exactly the same thing when they were using http (non-secure) logins.

Basically the idea is something like this:

*) Server sends a random long string along with form. This string has a time component (either via additional encrypted serialized string or via server-side session storage) and will expire after an hour or less to prevent it being re-used by someone else for a submission. (Can also be expired once used by user to login.)
*) clientside javascript hashes this random long string (possibly more than once) along with password and sends to server. (This protects from rainbow table attack of password using the hash.)
*) server verifies that the hashed values match.

This is a basic overview. I did some other tricks and what not to increase security. I think I looked into using the PKCS standard for some stuff, but can't remember. There are probably some other ways to do this. I think I looked into actual encryption (years back), but javascript was too slow at the time. That might not be the case as much anymore.

Re:Duh (1)

by (1706743) (1706744) | more than 3 years ago | (#34986544)

I could have stolen innumerable facebook passwords when I was in college. When you register your computer for the campus network, you can choose your hostname, which would then be a FQDN -- <myhost>.<university name>.edu . So I registered the "facebook" hostname, and any time someone on the campus network typed in "facebook" (without the .com), it would resolve to me. I ran a redirect to my profile page on facebook.com, just for the hell of it (I eventually got, um, told that I should find better ways to amuse myself...).

It would have been trivial for me to host a false facebook login page, capture the credentials and then redirect to the real facebook login / invalid password page; I would have the password, they would get to log in (I'd like to stress that I didn't actually do this). I haven't R'd TFA, but I suspect you could do something similar on a much larger scale.

Re:Duh (1)

Frosty Piss (770223) | more than 3 years ago | (#34986802)

Feel lucky you didn't end up in front of a judge.

Re:Duh (1)

MichaelSmith (789609) | more than 3 years ago | (#34986822)

Good evening Mr By I represent the Government of Tunisia. A new future awaits you as an employee of the fastest growing security establishment in Africa...

Re:Duh (1)

rwven (663186) | more than 3 years ago | (#34986644)

Facebook doesnt use an SSL login page.... It was totally unencrypted.

Re:Duh (0)

Anonymous Coward | more than 3 years ago | (#34986718)

https://www.facebook.com/ [facebook.com] would disagree with you. As would TFA.

Re:Duh (1)

rwven (663186) | more than 3 years ago | (#34986982)

Log out of facebook and go here:
http://www.facebook.com/index.php [facebook.com] The login page is not secure by default (though you can manually type https if you want). Unless you explicitly tell facebook to be HTTPS, it won't be. How many users do you know who would do that? I can't think of a single one....

An ISP could easily inject a javascript keylogger into this page. It would be downright trivial.

Require HTTPS for all connections... (5, Insightful)

Cryect (603197) | more than 3 years ago | (#34986198)

Really is annoying that Facebook defaults to http

Re:Require HTTPS for all connections... (4, Insightful)

Pojut (1027544) | more than 3 years ago | (#34986304)

I'd say baffling is more appropriate...as huge as the website is, and with as much personal information being slung around, you'd think they would make it ONLY https at this point...

Re:Require HTTPS for all connections... (1)

tkprit (8581) | more than 3 years ago | (#34986682)

I use https and FB just doesn't work well with it: not only do you lose chat, you lose push notifications and profile editing.

Re:Require HTTPS for all connections... (4, Insightful)

Anonymous Coward | more than 3 years ago | (#34986824)

you lose chat, you lose push notifications and profile editing.

Awesome! HTTPS actually makes the application less annoying?!?!

Re:Require HTTPS for all connections... (1)

sustik (90111) | more than 3 years ago | (#34987094)

So some websites (still?) send login and password info as cleartext?

Why do we enable incompetent people to get rich?

Re:Require HTTPS for all connections... (1)

choongiri (840652) | more than 3 years ago | (#34986332)

Precisely. This attack should have been impossible.

Re:Require HTTPS for all connections... (1)

rjstanford (69735) | more than 3 years ago | (#34986652)

Except that all the interceptor need do is force an HTTP connection to themselves, then make the HTTPS connection outbound. How many people would actually check for an HTTPS connection before logging in to Facebook?

Every tunisian naked pics is leaked (1)

h00manist (800926) | more than 3 years ago | (#34986338)

The real revolution-causing leak will be the naked pics leaks.

Re:Require HTTPS for all connections... (1)

Anonymous Coward | more than 3 years ago | (#34986450)

Agreed. As annoying is the fact that the whole site doesn't work over https -- e.g. chat seems to have serious problems.

I'm sure everyone knows HTTPS Everywhere [eff.org] already, it certainly helps me. Unfortunately a non-default solution is useless for the people who most need help, the ones who have no idea what https means...

Re:Require HTTPS for all connections... (1)

I8TheWorm (645702) | more than 3 years ago | (#34986632)

Sadly, https://www.facebook.com/ [facebook.com] does work, but you have to force it... and continue to force it because each request sent over https generates a response as http.

Re:Require HTTPS for all connections... (1)

smart.id (264791) | more than 3 years ago | (#34987220)

Could a greasemonkey script be written to update all links to HTTPS?

Re:Require HTTPS for all connections... (0)

Anonymous Coward | more than 3 years ago | (#34986500)

Yeah, it is. At least login is encrypted, though. I would copy/paste in the form code from their page if Slashdot's comment entry form didn't dislike chrome on mac.

Re:Require HTTPS for all connections... (1)

91degrees (207121) | more than 3 years ago | (#34986588)

But even if it doesn't, you could simply use a non-encrypted proxy site and assume that most users won't care that ther's apparently no secure connection.

Re:Require HTTPS for all connections... (0)

Anonymous Coward | more than 3 years ago | (#34987048)

HTTPS is too much of a performance hit in order to scale.

It's just not viable for gigantic sites (much like google still doesn't push to https either).

From a serverside standpoint generating, the extra calls, every part of what makes the security feasible, is not performant.

Bandwidth isn't free (1)

rsborg (111459) | more than 3 years ago | (#34987074)

As big a fan as I am of HTTPS, it's not only slower than HTTP for the end user, but costs a bunch more in bandwidth and compute (cacheing problems).

I'd say only HTTP is also more along the lines of Zuckerberg's infamous opinion [theregister.co.uk] of his users... in his view they get what they deserve.

Kudos to facebook (5, Insightful)

operagost (62405) | more than 3 years ago | (#34986208)

When Facebook does something right, they should be commended. They easily could have shrugged their shoulders and said, "Not our problem!"

Re:Kudos to facebook (0)

Anonymous Coward | more than 3 years ago | (#34986318)

Like they shrug when the CIA snoops all their traffic.

Re:Kudos to facebook (1)

Yvan256 (722131) | more than 3 years ago | (#34986440)

The Chinese Intelligence Agency?

Re:Kudos to facebook (0)

Anonymous Coward | more than 3 years ago | (#34987206)

But the CIA is so good at keeping their raids secret it's not even known they go around oppressing people with that information, right? It's not like other countries, where the entire world knows they imprisoned their population... nah, the CIA is far too skilled for that. Fuck, I bet they clone the people they catch to impersonate them! Go America... where even our oppressors are the best.

Re:Kudos to facebook (0)

$RANDOMLUSER (804576) | more than 3 years ago | (#34986362)

When Facebook does something right, they should be commended.

Please wake me when that happens.

Re:Kudos to facebook (2)

gparent (1242548) | more than 3 years ago | (#34986914)

When they prevent HTTP login and switch to HTTPs, they'll have done something right. This is just PR. Their shitty security allowed this in the first place.

No Kudos to facebook (2)

Tmack (593755) | more than 3 years ago | (#34987194)

Like others have said, this is easily preventable. HTTPS. Make the http login page redirect to https, and make pages default to https and no more login stealing-by-snooping (firesheep) will work. As is, you can login via https, but all the links on the page are http. VERY annoying.

Yes, https increases CPU and bandwidth, but if you also include the benefits: reduction in staff, support, bandwidth, cpu, etc currently wasted trying to fix the resulting stolen/hijacked accounts, it would come out ahead, probably way ahead.

Tm

so who's to blame for this one? (2)

lagi (303346) | more than 3 years ago | (#34986210)

makes you wonder why a country is able to steal it's Facebook user's passwords.

Re:so who's to blame for this one? (0)

Anonymous Coward | more than 3 years ago | (#34986806)

"makes you wonder why a country is able to steal it's Facebook user's passwords."

It's because all those extra apostrophes.

Re:so who's to blame for this one? (1)

rwven (663186) | more than 3 years ago | (#34986924)

It was very easy... Rtfa

Wake up call (1)

h00manist (800926) | more than 3 years ago | (#34986232)

If they are doing it, I would be surprised if lots of others aren't too.

TL;DR? (0)

Anonymous Coward | more than 3 years ago | (#34986236)

Could someone post the executive summary for this?

The author doesn't get to the fucking point, and I'm not going to read all that garbage to learn how Facebook's authentication sucks wrt security (assuming that's even mentioned in the article).

Re:TL;DR? (0)

Svenne (117693) | more than 3 years ago | (#34986414)

Facebook switched to HTTPS for Tunisian users. Yep, that's about it.

Re:TL;DR? (1)

the eric conspiracy (20178) | more than 3 years ago | (#34986592)

The WTF was that they weren't using https in the first place.

Security an authoritarian government could love (1)

serano (544693) | more than 3 years ago | (#34986238)

The second technical solution they implemented was a "roadblock" for anyone who had logged out and then back in during the time when the malicious code was running. Like Facebook's version of a "mother's maiden name" question to get access to your old password, it asks you to identify your friends in photos to complete an account login.

Hmm, you're trying to log in... Please help us identify your friends first.

This is going to be a great new fake verification for a future authoritarian government.

HTTPS (5, Insightful)

gambino21 (809810) | more than 3 years ago | (#34986244)

Article Summary: They switched facebook to use https in Tunisia.

I wish facebook would consider just switching all traffic to https.

Re:HTTPS (1)

mlts (1038732) | more than 3 years ago | (#34986336)

+1. I know FB would rake in the bucks if they offered a premium service that had https by default, no ads, and the ability to use a VASCO or SecurID keyfob (with OATH certification when logging from PCs, and for non-PCs, the FB app has the ability to set a PIN.)

I'd pay the usual $20 a year for this easily, mainly because FB is a good tool for keeping track of band and other events going on locally.

Re:HTTPS (2)

jschmitz (607083) | more than 3 years ago | (#34986526)

They are already raking in the bucks - you aren't the customer you are the product

Re:HTTPS (3, Insightful)

LWATCDR (28044) | more than 3 years ago | (#34986584)

Wow $20 a year? You and five other people. They rake in more than that in ad revenue from each "prime" user. Also most people just don't care enough to pay for this service.

What I find amazing is not that Facebook isn't secure but people expect it to be. This is a place where you "publish" information on the internet. It is not now and never should have been considered a secure communication channel.
Why doesn't facebook default to https [slashdot.org] :? My guess is cost. It takes resources to encrypt data and for face book moving everything to https probably would cost a few million dollars in resources.
And nothing stops you from using https://facebook.com/ [facebook.com] does it?

Re:HTTPS (1)

vlm (69642) | more than 3 years ago | (#34987238)

What I find amazing is not that Facebook isn't secure but people expect it to be. This is a place where you "publish" information on the internet. It is not now and never should have been considered a secure communication channel.

I deleted my facebook acct about a year ago, so excuse my terminology.

Imagine the scenario of a profile picture being changed to goatse.

You are correct that it is "published" to the internet and is not secret-secure.

Where you are wrong, is thinking that it is authorized-secure.

Much like this post was written by VLM. Or, was it? As if you'd know...

Re:HTTPS (1)

MichaelSmith (789609) | more than 3 years ago | (#34986368)

The ISP could still proxy the connection though. Proxy to FB and Proxy to client would still be encrypted but the proxy would get the username and password. The client may have to click through a warning about a mismatched certificate but I reckon most would.

Re:HTTPS (1)

ThatMegathronDude (1189203) | more than 3 years ago | (#34986424)

Most browsers give you a very big and mean looking error message when certs mismatch. The kind that make people unversed in security call their computer geek friends before doing anything; I suspect that this won't be too huge a problem.

Re:HTTPS (1)

MBCook (132727) | more than 3 years ago | (#34986462)

They don't have to play Man-In-The-Middle. They can just make sure that HTTPS doesn't work (return error codes, drop packets, etc) such that it becomes unusable and people's only choice (if they want to keep accessing FB) is to use standard HTTP.

Re:HTTPS (1)

NoSig (1919688) | more than 3 years ago | (#34986494)

At which point it will be apparent that something is up.

Re:HTTPS (1)

MichaelSmith (789609) | more than 3 years ago | (#34986498)

True but say the user in Tunisia is using IE from Windows. Maybe the government looks the other way when people steal the version of windows with the "right" binaries. Or he's running firefox but Tunisia has a special localised version which you automatically get when you download it from one of their ISPs.

Re:HTTPS (1)

kiwix (1810960) | more than 3 years ago | (#34987058)

Most browsers give you a very big and mean looking error message when certs mismatch. The kind that make people unversed in security call their computer geek friends before doing anything; I suspect that this won't be too huge a problem.

Since Firefox gives me the same alarming message every time I go to a website with a self-signed certificate, I just click through the warning without reading it (self-signed certificates are quite common, and pretty inoffensive). I guess many people do the same.

Sadly enough, SSL certificates aren't so much about security as they are about money...

Re:HTTPS (0)

Anonymous Coward | more than 3 years ago | (#34986558)

That's as far as Facebook's responsibility goes. If the users decide to ignore the big warning screen (thinking FF, I have no idea how other modern browsers do it), that is their problem. Facebook doesn't have to babysit it's userbase, as long as they take reasonable precautions (ie HTTPS as default protocol).

Re:HTTPS (1)

BitterOak (537666) | more than 3 years ago | (#34986852)

The ISP could still proxy the connection though. Proxy to FB and Proxy to client would still be encrypted but the proxy would get the username and password. The client may have to click through a warning about a mismatched certificate but I reckon most would.

Probably not even necessary. How hard would it be for the Tunisian government to get a CA in Tunisia to sign a fake Facebook cert? Then there'd be no warnings at all. I mean SSL only works if you trust every CA whose root cert is in your browser, and really, why the hell should anyone do that?

Re:HTTPS (1)

MichaelSmith (789609) | more than 3 years ago | (#34986970)

The ISP could still proxy the connection though. Proxy to FB and Proxy to client would still be encrypted but the proxy would get the username and password. The client may have to click through a warning about a mismatched certificate but I reckon most would.

Probably not even necessary. How hard would it be for the Tunisian government to get a CA in Tunisia to sign a fake Facebook cert? Then there'd be no warnings at all. I mean SSL only works if you trust every CA whose root cert is in your browser, and really, why the hell should anyone do that?

Yes.

Re:HTTPS (0)

Anonymous Coward | more than 3 years ago | (#34986794)

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.

On your client end, one connection is no problem. Scale that for 100 million logged-in users.

Facefuck off (0)

Anonymous Coward | more than 3 years ago | (#34986260)

Er, Facebook is willing to give up pretty much all your personal details to any third party that asks so I don't see why this is that much different. I'm surprised they didn't release some lame statement along the lines of 'Oh this is so you can log in much easier, just let your local government official do it for you and he can do all your shopping and check your Farmville while you are in prison.FUCK ZUCKERBERG!

Re:Facefuck off (1)

h00manist (800926) | more than 3 years ago | (#34986404)

FUCK ZUCKERBERG!

You have logged in from Tunisia. Thank you for using Facebook.

Pay Up (5, Insightful)

Anonymous Coward | more than 3 years ago | (#34986270)

So Facebook's sales guy called the President of Tunisia and said "Dude, you have to pay for all that user data just like everyone else does. What makes you think you're special?"

Light on details (3, Insightful)

sat1308 (784251) | more than 3 years ago | (#34986294)

The article is a little light on details, but am I right in thinking that people's session cookies were being sidejacked? AFAIK, despite FB not sending everything over https, the password is sent over https. So I don't see how a keylogger like approach would work to intercept the pw, unless the Tunisian government was smart enough to run something like Moxie Marlinspike's sslstrip where they did a MITM attack and sent unencrypted http traffic to the user and then stole their password. I doubt this was the case because a) they don't seem smart enough and b) no security measure would circumvent this unless people knew not to log in over http.

So now we just wait until the government uses sslstrip...

P.S. - It's unbelievable that in this day and age FB doesn't encrypt the whole session given how trivial session-jacking is.

Re:Light on details (2)

mlts (1038732) | more than 3 years ago | (#34986520)

There are a lot of places other than FB which don't encrypt their traffic other than the initial username/password. Mainly because it is cheap to do so (plain http connections after authentication can be cached, no need to set up and tear down encrypted sockets, etc.)

However what was par for security even last year before widespread sidejacking tools like FireSheep became available is now considered a wide open security risk. Just like how companies have to firewall their networks with the expense involved in having network security, separating departments, and such, companies will have to move to SSL for the entire transaction with their visitors or customers.

Re:Light on details (1)

Jimpqfly (790794) | more than 3 years ago | (#34987004)

I'm sorry but even if you criticize a huge censorship, I find the fact that you saying "they don't seem smart enough" quite offended for Tunisians...
Don't forget they're not red necks, and that they are highly educated.

Fabebook security team discovers https (1)

Anonymous Coward | more than 3 years ago | (#34986314)

Now, that's a story..

Executive summary (5, Funny)

93 Escort Wagon (326346) | more than 3 years ago | (#34986352)

Facebook doesn't want anyone accessing their customers' personal information unless Facebook is being compensated.

Re:Executive summary (1, Insightful)

pitchpipe (708843) | more than 3 years ago | (#34987130)

Parent is modded funny. It is not funny. It is insightful.

Seinfeld (0)

Anonymous Coward | more than 3 years ago | (#34986376)

Every time I see the words "very, very bad" I get a flashback of this:

Babu: You bad man! You very, very bad man!

With his finger saying "uh-uh", going left and right.

A lot of reading (1)

denshao2 (1515775) | more than 3 years ago | (#34986394)

Just to find out that they rerouted to https and used the ability to recognize friend's faces to determine if someone was a legitimate account holder.

Wader (0)

Anonymous Coward | more than 3 years ago | (#34986396)

facebook doesnt have encryption past the server because they dont use HTTPS with an SSL certificate... they use HTTP which simply exposes all information that passes to their server. Its only encrypted after it reaches their server

Everyone knows its insecure lol. Its the most easy site to hack because it uses client side coding...

Good thing Tunesian doesn't have a Root CA! (1)

foom (29095) | more than 3 years ago | (#34986672)

At least, I guess they must not...unlike most every other government in the world... If they did, they could still pretend to be Facebook, even when facebook uses https!

Re:Good thing Tunesian doesn't have a Root CA! (1)

Anonymous Coward | more than 3 years ago | (#34986886)

Well, they actually have a national certification authority ( http://www.certification.tn/index.php?id=4 )

And according to the site it is recognized as a root CA in internet explorer ( http://www.certification.tn/index.php?id=323 )

Re:Good thing Tunesian doesn't have a Root CA! (1)

Archwyrm (670653) | more than 3 years ago | (#34987242)

I always knew IE was bad, but I didn't know it could get you killed..

Seriously though, the CA system is awful and needs replacing.

The real lesson (0)

Anonymous Coward | more than 3 years ago | (#34986748)

Quote from TFA:

Though Sullivan is the unflappable type, the Tunisian situation seemed to force him into a bit of reflection. "When you step back and think about how Internet traffic is routed around the world, an astonishing amount is susceptible to government access," he noted.

Indeed. It happened in Tunisia today, but just remember that there is absolutely no technical reason why it couldn't happen here. Your ISP could do it, your government could do it, and every single last router along the way could do it.

In fact, we pretty much know it IS being done (remember those secret NSA rooms they found at AT&T and all that?); it's just done in a more professional fashion, and the government's not going to tip their hand easily (so if you have something to hide, you're probably safe: they'll know, but they won't act in a way that would give away that they know).

Why again isn't https standard? And why again doesn't Slashdot support https?

Why not protect all users? (1)

Gothmolly (148874) | more than 3 years ago | (#34986772)

Why do you need a country-level solution? Why not a global solution, which implements ALL your country solutions at once?

Re:Why not protect all users? (1)

tnk1 (899206) | more than 3 years ago | (#34987166)

Why do you need a country-level solution? Why not a global solution, which implements ALL your country solutions at once?

Because:

a) Tunisia is in the news for the first time since the Punic Wars, so its topical. That gives positive PR value.
b) Tunisia is a small country that doesn't have the number of users as, let's say, the US, and so forcing https down their throat is not going to be a big deal
c) If this fails, people will forget about it as soon as people forget about Tunisia again. (About 2-4 weeks from now)

and....

d) "Holy shit, look at what's going on in Tunisia! Hey, wouldn't it be funny if we had Tunisians as customers? Wait! We do! Let's check out the traffic from there. Wait a minute... check this out....! Hey, Joe, can you upload those certs to the Netscaler today? Thanks! Go North Africa Ops! Now we have something to put in the department newsletter instead of our usual lame Spicy Falafel recipes. Eat THAT US Operations losers!"

Join the Facebook group (0)

Anonymous Coward | more than 3 years ago | (#34986778)

Want to have HTTPS on Facebook as default? Show your support in favor of HTTPS. Join the Facebook page. [facebook.com] :p

HTTPS Everywhere (4, Informative)

metrometro (1092237) | more than 3 years ago | (#34986834)

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 [eff.org]

Work that donate button a little while you're there.

They turned on https for logins (1)

Culture20 (968837) | more than 3 years ago | (#34986836)

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.

Please tell me that they turned on https for logins by default. Because that is what they should have done.

solution (1)

Syobon (1853468) | more than 3 years ago | (#34986952)

yeah, the solution is easy: encrypt fucking everything.

Re:solution (1)

MichaelSmith (789609) | more than 3 years ago | (#34987204)

The only way that can be made to work is for all of us to control the hardware and software we use, and for each of us to have a private key which we share with selected people. Systems which rely on dynamic key negotiation can be broken by routers. Systems which rely on globally available certificates can be broken by the authorities which operate the certs.

I don't think that word... (1)

wealthychef (584778) | more than 3 years ago | (#34987190)

... means what you think it does:

a revolution that could become a parable...

Bzzt. wrong

Load More Comments
Slashdot Login

Need an Account?

Forgot your password?

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>