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

221–230 of 306 posts

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

#221

Post by EthanHeilman »

jolmg wrote: post #207

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.

>It makes it look that this wasn't disclosed responsibly.

Not sure how anyone could say if the disclosure was or was not responsible based on who got advanced warning. Full-disclosure, i.e. all details without any prior warning, can be responsible disclosure. Coordinated disclosure, i.e. providing advanced warning, can be less responsible than full disclosure. It depends on the circumstances and surrounding context.

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

#222

Post by AnaniasAnanas »

tptacek wrote: post #212
xoa wrote: post #206

Earlier quoted context omitted.

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…

Yes, us head-in-the-clouds idealists with our pie-eyed demands that encrypted message protocols not leak the contents of our messages to anyone who can intercept them . What will we demand next, forward secrecy? We should climb down from our ivory towers.

> not leak the contents of our messages to anyone who can intercept them

Already a thing, next?

> forward secrecy

There is https://tools.ietf.org/html/draft-brown-pgp-pfs-03 but to be honest forward secrecy in general does not make much sense in the context of email or backups.

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

#223

Post by xoa »

tptacek wrote: post #173
rocqua wrote: post #170

Earlier quoted context omitted.

It woulds still be great to get some sort of protocol that will work over email. This is still the de-facto way of communication. If we can secure it, it would be a massive win. Much like the wide-spread use of HTTPS over HTTP was a massive win.

Why would that be a good thing? You'd still be left with a system that leaks immense amounts of metadata, which is often all government adversaries really care about, where the majority of the installed base isn't encrypted and you have to interoperate, and the vast majority of users gets access to messages through a web browser and so is hamstrung on secure delivery of encryption in the first place. Just stop using…

>Just stop using email to deliver secrets.

At the least I'm not sure this is legally feasible under ERISA electronic delivery requirements, to name a single one amongst a host of other often incredibly complex regulations. It might be ok under the UETA, but either way that wouldn't be my call.

I am 100% sure that it wouldn't be ok with coworkers, customers, and in turn bosses, so demanding to cease all usage of email would get me fired. I mean, even entirely plain text email isn't sufficient to get anyone to stop using it to deliver secrets. It's been a real improvement just to have the MUAServer connection be encrypted, and even that is probably still not universal!

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

#224

Post by shinigami »

tptacek wrote: post #193
shinigami wrote: post #191

Earlier quoted context omitted.

I agree they should have done that as a stopgap measure, but we should push for security in all cases (e.g. streaming AEAD with STREAM or CHAIN https://github.com/miscreant/miscreant/wiki/STREAM )

I'm not super psyched to see 1990s crypto vulnerabilities used as an opportunity to promote hipster schemes that literally nobody uses. Virtually all modern cryptosystems handle this problem already.

AEAD was also a hipster scheme that literally nobody used. That's the whole point.

In Twitter you even linked to Adam Langley's post where he suggests something exactly like STREAM/CHAIN!

Which modern cryptosystems handle this problem? Tahoe-LAFS is the only one that comes to mind. Not being snarky here, I'm genuinely interested in knowing this.

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

#225

Post by yacn »

tptacek wrote: post #220
yacn wrote: post #218

Earlier quoted context omitted.

Why don't you recommend it?

Wouldn't a bunch of secure messenger drama be fun right now?

Sorry, I'm just not nearly as familiar with the intricacies and differences between them, know that you definitely know your stuff on crypto, and always thought Matrix seemed cool/interesting.

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

#226

Post by xorcist »

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…

> If you strip the SHA-1 hash off a message, GPG will print a warning.

That's far from the whole story. If you strip off the authentication, GPG will fail with an error. Not a warning message.

(Over a socket, gpg will have started sending real data before failing, due to a bad and ancient design. OpenPGP can improve here, so let's point out the real problems instead of making up simpler ones for the sake of a good story.)

If your mail client supports encrypted email silently ignoring errors there's going to be more attacks possible than this one. And if you're parsing untrusted HTML with Outlook 2007, well, that might be problematic in itself.

I don't think anyone is dismissing the attack itself, but the communication around it could have been a little better. Most use of GPG takes place outside of MUAs.

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

#227

Post by AnaniasAnanas »

dewyatt wrote: post #94
AnaniasAnanas wrote: post #36

Earlier quoted context omitted.

OpenPGP does have a way to authenticate the messages, see https://tools.ietf.org/html/rfc4880#section-5.13 .

Also tag 20 is the newer AEAD method: https://tools.ietf.org/html/draft-ietf-openpgp-rfc4880bis-04...

Thanks for that, I was not aware of the draft.

It seems that they provide support for OCB and EAX. I would prefer support for chapoly to be honest.

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

#228

Post by jwilk »

cyphar wrote: post #167
AnaniasAnanas wrote: post #26

Earlier quoted context omitted.

GPG is not a standard, the standard is OpenPGP. As for the tools, they seem very easy, especially engimail which IS 1-click setup. > add generic messages about encryption in alternate mime content bodies and simply encode the encrypted messages into it's own This is exactly what it is doing. PGP/MIME is a thing.

> the standard is OpenPGP The standard is PGP. OpenPGP is an implementation.

No. OpenPGP is the standard.

PGP and GPG are implementations of this standard.

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

#229

Post by FrantaH »

tc wrote: post #138

Let's summarize the situation: Abstract: S/MIME and MUAs are broken. OpenPGP (with MDC) is not, but clients MUST check for GPG error codes. Use Mutt carefully or copy/paste into GPG for now. - Some mail clients concatenate all parts of a multipart message together, even joining partial HTML elements, allowing the decrypted plaintext of an OpenPGP or S/MIME encrypted part to be exfiltrated via an image tag. Mail clien…

Check RFC2634 before you abandon S/MIME. Triple wrapping solves surreptitious forwarding, which is how this attack works. Sadly AFAIK it's implemented only in Trustedbird.

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

#230

Post by tptacek »

xorcist wrote: post #226
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…

> If you strip the SHA-1 hash off a message, GPG will print a warning. That's far from the whole story. If you strip off the authentication, GPG will fail with an error. Not a warning message. (Over a socket, gpg will have started sending real data before failing, due to a bad and ancient design. OpenPGP can improve here, so let's point out the real problems instead of making up simpler ones for the sake of a good st…

GPG provides unauthenticated plaintext to callers. It needs to stop. There's not much more to discuss.
Post reply on HN