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.
Same story still on the front page.
I'm hoping this will spur development of a new encryption standard that's both secure and easy to use.
If youâ(TM)re serious about your email security the first thing you would do is disable HTML email in your client. This is an attack thatâ(TM)s easily mitigated by observing the bare minimum of best practices.
To me this sounds like entirely an email client issue AFTER the message has been decrypted. or malware that manages to alter the message BEFORE it gets encrypted.
This does not sound like any kind of flaw with PGP itself, just in the leaky sieve of an email client that users choose to use with it.
https://it.slashdot.org/story/18/05/14/149222/attention-pgp-users-new-vulnerabilities-require-you-to-take-action-now
Is the flaw that Slashdot editors posted a duped story?
was always a bad idea.
Old news and it's not PGP and S/MIME, but the mail clients that can use them: Thunderbird and Apple Mail and Outlook. Probably also affects clients using GPG. Or any other encryption scheme.
PGP is not broken. GPG is not broken. S/MIME is not broken. The flaw is in how mail clients display email. Admittedly, a lot of them have the same issue.
This is why I never use encrypted email. I've never trusted it.
(see title)
#DeleteFacebook
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.
She should have done it yesterday - mother's day
Or you could get a clue.
It is NOT a MITM attack, not even close.
It is a VERY dubious 'attack' that required the email to load other, non secures content via normal http which they then ALSO intercept, inject content that magically takes control of their computer and steals the unencrypted email. You would never several layers of flaw and a high level of network control over the targets computer in the first place.
Basically, if they use a normal browser and you had this level of control then you could own their computer anyway, so the 'email' part is of exactly zero relevance.
Mitigation: Dont send emails with external http references (quite rare anyway for anything normal outside marketing flyers), or use an email program that doesnt load them by default, or have them loaded from a secure (https) source, or do just about ANYTHING competently.
This is like saying locking your front door has a HUGE SECURITY PROBLEM because you left the back door and all the windows wide open..
Here's a "pro tip" from grandpa:
When you see a fancy website for an exploit, chances are that the authors are attention-hungry acclaim-mongerers that want something for their resumés. Responsible security researchers report the vulnerabilities responsibly. Websites like this are pure ego-stroking.
Don't use HTML Email and the problem goes away. I find that 99% of the time, there is no need for an HTML part to Email, anyway. This whole vulnerability is due to HTML parts being displayed AUTOMATICALLY and WITH loading external parts/links. (If you want to show something external, then just send a link, I don't need a web site "Emailed" to me).
Or, use a "real" Email client (like Claws and perhaps others) that allows you to control how Email is displayed. For example, Claws will happily-
1) Not display the HTML part at all and just show plain-text (the default).
2) If the Email is in violation of rules and has no plain-text part, it will just invent one out of the HTML body.
3) If you DO want it to display the HTML (with a plugin), then there are settings to disable any external component loading
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.
eh?
Or they could just read it over your shoulder. Eitehr way.
I don't get it and I haven't RTFA. From the summary it seems that the attacker manipulates the encrypted message in way that makes it do certain stuff in HTML. Do they mean that they manipulate it in a way that they add external links to be loaded at rendering time? If so, doesn't the ciphertext also have a hash check that will make any attempt to tamper with the data evident at decryption since the hashes won't match?
This 'major, divisive flaw' is something that needs multiple conditions before it can execute:
- Someone who uses encrypted email but doesn't disable automatic image loading in the client
- Client that can't handle malformed HTML inputs and processes unterminated src tags in a weird way
- Message tampering warnings by the PGP or GPG library are ignored
- Server address where the plaintext will get uploaded thru uuencoded resource requests
I wonder if there are clients that, when user has disabled image loading, would still end up auto loading other content (eg. CSS links)? If so then this could be readily exploited far more often in the wild, with the proviso that the attackers don't care about leaving trails of their server address in client & router logs.
Divisive?
And just how is this security flaw tending to cause disagreement or hostility between people?
Once I saw Beauhd's post I tried to link it back as old news... to an earlier /. post from msmash hours before... but apparently my lack of using the word "dupe" in the subject line... got it auto-moderated into oblivion?
So sad. Thumb's up to msmash and thumbs down to BeauHD for a complete lack of reading previous topics on this website before proclaiming total information dominance on a topic that was hours old.
Peace out.
Fueled by Microsoft, then Apple, and with the involuntary help of Mozilla ("we would become irrelevant otherwise!").
Whoever thought receiving HTML mails was a good idea. Especially when they trigger "actions" (CSS, loading of media, perhaps Javascript or Flash -- what do I know how far the bad taste goes?) on the vulnerable (because decrypted) client side.
Any sufficiently advanced stupidity is indistinguishable from malice.
(Sorry, Clarke & Hanlon).
S/MIME was made in a world where mail was passed, un-encrypted on SMTP port along a chain of mail servers for every company on the internet. anybody operating any router between A and B, and there could be a lot of them, could intercept the mail and read it. Nowadays, a lot of that has collapsed into a few big mailers with many hundreds of thousands or millions of mailboxes. Traffic between those services is SSL encrypted these days. So as long as you dont care about the service operator seeing the mail, there is no problem. This is much safer than things used to be.
cue the paranoid fanatics...
If I use Thunderbird which blocks most of HTML and all of JPEG/GIF content, how am I vulnerable again?(ok i don't use PGP, but still)
When my email client tells me that sending an email in HTML format is not secure. Next you'll be telling me that posting my private key on Facebook could allow hackers access to my encrypted messages.
Anyone who is sending encrypted mail is going to be using plain text, right?
"The eFail attack requires hackers to have a high level of access in the first place that, in itself, is difficult to achieve."
I'm 100% certain that the censors in China have this level of access. China can also force all Internet traffic to route through their country because they have several BGP routers, which is something that they've done on occasion.
This seems to be an instance of security researchers crying wolf when they found a scrawny coyote. Doesn't mean the thing wonâ(TM)t bite you, though.
(BTW, slashdot, why did you convert my dumb apostrophes to weird things?)
Not that I've ever used it, but I thought that PGP stood for "Pretty Good Protection" - aka not uncrackable but enough to keep casual observers (like bored ISP admins) at bay.
If we need a email-esqe asynchronous messaging system, perhaps a thunderbird plugin to do OpsMsg/Drop for e2e?