Slashdot Mirror
Encrypted Email Has a Major, Divisive Flaw (wired.com)
An anonymous reader quotes a report from Wired: The ubiquitous email encryption schemes PGP and S/MIME are vulnerable to attack, according to a group of German and Belgian researchers who posted their findings on Monday. The weakness could allow a hacker to expose plaintext versions of encrypted messages -- a nightmare scenario for users who rely on encrypted email to protect their privacy, security, and safety. The weakness, dubbed eFail, emerges when an attacker who has already managed to intercept your encrypted emails manipulates how the message will process its HTML elements, like images and multimedia styling. When the recipient gets the altered message and their email client -- like Outlook or Apple Mail -- decrypts it, the email program will also load the external multimedia components through the maliciously altered channel, allowing the attacker to grab the plaintext of the message.
The eFail attack requires hackers to have a high level of access in the first place that, in itself, is difficult to achieve. They need to already be able to intercept encrypted messages, before they begin waylaying messages to alter them. PGP is a classic end-to-end encryption scheme that has been a go-to for secure consumer email since the late 1990s because of the free, open-source standard known as OpenPGP. But the whole point of doing the extra work to keep data encrypted from the time it leaves the sender to the time it displays for the receiver is to reduce the risk of access attacks -- even if someone can tap into your encrypted messages, the data will still be unreadable. eFail is an example of these secondary protections failing.
The eFail attack requires hackers to have a high level of access in the first place that, in itself, is difficult to achieve. They need to already be able to intercept encrypted messages, before they begin waylaying messages to alter them. PGP is a classic end-to-end encryption scheme that has been a go-to for secure consumer email since the late 1990s because of the free, open-source standard known as OpenPGP. But the whole point of doing the extra work to keep data encrypted from the time it leaves the sender to the time it displays for the receiver is to reduce the risk of access attacks -- even if someone can tap into your encrypted messages, the data will still be unreadable. eFail is an example of these secondary protections failing.
No need. The morons making "modern" mailers just need to learn about the basics of security.
Most ACs are not even worth the keystrokes to insult them. Be generically insulted by this and ignored otherwise.
This sentence stuck out to me:
The eFail attack requires hackers to have a high level of access in the first place that, in itself, is difficult to achieve. They need to already be able to intercept encrypted messages, before they begin waylaying messages to alter them.
My response would be that if you're not worried about someone intercepting your email, then why are you encrypting it in the first place? This is essentially a MiTM attack, which is exactly what encryption is designed to protect against. If it can't protect against it, the encryption has completely failed.
I'd say that's the case here. This isn't one of those silly edge cases certain security people jump up and down over nothing. Like "well first you need root access, and then you can get an even higher level of security access!". This is a real, bona-fide hack. Congrats to the researchers who found something real.
Any email program which respects html instructions to automatically load external content was badly broken from a security perspective even before you consider the errors the researchers here exposed.
Any email program which directly fixes the hack without barring external content from loading when the email opens remains badly insecure.
Moderating "-1, Disagree" is simple censorship. Have the guts to post your opinion.
Bad guy intercepts encrypted email he wants to read. (MITM). He injects additional HTML data into the email (in his possession).
Except the email is still encrypted at this point. How could they inject HTML into an encrypted email?
So, yes, this does act as MITM.
Except the scenario you invented is not what this flaw is about and flaw doesn’t allow tampering with the encrypted email while in transit. The email isn’t decrypted until it reaches the email client and the email client has to be one of the buggy ones that don’t actually check the failure return.
So the fix, as usual, is to disable HTML in your mail client.
And also to persuade every person that *you* send encrypted email to to do the same. Good luck with that.