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

51–60 of 306 posts

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

#51

Post by griffinmb »

consp wrote: post #43
mehrdadn wrote: post #22

Earlier quoted context omitted.

How can embedded platforms generate IVs but face trouble generating nonces? Aren't IVs also nonces? Or do you mean a different aspect of it is the problem?

In this case (cbc) the IV is the nonce though for some kind of reason people like to mix words and make everyone's life more difficult. As far as I have encountered, almost always the word nonce applies to some randomization and IV is basically the first data into the system, even if it is not random. Since most embedded platforms have limited entropy and/or no hardware RNG it is more difficult to generate proper dis…

I think the issue is more that nonce reuse with stream ciphers like GCM result in a more catastrophic failure (i.e. secret key disclosure), whereas reusing the IV with CBC will only disclose whether some plaintext was encrypted multiple times. In an embedded platform where there is no easy way to ensure a nonce is not reused, the potential info disclosure may be preferable.

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

#52

Post by A1kmm »

Promarged wrote: post #25

The bug would work only if all of these are true: - only-encrypted (not signed) message (signing is good practice), - clients that do not do MDC (MDC was introduced in 2000, every non-prototype client uses it) - client that rendered HTML mail with broken markup, - client that automatically fetches remote resources. tl;dr this is a very narrow case

> only-encrypted (not signed) message (signing is good > practice),

Or the client decrypts it even if unsigned, or the attacker signs the message.

> clients that do not do MDC (MDC was introduced in 2000, every non-prototype client uses it)

I think the client would not only need to use MDC, but also enforce its presence and validity, which is somewhat more likely to allow an attack.

> client that rendered HTML mail with broken markup,

The HTML5 specification defines exactly how HTML inputs should be processed for nearly every possible input, so this applies to any HTML5 compliant email client.

> client that automatically fetches remote resources

I have this turned off in my client, but many email users these days (possibly even those using GPG) have settings to automatically download remote content.

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

#53

Post by r3bl »

rocqua wrote: post #23
oblio wrote: post #6

While HTTPS is taking over web traffic, encrypted email could be considered a failure, at this point. I wonder what percentage of emails are encrypted using GPG. Based on my experience it's probably less than 0.001%.

/Donns alufoil hat Google likes HTTPS, it makes the web safer, and keeps middle-boxes from interfering with their stuf. However, Gmail likes access to the plaintext stuff. They no longer use email content for ad-targeting, but they still need this access for spam-filtering and auto labeling. Gmail is essentially e-mail for a lot of people, so what they do matters.

HTTPS means encryption in transit.

Email are also encrypted in transit (almost) universally.

Encryption in transit has absolutely nothing to do with keeping the data hidden from the service you're visiting.

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

#54

Post by veeti »

AnaniasAnanas wrote: post #18

To be honest, this is a really bad joke. Not only did they chose to go directly to the media/EFF without even informing the GPG people but they also attacked them[1] for not keeping quiet. Not to mention all the fud that was spread for an issue that is not even caused by GPG but by bad clients (in fact I am not aware of any client that is vulnerable to this). Shame both to the publishers of this and to the EFF for he…

> (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...

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

#55

Post by simias »

kennell wrote: 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.

I don't even understand why they needed to tease the thing one day in advance with measures that were so weird that nobody knew what to expect. "Stop decrypting email", right, super convenient and totally appropriate given the actual vulnerability. Next time maybe they'll say "don't touch your mouse until further notice". What difference would it have made if they had simply published this website straight away? Seemed like they were releasing the teaser for the next Captain America movie or something.

This reminds me a bit of the "amdflaws" debacle, although that one was even shadier and might have been an attempt at manipulating AMD's stock price.

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

#56

Post by Sir_Cmpwn »

Even setting aside that this is an excellent example of how toxic the security community is, the real problem here is that HTML email is a steaming pile of crap. The number of vulnerabilities introducted by the mind bogglingly stupid idea of putting HTML in emails is staggering. You're better off only reading plaintext emails and sending the rest to /dev/null. Bonus: this gets a good deal of spam out of your inbox!

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

#58

Post by noguespi »

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 fully or wait.

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

#59

Post by simias »

jcims wrote: post #16
simias wrote: post #9

Earlier quoted context omitted.

PGP and HTTPS have very different trust models so it's comparing apples to oranges. That being said I agree that PGP failed to gain widespread adoption even though I personally use GnuPG daily and sign all of my emails. I'm still hoping that it'll make a comeback but I'm not holding my breath.

S/MIME uses a trust model similar to HTTPS, is built in to most clients and still has almost zero adoption. I think the issue is that HTTPS is a pain in the ass for a few, while encrypted email is a pain in the ass for everyone. Between client cert distribution to wonky webmail support to escrow challenges for regulated orgs it requires deliberate effort for all parties forever.

Yeah S/MIME probably overlaps with HTTPS a lot these days, especially in corporate environment where it makes the most sense. Just setup an encrypted connection with the company's messaging platform and you're good.

For personal email GPG is still pretty much the way to go if you don't want to trust any 3rd party though. Few people seem to care about that these days however. The fact that GPG's UI is abysmal doesn't help.

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

#60

Post by dijit »

veeti wrote: post #54
AnaniasAnanas wrote: post #18

To be honest, this is a really bad joke. Not only did they chose to go directly to the media/EFF without even informing the GPG people but they also attacked them[1] for not keeping quiet. Not to mention all the fud that was spread for an issue that is not even caused by GPG but by bad clients (in fact I am not aware of any client that is vulnerable to this). Shame both to the publishers of this and to the EFF for he…

> (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).

Post reply on HN