@webshinra no, all PGP users. Thunderbird/Enigmail and other clients are vulnerable in similar ways, and even if yours isn't the people you email might be using vulnerable clients

@micahflee
Sorry, only a specific part of distant content integration inside pgp cyphered mail (when a error warning was not handeled correctly).

«PGP users» are not affected Enigmail have been patched month ago.

https://pl.quic.fr/notice/57672

People not displaying html mail where never affected.

You call better have specificaly adressed to thoses using the apple thing.

@webshinra The default behavior of Thunderbird is to display HTML emails, which means probably most Thunderbird users display HTML emails

@micahflee he default behavior of Thunderbird is to not decipher gpg cyphered message.

@webshinra yeah but once you install Enigmail, you still display HTML emails unless you explicitly disable it. So most Thunderbird/Enigmail users are vulnerable if they choose to display remote content.

And the remote content button is misleading as-is, until fixed. It should say, "Load remote content and potentially leak your plaintext" instead of just "Load remote content"

@micahflee probably not, as enigmail is patched against it from the 2.0.4

@webshinra excellent, was 2.0.4 released today? I'll try to make a Thunderbird exploit too to verify it fixes it

@micahflee Your free time is your free time.

The more I think about #EFail and the #EFF's take, the more sympathy I have with their approach.

I wish they'd given more nuanced advice and avoided some of drama, but here are some factors to consider:

1) People don't read. Security advice needs to be simple.

2) Lazy User A can put careful User B at risk.

3) Social engineering works.

4) The PGP/e-mail community's knee-jerk was "we're not vulnerable."

But many were & are vulnerable if you count SocEng and/or old versions. #Mailpile too.

@HerraBRE I think also EFF believes attackers will quickly find new backchannels, most users won't hear the news and keep using remote resources and HTML, etc.

PGP is a slow-moving, often user-blaming open source ecosystem instead of like an app with immediate security updates. But I think if the big clients can fix this- particularly by validating PGP/MIME way better, and displaying MIME types in like separate iframes, then it's fixable. That might take a long time though

@micahflee @HerraBRE the way Privacy International reached out was a good way to communicate imo, very accessible and all the important points were there, what do you think? https://privacyinternational.org/blog/2033/efail-and-pgp-what-should-i-do

@charlyblack @HerraBRE I sympathize with their position -- I can't just stop using PGP like EFF recommends either. But their blog post is inaccurate. It only addresses the malleability attack, not direct exfiltration.

This is wrong: 'This attack is incredibly "noisy", relies on a non-standard setup of your email client, and requires some interaction from the user to even work.'

Apple Mail is vuln with default settings without user interaction. Thunderbird too, but with user clicking a button

@micahflee @HerraBRE I see, right, I am totally unfamiliar with the Apple ecosystem and never used PGP via Thunderbird so I was not looking at the bigger picture... still unsure if PI's take is worst advice to the average user than 'stop using PGP' though

@charlyblack @HerraBRE I'm not sure either.

But I do think it's true that encrypted emails are a lot more likely to get compromised, because of another recipient's email client if not yours, now than before we knew about efail.

But this isn't true for Signal protocol apps that use modern crypto.

@micahflee @charlyblack @HerraBRE But for Signal the security situation is even worse (as with the Electron thing). Another issue with Signal is that it is centralized. Something GnuPG is not. GnuPG can be found pretty much everywhere and decentralized.

The implementation issues that was Efail will be mostly mitigated... so...

@shellkr @micahflee @HerraBRE yeah, pros & cons on both sides, some degree of compromise is unavoidable whatever path one favors... neither are gonna be mass-adopted anytime soon anyway :/

@charlyblack @micahflee @HerraBRE Yes, but it becomes a bit funny that EFF recommends an app that are in almost every way worse than the Efail. If you chat with a friend on desktop... you will be compromised with Signal. That is not true with GnuPG. Also.. GnuPG has a lot more utility than just messaging.

@shellkr @charlyblack @HerraBRE that isn't true, Signal was patched before the vulnerability was made public. And obviously Thunderbird and other email clients have RCEs all the time

@micahflee @charlyblack @HerraBRE Well, you have this https://github.com/signalapp/Signal-Desktop/issues/1635

And Electron have had at least 2 vulns this year what I know..

@shellkr @charlyblack @HerraBRE that's not a real security bug report

