Mozilla announces PGP Support in Thunderbird, coming 2020
blog.mozilla.org
blog.mozilla.org
Like take their rewrite of their android browser. It's faster than Chrome and is currently in preview.
Add-on support is work in progress but they got plenty of snarky attacks that it's not in MVP.
The whole DNS over HTTPS attacks seemed focussed on Firefox, a browser with a tiny marketshare compared to Chrome who also implements it.
Take a look: https://addons.mozilla.org/en-US/firefox/addon/search_by_ima...
The thing is about forward secrecy it's only really useful in situations where the communication is real time. Email is not.
https://arstechnica.com/information-technology/2016/12/signa...
If you're concerned about that storing it on a hardware key (like a Yubikey) is the way to go.
That being said, I wish PGP had at least a casual PFS Extension. I've imagined ideas like an ephemeral key server that can deletes keys after awhile (you could run your own), and/or including futures keys to use in replies in the signature block.
> As far as I know, Brown et al.'s proposal is not often used. One reason for this is that forward secrecy is not always desired. For instance, if you encrypt a backup using GnuPG, then your intent is to be able to decrypt it in the future. If you use forward secrecy, then, by definition, that is not possible; you've thrown away the old decryption key.
They are two different tools for two different jobs.
User donations account for a lot of the work that has been done in the last year. It has allowed them to hire full time and contract workers for Thunderbird. If you want to see the project continue to progress dropping them a recurring donation would be awesome [2].
[1] https://blog.mozilla.org/thunderbird/2017/05/thunderbirds-fu... [2] https://donate.mozilla.org/en-US/thunderbird/
> Email is insecure. Even with PGP, it’s default-plaintext, which means that even if you do everything right, some totally reasonable person you mail, doing totally reasonable things, will invariably CC the quoted plaintext of your encrypted message to someone else (we don’t know a PGP email user who hasn’t seen this happen). PGP email is forward-insecure. Email metadata, including the subject (which is literally message content), are always plaintext.
In 2020, someone should know better than to to add pretend encryption to email. The metadata leaks alone should lead you to conclude that this isn't worth doing.
Don't use email for secure communications, period. Use a secure messaging app like Signal, instead.
1. PGP email is easy to screw up, even with client support.
2. If you need PGP to work, those screwups are life-threatening.
This isn't an abstraction or a just-so argument. PGP team members have, in the recent past, discussed how DoS attacks on their keyservers were upsetting because dissidents in specific, murderously authoritarian countries were ostensibly relying on PGP.
(They mostly aren't, by the way; they use Telegram, which I trust even less. At least I believe the PGP people mean well.)
There are few exceedingly narrow use cases for secure email (where "thou must use email" is requirement #1). So minimal support for decryption of email (and understanding application/pkcs7-signature) isn't necessarily a bad thing. And while you're doing it, you might try to make the UX harder for people to do things like quote encrypted text in plaintext messages.
But I do think it's improper to make ease of PGP or S/MIME use a primary touted feature, and I wouldn't recommend its use to lay users. In other words, support it, but don't advocate it. (I am probably in disagreement with the rest of the Thunderbird team here).
I don't buy that argument. Every time I can remember where I've wanted to use email encryption has been a situation where I was fine with the metadata leaks. E.g., it was email to someone I regularly correspond with, on a subject we regularly correspond on, at a time when we would be expected to be corresponding on this subject. It only differed from our normal correspondence in that I had one or two things I wanted to include in the body that were more sensitive than normal.
The two real reasons to avoid encrypted email are:
1. There's no realistic way to do it with forward secrecy, so any point-in-time compromise of a key --- which is inevitable --- will decrypt every message ever sent through that user.
2. Email is default-plaintext, and most people who have used PGP or S/MIME "at scale" have seen people repeatedly forget or misconfigure and send plaintext replies to encrypted emails, often with the plaintext of previous messages quoted.
Both of those reasons are, for me, dispositive.
Often who you're talking to is not sensitive. What you were talking about on the other hand might be.
https://arstechnica.com/information-technology/2016/12/signa...
With things like MTA-STS and DANE we're only gonna get metadata leaks really to the mail servers themselves.
> Don't use email for secure communications, period. Use a secure messaging app like Signal, instead.
This assumes you're okay in giving everyone your phone number. What if you do that and then one of your contacts starts calling you all the time?
So then it's suggested to have two SIM cards. Here in my country that either means post paid paying a monthly bill or pre paid, and having to recharge it or lose it.
It's not like we haven't seem SIM jacking related attacks either.
Phone numbers are a really terrible identifier.
I am also curious to know what will happen if the US/UK ever passes laws like Australia did. Signal LLC is American, and therefore would have to comply with the laws there if they ever passed something like Australia did.
Realistically if we're going to throw PGP out, we shouldn't be suggesting centralized systems as an alternative. Has anyone forgotten about William Barr? He's been trying all year to get backdoor in Whatsapp E2EE, the same E2EE used by Signal.
The same as if they start emailing you all the time: you block them.
And since phone numbers are harder and costlier to just generate and use, that block is more meaningful blocking an email address.
> And since phone numbers are harder and costlier to just generate and use, that block is more meaningful blocking an email address.
You might think that but throwaway phone numbers can be bought cheap for the purpose of spamming.
I cannot think last when I got spam emails in my inbox. I can however think of when I got spam SMSes. It's also obviously cheap enough they can use robots to say things too.
Could this be because someone who knew my number had a compromised phone? quite possibly. I am not very happy about Facebook having my phone number even though I don't have an account with them.
I agree with the other complaints but not this one.
If my human client, who demanded I use PGP, does something stupid with the email, that is not my problem (The bits are colored blue like you asked--the fact that you uncolored them again is your fault).
People forget that computer tasks in the real world are often more about liability transfer than actual security.
Instead, you both should have used a secure messaging app like Signal, which doesn't have a prominent UI button to forward messages in plain text.
And using PGP in some scenarios has an advantage for the users and is indeed less convenient for eavesdroppers. It seems that the later are especially motivated to promote fear against PGP.
The point isn't "use non-PGP email", the point is "don't use email at all for secure communications. Use a secure messaging app instead."
The point is that you forwarded the secret in plaintext, because email is plaintext by default, and the forwarding person probably didn't realize that, because no email client (even with GPG plugins) posts a big red warning label saying "stop! this is plaintext" because that's 99% of all emails.
I've used a plugin that did exactly that: warned when the encrypted e-mail is replied to or forwarded as plain text.
If such a plugin is not commonly used with e-mail clients that can't be a proof that e-mail encryption is inherently bad, just that that feature should exist.
Mozilla implementers, I hope you're inspired.
- PGP isn't always the proper solution.
- Yes, you do need to be aware of what metadata is involved and what it exposes. This applies to all systems.
- Secure communication is much more than key selection.
- Mozilla taking steps to integrate it into Thunderbird should be applauded.
Mozilla should include a proper PGP implementation in their browser. In fact, I have no idea why a browser that positions itself as pro-privacy doesn't already have a way to sign, verify, encrypt and decrypt text.
As far as I can tell, there wasn't even a discussion about this, which is ridiculous, considering the web (if you count it as a single system) is clearly the biggest communication platform in the world today.
I know it's not exactly that, but if anyone wants to use PGP in the browser with webmail clients, there's Mailvelope[0].
What I like about it is that you can use it with GnuPG as a backend[1], so I can sign and decrypt emails in the browser with an OpenPGP smartcard without importing private keys.
Maybe something built on top of Webauthn is possible? I guess we have to wait and see.
The current PGP/GPG implementation Enigmail is XUL, and been available for years.
> To process OpenPGP messages, GnuPG stores secret keys, public keys of correspondents, and trust information for public keys in its own file format. Thunderbird 78 will not reuse the GnuPG file format, but will rather implement its own storage for keys and trust.
First reaction: Yay! We'll get to manage everything twice!
Second reaction: I am hopeful they'll support private keys stored on smartcards (i.e., Yubikeys, "real" smartcards, and OpenPGP cards) although, if the support in Firefox is any indicator, I wouldn't bet on it actually being "usable".
IMO this is great news. GnuPG is, IMO, awful. Every time I use it I dislike it more. I recently set up a new subkey using a hardware token and the whole experience made me wish that someone would implement a better way to deal with OpenPGP messages.
I doubt GDPR has anything to do with this. We don't have GDPR in my country and they use offerings from Symantec Encryption Server.