Securing Email Communications from Facebook
facebook.com
facebook.com
GPG Tools seems to be popular and has Mail.app integration. It loads, shows the secret key as valid in the GPG Keyring app, but any attempt to decrypt a message fails with “Secret key to decrypt the message is missing”. No diagnostic information is provided.
Okay, I'll pretend it's still 1995 and run it on the command-line. "pbpaste | gpg --decrypt" needs a password, so I naively attempt to setup gpg-agent so I don't need to keep pulling my 30-character password from my password manager. "brew install gpg-agent" and it quickly turns out that it's just broken: pinentry doesn't get stdin for some reason and chews 100% CPU printing * as quickly as possible.
So much for saving time in the future; let's just see if we can open one message. Save it to a temp file, run it through gpg --decrypt and … it's HTML so the URL needs to be unescaped, so make that "gpg --decrypt encrypted.asc | urlview".
Open that URL and get … a server error from Facebook.
So … another vote for http://www.thoughtcrime.org/blog/gpg-and-me/
When you decrypted from the command line, did you notice the plaintext blob preceding the HTML message content? Look for "Content-Type: text/plain;" and see if there is an unmodified verification URL there.
You might have only noticed the HTML one, which will be a pain to cut & paste. If it's still broken, please contact me.
Incidentally, I've been using both GPGTools/Mail.app and Gmail/Mailvelope without trouble. The latter doesn't open clicked links in a new tab, though. I've had to "Copy as" and paste in another tab.
People post things on here and simply get attacked, even if they're trying to do good and improve like OP for this thread is. It's people like you who drive others away from this site through your constant "this sucks, that sucks" mindset.
Reinforcing this point to sweis is not a negative comment. It is a comment you do not like. There is a difference.
[https://www.facebook.com/…/publickey/verify/?e=1&fp=…&ext=…&...]
The regex which urlview uses includes the final bracket, which causes the error. Once I removed it, I successfully validated the key.
It'd probably be best to put the URL on its own line but if not, RFC 2396 recommends using angle brackets – see “Recommendations for Delimiting URI in Context” in http://www.ietf.org/rfc/rfc2396.txt.
... the challenge now is how will my email come through on iOS!? Any recommendations for that? I saw https://ipgmail.com/
The lack of a decent iOS mail client with GPG support is somewhat of a show stopper for me.
This isn't yet at S/MIME levels, much less something like iMessage or Signal/TextSecure – and, yes, there's a ton of room to argue their respective merits but most users are simply going to switch to something which gets their message through rather than debug failures, particularly when the software doesn't give any feedback about what's wrong and, critically, what you could do to fix it.
To copy your public key to the clipboard where it can be pasted into your Facebook profile, just do this from the command line:
gpg --export --armor bob@example.com | pbcopy
I also love the subversive nature of this; regardless of how the Patriot Act legislation turns out, Facebook is now providing email that only the recipient’s private key can decrypt and that nobody else can read.
That's the same config I used as well. I used the same export as you but I could have used the GPG Keyring for that step – it's only the mail integration or gpg-agent which fail, unfortunately without any explanation.
That was my real point: I can use everything from the command-line, just like the first time I used PGP in 1993, but for this to catch on the integration needs to be both seamless and reliable. All but the most dedicated privacy / security activists handle failures by disabling the crypto software.
That's been the rule since the 90s: I've seen a bunch of people use PGP/GPG or S/MIME for a few weeks and then give up when they hit a problem and realized that nobody else actually noticed or, in the case of mailing lists, that people using crypto-aware clients couldn't read legitimate messages but everyone else could.
Exceedingly few people care that the software is working correctly when the experience is unpleasant and that's really what needs to change to see popular update. People love iMessage and that's because they're confronted with the always-on strong encryption breaking the experience. It'd be harder to hit that with a decentralized, cross-platform system but that's what we should be shooting for.
Do you have a standard text you use to explain what it is? I confess, I planned to write it, but it's still on my to-do list…
Provides a good overview of PGP/GPG, and more or less gives enough instruction that someone could set it up on their own provided they were more technically inclined. Either way, if they were interested, this would be a good enough starting point I think.
Edit: Achievement unlocked, thanks Iain and Seth.
One thing is giving your data to companies and another one is living on a country where there is not free speech, your beliefs/lifestyle/genetics are illegal, etc. More encryption is always a good thing.
By the way, the article links to an official FB Onion site. Neat!
(not specifically responding to you, just a general response)
Facebook and the NSA aren't the only threats to protect yourself from. Improvements to security aren't bad just because they aren't absolute 100% solutions.
This is likely an attempt by motivated individuals inside an unstructured place like Facebook to get a feature they want out to the public, and less driven by some PM who wants to compete with others.
Your theory seems much more likely, given the probable adoption of this feature :)
Facebook is definitely a place that lets engineers run with ideas, and it is that environment that allowed us build this out as something engineer created, designed, and driven.
I will acknowledge the PMs on the relevant product teams were all great to work with at the points they became involved and understood the problem we were hoping to solve here.
Compromise or loss of the PGP key remains an ongoing problem. Maybe we could persuade Apple to add PGP functionality to their secure co-processor.
And unfortunately, by allowing me to store so much mail (~7.5GB at the moment), gmail has made it effectively impossible to use any other IMAP client – I've left Mail.app and Thunderbird running for days trying to do their initial sync, to no avail. The only client that actually works with the amount of mail I have, and has PGP support, is mutt, and even that takes ~5 minutes to read in its header index on startup.
The end result is I pretty much just don't use PGP unless someone sends me something encrypted (which does happen! But probably this is just because I work in security), and then I break out mutt and resign myself to waiting around a bit for things to load.
In general, they tended to not mesh well with the gmail UI – you could decrypt, but the decrypted message would pop up in a new window. And sometimes it just wouldn't detect that a message was encrypted, so you'd have to select the encrypted text, find the context menu for it, etc. Composing was also more difficult than it needed to be – another extra set of steps to remember before hitting send, rather than something that would be triggered automatically if the recipient was in my keyring.
Basically, the functionality offered usually ended up not being much better than selecting the message, opening a terminal, and doing `pbpaste | gpg --decrypt` (or --encrypt on the way out).
From my experience, it seems to be just about any MUA on any platforms will start choking when it starts getting around 2GB to 3GB -- not only fetching takes forever, but also makes it very unresponsive. We have a few people here using Outlook with Google for Work, and I had to set it up to limit fetching and tell them to go on to mail from a browser for older E-mails as it'll start doing weird stuff when it hits a certain threshold.
I use sup (https://github.com/sup-heliotrope/sup/) as a MUA to manage my mail, with the gpgpme gem [2] I can use gpg almost flawlessy (but I'm biased, I help maintain it :)
I find it more likely that they want to protect and to be seen to protect their users.
So another act in "security" theater for most people. They must keep everyone guessing at what they will do next.
How is this security theater? It's providing an actual, useful service for those who choose to use it. If the majority of people choose not to, then the fault would lie primarily on the end user, not on Facebook.
The good news is:
a) This continues the momentum that the big Valley companies are creating around strong crypto
b) This will motivate people to build better replacements for PGP, because now they know that they might actually receive encrypted emails if they can get sweis and others at Facebook on board.
S/MIME would have been slightly better, IMO, but I understand why they didn't do it that way - Yahoo and Google are working on OpenPGP browser extensions, and "copy/paste your key" is easier than "upload your certificate".
We badly need a modern, fresh take on email end-to-end crypto.
Maybe facebook has some numbers on how many users distrust other major mail providers to the extent to use this, while also trusting facebook.
At least to me, that sounds ridiculous. Because along the measures of distrustfulness of who allows information to propagate to third parties (some third parties more privileged than others…), I don't particularly see any major mail provider above and beyond any other major players…
Considering that most people wont even know what GPG/PGP are, this seems like an exercise in "Don't trust others, but trust me" and the user is supposed to go like "Welp, ok!"? Haha.
Now if we could get the public more aware of it, then that'd be great. :)
In any case, this isn't security theater. There's nothing theatrical about this. This is a real security benefit that has newly been added. Lots of things can be said about PGP in general, sure, but the ability to encrypt the messages from Facebook so that only you can read them is an actual security benefit. The entire concept of "security theater" is something that looks like it increases security but does nothing. By sheer fact that encrypting communications increases security, it can't be security theater.
Except it isn't really "only you", its whoever else has access to the key or keys facebook uses to encrypt such messages and if one distrusts other mail providers that they use to such degree, but trusts facebook, I'd really start question what threat model they are contriving…
No, you are giving FB the public key, and keeping the private key. So anyone with the (public) key you give Facebook could send you messages that you can decrypt with the private key (which is why FB also lets you publish the key on your profile page), but could not read the messages sent by someone else with the same key.
Only you -- or someone else with the private key that you don't give to Facebook -- can read the messages. Of course, if someone breaks PGP so that they can use one half of the key pair to recover the other half, they could read the message just by knowing the key you share with Facebook ... but that that is intractable is the whole foundation of public key cryptography.
Also, how is it "intractable" exactly? If you keep your key safe, you keep your key safe. If you give your private key to anyone and everyone, then it's on you if someone else reads your stuff. There's nothing inherently intractable about this. Either you're good with informational security or you aren't. Facebook has absolutely nothing to do with it.
So now that part of the puzzle has been addressed by facebook without the acknowledgement of the rest, people are suppose to just set this aside?
>…And that would be covered by a Privacy Policy and potentially the Terms of Service.
So a technical implementation with its foundation on a social contract that has and can change at any time is to be trusted…
The parent mentioned:
"Of course, if someone breaks PGP so that they can use one half of the key pair to recover the other half, they could read the message just by knowing the key you share with Facebook ... but that that is intractable is the whole foundation of public key cryptography."
Which I decided to set aside since between the user and privcy policy/tos, are the ones that seem to be the weak points that are often exploited in practice that subverts "security".
To answer your question bluntly, people are supposed to just set this aside here, yes. Because all those things are not at all even remotely related to the topic at hand. If you have concerns about PGP, there's plenty of security-oriented forums you can take those problems to to have them analyzed by actual security experts who would be able to provide much more information about it than we could. If you have concerns about Facebook's policies, then I'm sure there's legal forums and other Facebook-related discussions which would more closely match those concerns. If you have concerns about Facebook itself, well, perhaps you shouldn't be on it in the first place. But regardless, this topic is not the appropriate place for any of these conversations because none of them are about the encryption of notifications from Facebook to you.
To call this one specific feature a net security positive while being willing to silence all else (out side of empty nods to such) that is related to the encryption process for the sake of giving a pat on the back it seems, doesn't inspire much confidence…
No, the "social contract" at issue deals with a different set of concerns than the "technical solution".
The "technical solution" addresses the issue of providing a mechanism to prevent the data sent from Facebook to you being exposed to third parties without you or Facebook intending that exposure.
The "social contract" addresses limits on intentional sharing by Facebook of data related to you (which overlaps with some of the information in the communications protected by the technical solution.)
The former is not the foundation for the latter, they address distinct, though related, issues.
Uh, its the plaintext of notifications sent by Facebook, to you.
If you don't trust Facebook with the plaintext of those, you probably shouldn't have a Facebook account.
This is a means of preventing interception by third-parties not intended to have access by either of the parties to the transaction. Its kind of an orthogonal concern to the degree of trust one has in the other party, though I suppose if one sufficiently distrusts the other party, the risk of accidental interception becomes negligible compared to the risk of intentional disclosure by the other party. But if the trust is that bad, why would you even voluntarily have relationship with that party?
Good question, but It's probably best for those who trust facebook, and complain about parties that have a carte blanche to subvert such security of interception (like government actors and civilian contractors but most don't complain about the contractors) like the crowds do on HN from time to time. I ask that question to myself when I see such complaints being raised…
So really, the only one at fault for someone else reading the message would be the key owner, who's responsibility it would be to store that safely. And once again, we ask, how is this "theater"? Everything points to it being a net positive security wise. If you want to debate PGP, or the usefulness of encryption, then I'm sure there's plenty of forums for that. But in terms of the actual feature that Facebook just implemented, it's a security gain as before we had nothing, and, by definition, can't be called a security theater.
We need better user-agents for dealing with encrypted email.
The issue I have is that it fails to discover my private key, even though gpg2 is clearly aware of it (and Engimail is configured to use gpg2).
I noticed this was somewhat of a sore spot for people when Enigmail started forcing gpg2 instead of letting the user choose. I don't disagree with forcing gpg2, but there were definitely some configuration changes that needed to be made on my system to cope with / reflect that choice.
What really made me happy was K-9 Mail on Android - now I'm not tied to a computer to send or read a secure email.
Facebook? I don't use it, but it is nice to see someone try to get GPG/PGP in front of people.
https://pgp.mit.edu/pks/lookup?op=vindex&search=0x2F3898CEDE...
Surprised that nobody has generated a private key with a UID containing an abusive or self promoting real name/comment, signed Facebooks key with it and uploaded the signature to the keyservers yet. Tempted to sign it with a key with a real name of:
"Software Developer / SysAdmin for hire. See https://mywebsite"
I guess at that point I'd be permanently branded a spammer though. ;)
You could have a pretty high degree of confidence that the public key associated with a Facebook account belonged to the account owner.
Hopefully they'll be come kind of API (if there isn't already).
Either way, I hope http://keybase.io lets me add my Facebook profile now!
That being said, I'm trying my best, and coming up short, in figuring out what problem this would solve...
If this truly is Facebook's intention, I somehow doubt it'll be very successful. I'd like to think it'll encourage more people to start encrypting and signing their emails, although somehow I doubt that as well.
It's only a small "win" for privacy - given that Zuckerberg is on the other unencrypted end of anything "private" this might send, but I can see it as an important win for a few people...
Of course, perhaps this is part of a cooperative or NSLed collaboration with the NSA, "Hey Zuckerberg! We need you to tell us which of your users knows how to use PGP, then give us their entire social graph, the social graph of everybody who's ever uploaded a photo with them in it, the locations of those photos, and any Facebook-javascript-bugged webpages they've ever visited. Thanks."
The first is pretty innocent, the other could get you killed.
That doesn't make encrypted notifications useless in general or otherwise bad, but it's an oversell to say this makes them useful for abuse victims. In fact, selling it that way is dangerous given a sufficiently abusive and motivated adversary as it's false security.
Again, I'm responding to the grand-parent post that said this would be good for abuse victims. It's not all that great, but that doesn't mean it's useless.
Please contact me if you do see anything leaking metadata about the plaintext email.
The parent to my post mentioned that this was a win for people with "overbearing parents" or an "abusive spouse". My response is that the message From field still says that this message is from Facebook, and the subject line apparently says "Encrypted Notification from Facebook". So this is not really a win for someone with overbearing parents or abusive spouses because sufficiently overbearing or abusive people will be on the lookout for any communication from Facebook and will assume the mere fact that the message is encrypted is a sign that it's something they would disapprove of.
That is no way meant to say that the feature is useless, rather that the parent to my post is mistaken about who this feature is useful for. More useful would be an option to have the notification message come from somewhere innocuous - to otherwise make it look like spam. If it did, the PGP encryption would allow the recipient to pick it out of the spam and make sense of it while not alerting others to the fact that it's a message from Facebook.
The more mundane email traffic like this is encrypted, the less encryption will be equated with suspicious activity.
But then exporting your private key and importing it on iOS ... Still a UX disaster, unfortunately.
It's not against you personally, but I never understood how people compare a brutal, murderous gov. agency to something as mild as a social network.
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.4.9 (Darwin)
[0] https://access.redhat.com/documentation/en-US/Red_Hat_Enterp...
[1] https://drive.google.com/file/d/0B9kwqLwGBg_7NGd4QlRreU5hSFE...
[2] https://drive.google.com/file/d/0B9kwqLwGBg_7WlpqUFlEWmRMY2c...
If it's the latter and anyone at Facebook wants someone to look over their implementation, let be know. ;)
If you are interested in looking at the implementation and other interesting security stuff, we have a lot of security openings:
Security Software Engineer - https://www.facebook.com/careers/department?req=a0IA000000G2...
Open Source Security Engineer - https://www.facebook.com/careers/department?req=a0I1200000G4...
PrivateCore Software Engineer - https://www.facebook.com/careers/department?req=a0I1200000G4...
Security Infrastructure - https://www.facebook.com/careers/department?req=a0IA000000G4...
I'm looking forward to when they inevitably (I hope) add support for visualising the Web of Trust
Edit: you either have to install GPGTools (for OS X, https://gpgtools.org/), GPG4Win (https://gpg4win.org) Windows, or gpg for linux. To use GPG in Thunderbird you'll also need Enigmail.
Unless you have an active attacker, in which case they are equivalent.