Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

efail.de

Post reply on HN
Print view View original

201–210 of 306 posts

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#201

Post by JoachimSchipper »

tptacek wrote: post #113
noguespi wrote: post #58

A lot of buzz for a not so critical vulnerability. Well it is critical but very hard to exploit because : 1. Hacker need to intercept the encrypted email. 2. HTML tags/remote content are blocked by default on most email client. Still an important vulnerability, but not enough (for me) to disable enigmail, I know I'm safe with blocked remote content. By the way I hate this kind of "buzz" disclosure. Just disclose full…

Encrypted mail that only works when attackers can't intercept your mail might just as well not be encrypted.

It's not exactly PGP's security model, but: - if you use SMTP-via-TLS and (IMAP/POP/MAPI)-via-TLS, attackers really can't intercept your mail - unauthenticated encryption still protects your mail spool at rest.

Of course, attackers gaining access to your mailbox is still game over, due to password resets etc. via e-mail; but "attackers can't intercept your mail" is a more realistic assumption in 2018 than it was when PGP was designed.

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#202

Post by mjw1007 »

tptacek wrote: post #152

This is the worst reaction to a serious and interesting vulnerability I think I've ever seen on HN. The problem being exploited today is that PGP isn't properly authenticated. PGP has an authenticator, but it's simply the SHA-1 of the plaintext appended to the message. Since even that SHA-1 was a later addition to the protocol, mainstream PGP implementations will process messages that lack the hash and decrypt the me…

> But popular mainstream GPG clients don't honor that warning, which doesn't say "Stop, don't process this plaintext I am showing you", but rather "message was not integrity protected".

As more information is coming out, it begins to seem that this is not the case: it looks like most GPG clients do detect the warning/error.

Looking at the table in the paper, most clients weren't vulnerable when using GPG rather than S/MIME.

Thunderbird is listed as vulnerable and would count as a popular mainstream client using GnuPG, but it appears that it (ie, enigmail) is not in fact vulnerable:

https://twitter.com/robertjhansen/status/995977877375070209

According to https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06033..., if a gnupg client uses --status-fd and there's no MDC, it will get

    [GNUPG:] DECRYPTION_FAILED
and it won't get the usual

    [GNUPG:] DECRYPTION_OKAY
Further, according to the paper gnupg "returns an error code" in this case, which I take to mean a nonzero exit status.

It that's true, I don't think the situation is at all as bad as you make out.

