Live data from Hacker News

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

efail.de

71–80 of 306 posts

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

#71
Matt Green gave a pretty good summary of this: https://twitter.com/matthew_d_green/status/99598925414360678...

Some of these thoughts are echoed by Filippo:

> No, in 2018 you don’t get to claim the high ground and blame users and implementations if your crypto API returns the plaintext on a decryption error.

from https://twitter.com/FiloSottile/status/996010161427935233

So yeah, most clients seem vulnerable but since the command line utility that pretty much no lambda users use is not broken HN is saying that this is a joke?

As for contacting the PGP team, I've tried reaching out Werner Koch many time for a vuln in libgcrypt without success. That was 2 years ago, the vuln is still there.

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

#72
post #68

Earlier quoted context omitted.

The encryption system should be saying "BAD MESSAGE" to the client and instead it is saying "Here's the message and some malware".

I disagree. The encryption system should not know about HTML, and these messages are "BAD MESSAGE"s even if they are unencrypted. That clearly points at the mail client, not the encryption layer.

Both things are problems. The encryption system should definitely be communicating that the message was tampered with...

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

#73
post #60
post #54

Earlier quoted context omitted.

> (in fact I am not aware of any client that is vulnerable to this) > First, the direct exfiltration attack abuses vulnerabilities in Apple Mail, iOS Mail and Mozilla Thunderbird...

I can see how it would work against Apple Mail/iOS Mail since they load HTML and external elements by default. I would be interested to see the attack working on a Thunderbird client with Enigmail installed and no other settings changes (like; loading external resources).

According to this table Thunderbird is vulnerable: https://twitter.com/matthew_d_green/status/99599862678571417...

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

#74
post #29

From the original article: > EFAIL describes vulnerabilities in the end-to-end encryption technologies OpenPGP and S/MIME that leak the plaintext of encrypted emails. I don't understand how this is being touted as vulnerabilities in OpenPGP and S/MIME. Sure there is undefined behavior in the OpenPGP and S/MIME standards but if implementations choose an insecure behavior for the undefined behavior, then it is a flaw i…

Aren't the point of the standards to ensure there is no room for security holes? It seems kind of strange to make the security dependant on the implementation. Imo, it should be impossible to implement the standard in an insecure way.

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

#75

From what I've read, I thought that in modern cryptographic methods you always authenticate and encrypt, in part to avoid attacks like this where an attacker can modify the encrypted message in some way. Does this mean that GnuPG and S/MIME don't authenticate/sign encrypted messages at all? Or that email clients still try to display encrypted messages that are not properly authenticated?

Yup, they don't authenticate encrypted mails.

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

#76

Earlier quoted context omitted.

> I know I'm safe with blocked remote content. Curious, how?

Because the vulnerability is just about adding HTML tags which will send decrypted content to a remote server controlled by attacker. Example : If you disable remote content, it can't be exploited on thunderbird (which is disabled by default) BUT there may be other attack vector on other software/email client. Anyway, the attacker still need to get a hand on your encrypted email.

What about attack vectors like this one (from the paper)?

    For example, in Thunderbird and Postbox
    we can completely redress the UI with CSS
    and trick the user into submitting the
    plaintext with an HTML form if he clicks
    somewhere into the message.
That sounds like something that can easily happen, even with remote content disabled.

(Edit: Formatting)

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

#77
post #50

As if a brand name, logo and website were not enough, even the white paper title is cringy clickbait: "Efail: Breaking S/MIME and OpenPGP Email Encryption using Exfiltration Channels". OpenPGP is not broken. Nothing in your paper has anything to do with OpenPGP. This is simply spreading overblown FUD for your 15 minutes of mainstream media fame.

[deleted]

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

#78
post #3

Robert Hansen just sent the following email to the gnupg-users list: to GnuPG-Users [taps the mike] Hi. I maintain the official GnuPG FAQ. So let me start off by answering a question that is certainly about to be asked a lot: "Should we be worried about OpenPGP, GnuPG, or Enigmail? The EFF's advising us to uninstall it!" https://www.eff.org/deeplinks/2018/05/attention-pgp-users-ne... Werner saw a preprint of this pap…

Werner Koch goes into further detail at the start of the gnupg-users thread @ https://lists.gnupg.org/pipermail/gnupg-users/2018-May/06031...

I'm reading this message with little context but it doesn't strike me as having reasons not to be worried. The two suggestions are: a) not to use HTML emails, which seems unlikely in practice; b) to use an obscure-sounding mode which has been implemented in such a way as to depend on the MUA doing multiple things correctly after the GPG code runs.

What am I missing here? Is the latter mode on by default and MUA are widely known to correctly deal with the error code in a secure way?

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

#80

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…

> I know I'm safe with blocked remote content. Curious, how?

Because the method used relies on accessing remote content.
Post reply on HN