@shellkr @charlyblack @HerraBRE (but I agree electron was a bad choice for the desktop app -- I would have chosen something with a smaller attack surface like python/qt5. But just the fact of using electron doesn't mean it's vulnerable.)

@micahflee @charlyblack @HerraBRE Yes, true.

@micahflee @charlyblack @HerraBRE Yes, but do show part of the problem with using Electron.

@shellkr @micahflee @HerraBRE I understand your arguments, the great advantage of Signal is usability, and it's already almost impossible to get uninterested people to use that, forget about GnuPG.. anyway in the big picture, from the point of view of the average potential user it's a loser-game either way, and I don't know how to turn this 'divide' in a constructive thing

@charlyblack @shellkr @HerraBRE Messaging apps use modern crypto, are well designed, don't have 20-30 years of technical debt and cruft, don't have a bazillion insecure options, aren't configured badly by default.

But messaging apps aren't actually a substitute for email. I want a real substitute for email, that's much simpler, federated, with e2e encryption built-in, that isn't the mess that is encrypted email right now

@micahflee @charlyblack @HerraBRE

You don't want crypto that is not tested well enough. You neither want crypto that self made (and thus not very well tested).

I agree about email though.. we need some way that is as decentralized as email and that have e2e on both content and meta.

@shellkr @micahflee @HerraBRE on emails, what do you think of Tutanota's approach?

@charlyblack @micahflee @HerraBRE Tutanota is probably one of the best.. but they use a hybrid encryption solution. This might be bad. Using the same thing as everyone else makes it more likely to find potential vulnerabilities. If you go off and do your own thing that might not be the case.

The hybrid is based on AES-128 so is probably alright..

@micahflee
I've wanted that for decades.
@charlyblack @shellkr @HerraBRE

Daniel (dkg) at the ACLU is one of the smarter people in the PGP world. He says some reasonable things about#EFail (and #EFFail) here: https://www.aclu.org/blog/privacy-technology/internet-privacy/encrypted-email-and-security-nihilism

Reading this, I get the feeling he's missing point 2) from my previous toot - how #EFail is particularly scary because Lazy User A can put Careful User B at risk.

In InfoSec, we're so used to thinking in an individualistic way about how we protect ourselves, I think we often fail to consider how our choices affect others.

@HerraBRE Doesn't his “Ecosystem concerns” section cover your point 2 or are you thinking of something else?

@edavies Yes, I think he missed an important point.

His frame there is "I need to send confidential info, therefore..."

I am pointing out the framing of "I have received confidential information from others IN THE PAST, therefore..."

Different questions lead to different outcomes.

The EFF recommendation that everyone who can, temporarily disable decryption until things are more clear, is actually quite reasonable from the latter POV.

Just my opinion, of course. 😃

@nino here's a video of the efail researchers exploiting Thunderbird/Enigmail using direct exfiltration with remote content, just like in Apple Mail: https://youtu.be/O0IVgY2rFC0

Enigmail protects against the malleablility attack (I think) but not direct exfiltration

@ajeremias really it's a problem with how OpenPGP and S/MIME are integrated into this list of email clients, and possibly others. But luckily as of yesterday, Thunderbird/Enigmail has a patch that mitigates (but doesn't completely fix) the problem for OpenPGP. S/MIME is still hosed though.

@micahflee Did you do the POC for thunderbird+enigmail ? and this one for apple mail, is so fishy.. i'd never click on that button when receiving a pgp mail...

@ajeremias Yes. I exploited it with Enigmail 2.0, but the mitigations in 2.0.4 (released yesterday) made my exploit stop working. However this guy says he was able to bypass them https://twitter.com/hanno/status/997138771194859521

Also if you watch the video again, the email with remote content wasn't encrypted, it was plaintext. I could have done a better job at social engineering you to click the load remote content button (include an image you actually wanna see, for example)

@micahflee
html..!

@micahflee but yeah i get ur point.. but are this new foundings changing the fault on the stack from not being on the email client, but on gnupg? besides it being a warning instead of just not rendering...

@ajeremias I think the bigger picture is, if you're a newbie and you set up PGP for the first time and send encrypted emails to another newbie, there's a good chance at least one of you is vulnerable to this, therefore the security of PGP isn't as guaranteed as you might have thought. But if you use a modern encrypted messaging app, that isn't the case

@micahflee yeah PGP should not render the content to the email, when MDC is not correct... but the HTML part is tottaly on the side of how mail clients render... because if u can decrypt securly with gnupg on the terminal... its clear..