AIUI using --status-fd has been the usual thing for clients for a decade or so (it isn't a matter of "oh, didn't you know you should use --status-fd, I'm sure it's in the small print somewhere").

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#203

Post by AnaniasAnanas »

jwilk wrote: post #35
AnaniasAnanas wrote: post #31

Earlier quoted context omitted.

Also relevant https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06032...

This seems to contradict the earlier claim that "the GnuPG team was not contacted by the researchers".

Maybe they forgot about it, or assumed that it was a different vulnerability especially since the original was a non-issue. Not a terrible thing to assume when the last communication with them was 6 months ago and they did not bother to give them the new paper. IMHO, the only unethical part on the side of the researchers is that they spread the whole "GPG is vulnerable!" FUD and went directly to the media when they had been informed that this is not a GPG issue beforehand. The other unethical part is that the EFF and the media companies did not bother to take GPG's side of the story.

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#204

Post by gsnedders »

deong wrote: post #105
gepeto42 wrote: post #97

Encryption plugins on top of other mail clients has always been a recipe for disaster. That being said, why would EFF tell people to completely uninstall it? When I hear that, I think "There is a crazy, in the wild, no user interaction needed remote code execution vulnerability". If someone had a use for PGP/GPG email (assuming they understand the threat model and the metadata that is not encrypted), surely they're b…

I believe the recommendation is to use something like Signal or iMessage -- an end-to-end encrypted channel that isn't email.

And which have perfect forward secrecy, which PGP will never have without adding some new per-message communication between the two parties (which would totally violate the layering on top of email).

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#205

Post by e12e »

deong wrote: post #102
klez wrote: post #98

Earlier quoted context omitted.

> not to use HTML emails, which seems unlikely in practice In a context where pgp is used, which is not me receiving promotional material or forwards from Grandma, why do you consider it unlikely that mail is to be sent as plaintext and not as html?

Almost every email client defaults to HTML. There are going to be people using both encryption and HTML.

The idea that you can combine full hypertext and security is absurd. IMNHO this is the most significant problem with email (and many "secure" messaging stacks that allow "rich content"). Sure, it's possible to define a secure subset of html (basically bold/italics/underline, tables and headers).

But everyone adds transclusion (in-line rendering of linked content, which leaks data and opens up the door to bugs), fonts (ie: programs), images (historically not a great idea), and some even Javascript!

And that's not even all the muas that runs in the browser, and try to expose some safe subset of itself to be used for rendering the mail body.

So, html Email is insecure, when contrasted with plain text email.

Using pgp as "code signing" for hypertext applications ("html emails") isn't nearly enough.

Sadly, afaik there's no agreed "safe" rich text format for mail. Absurdly rtf would probably be better than html mail.

Anyway, I don't see how anyone could expect html mail to be safe in the first place.

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#206

Post by xoa »

tptacek wrote: post #194
baby wrote: post #186

Earlier quoted context omitted.

The problem with emails is that you have to deal with a thousand different clients implementing things differently. There is no win there.

I think you misunderstood his argument. It was, "no".

Your argument is "everybody on the planet including all corporations and governments should instantly abandon email for an instant messenger thing instead of which there are many and no federation" which is a bullshit argument and you damn well know it. FFS, how often over the decades in security have we had to make do with highly suboptimal solutions that were the lesser of evils? When did you of all people become a head-and-feet-in-the-clouds pure idealist?

It's like coming into a global warming discussion and demanding everyone forgo personalized point-to-point mechanized transportation because of inherent inefficiencies vs mass transport. Or saying IRC is shit and therefor everyone should move to mailing lists or whatever. It's worse then even suggesting moving to something that's still "groups in 'rooms' with instant messaging" which at least is a technical feature match, it's suggesting dropping an entire UX. It's not happening. Path dependency is a thing, and so are specific desirable features that can be used alongside other channels for different tasks.

I gave reasons. You're the one implying everyone who doesn't dump a straight forward, desirable UX global standard for a bunch of silo'd different formats are idiots/old fogies/don't care about security/privacy at all. The very simple fact that even accepting dumping that UX for messaging service you still couldn't simply say "switch to this only" but had to list a couple of things further highlights the whole problem. Is every individual and organization on the planet also supposed to support every single secure messenger? If not what is the winner vs the losers tptacek? Saying I had no argument but"no" and ignoring everything else is insulting sure, but I also think it's not a helpful attitude to making the world a more secure place period.

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#207

Post by jolmg »

Were the development teams of Apple Mail, iOS Mail and Mozilla Thunderbird contacted about this and given time to fix their issues before publication? The page makes no mention of this. It makes it look that this wasn't disclosed responsibly.

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#208

Post by e12e »

dmix wrote: post #133
Tyr42 wrote: post #125

Earlier quoted context omitted.

Yeah, mutt is safe https://pbs.twimg.com/media/DdJ_d_wWsAEclUs.jpg:large

And the K-9 app seems safe which is the most popular way to use PGP on Android.

If true, that's great news. There are plenty of decent cli/desktop clients that make it easy to avoid html mail. Not so for Android, where apps seem likely to wrap some rich content control in order to render text (as html).

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#209

Post by e12e »

tptacek wrote: post #120
mehrdadn wrote: post #17

Tangent: Is it just me or does CBC (and block ciphers in general) always seem to be a troublemaker? Even if it's not directly at fault, it seems to always make everything more difficult to secure, and I don't recall ever having heard of a single benefit gained by using them. Why do people insist on using block ciphers instead of stream ciphers? What benefits do they have?

It's not block ciphers versus stream ciphers. CFB mode is a stream cipher and is implicated in this attack. CTR, the canonical stream cipher, is even more malleable than CBC. The problem is authenticated versus non-authenticated ciphers. CBC, CTR, and CFB are non-authenticated cipher designs. EAX, GCM, and OCB are authenticated designs.

I've always had S/mime in the back of my mind as an alternative for intranet/internal secure messaging (with optional escrow/archiving) - the assumption being that users would all have certs, there'd be a directory (ldap) - and things would be ok-is(granted metadata would be an issue). Never had i dreamt that S/mime didn't use a sane authenticated cipher configuration (if only by public key signature wrapping traditional ciphertext).

I mean that was the whole concept of S/mime, right? Federated key/trust and public key cryptography?

Re: EFail – Vulnerabilities in end-to-end encryption technologies OpenPGP and S/MIME

#210

Post by tptacek »

mjw1007 wrote: post #202
tptacek wrote: post #152

This is the worst reaction to a serious and interesting vulnerability I think I've ever seen on HN. The problem being exploited today is that PGP isn't properly authenticated. PGP has an authenticator, but it's simply the SHA-1 of the plaintext appended to the message. Since even that SHA-1 was a later addition to the protocol, mainstream PGP implementations will process messages that lack the hash and decrypt the me…

> But popular mainstream GPG clients don't honor that warning, which doesn't say "Stop, don't process this plaintext I am showing you", but rather "message was not integrity protected". As more information is coming out, it begins to seem that this is not the case: it looks like most GPG clients do detect the warning/error. Looking at the table in the paper, most clients weren't vulnerable when using GPG rather than…

Thunderbird and Apple Mail/GPGTools, two of the most popular PGP mail clients, are vulnerable. The table in the paper makes the situation look better than it is by displaying niche clients with very few users alongside the major clients that everybody uses.

Like I said upthread: the right answer (it's not even debatable; cryptography engineers deliberately design crypt constructions to have this property) is not to provide unauthenticated plaintext to callers at all. This isn't news. Whatever dumb warnings GPG prints are besides the point.

Post reply on HN