rixx 🏴 is a user on chaos.social. You can follow them or interact with them if you have an account anywhere in the fediverse. If you don't, you can sign up here.

So my major lesson learned from the /#pgp thing today is not to trust warnings by EFF in the future – while parts of their warning were factually correct, they were baiting for attention in annoying and unhelpful ways.

This culture of publishing exploits and issues in a publicicty focused way is disturbing. I had hoped the EFF was beyond this needless hyping of vulns. Apparently not.

rixx 🏴 @rixx

A part of their information strategy is that they recommended to stop using /#PGP over stopping the mail client from rendering HTML (or loading external sources in HTML). That's disturbing.
(Also that they let themselves be roped into a publicity campaign.)

Β· Web Β· 7 Β· 6

@rixx How is this disturbing? So many mails rely on HTML nowadays. It isn't realistic for most people to have HTML gibberish all. over their screens. Most GPG users have probably not actively used GPG in months.

@natanji At least Thunderbird (probably the other two, too) supports blocking external resources from HTML mails, which is a good security default anyways. By not offering this as an alternative, EFF says clearly that they value encryption less highly than displaying HTML. I'd have expected at least a sentence on discussing this, and offering similar guides for disabling third party/external resources from HTML mails.

@rixx @natanji If I recall correctly, Thunderbird even blocks loading external resources by default, which is a modern requirement anyways (against tracking), but also stops the attack.
The efail paper claims Thunderbird to be vulnerable, but gives no further details.
IMHO that is an extraordinary claim that would necessitate extraordinary proof.
(I know that Mario/Cure53 was looking into exactly this area from the privacy perspective some time ago and didn't find anything.)

@natanji I get where you're coming from, and I wouldn't want to recommend *only* no-HTML as a solution as it wouldn't be practical for many, but mentioning alternatives would have been more honest. Especially since disabling external resources in HTML mostly leaves HTML mails very readable, and only without a logo and large ad image missing somewhere.

@rixx also they recommend Signal aka electron hell...

@rixx admittedly deactivating encryption for one day until the embargo was over is the easiest "fix" that works everywhere immediately without breaking the embargo, as encryption in most clients is plugged in. Better not being able to read encrypted mail for one day than having (all) your mails exfiltrated. Especially as you might not even be able to easily deactivate HTML-rendering in some clients? Don't know that, but wouldn't surprise me if there are such cases.

@cherti I don't agree. They only posted guides for three clients, and I'm very sure that in all three clients you can disable *external* resource loading in HTML emails. The embargo was a bloody silly thing designed to grab attention, otherwise it wouldn't have been "oh, yea, 24 hours". Warning users to drop external resources would have been *safer* than just telling them how to disable GPG, and it would have spared us the "EMAILS ARE BROKEN" headlines.

@rixx The embargo wasn't their idea, they had to run with it (or opt to not having seen the documents at all/never again getting some to prepare material).
Yes, they provided resources for three clients, but there are much more clients out there (AirMail, Windows Live Mail, you name it) and they specifically did not speak about only those three.
Disabling decryption is quite as safe as disabling HTML-postloading and likely to be much easier to quickly and error free do for beginners... 1/2

@rixx until they had time to read about the problem and configure their clients properly.
And nothing would have spared us the "EMAILS ARE BROKEN" headlines, really one way or the other (actually that's quite what is happening, emails as used in the overwhelming majority of cases are severely broken right now and especially S/MIME seems to be difficult to fix).
The other thing is that with "deactivate encryption" users do not have to check if they use PGP or S/MIME, it just works for the moment.

@cherti Right, sure. If you think that disabling encryption is just as good as disabling third party content, I think we have no consensus left as basis for discussion.

@rixx Factually both leads to "no encrypted email content can be exfiltrated", doesn't it? I do not say that this is the optimal solution, but as a quick-and-dirty workaround it at least mitigates the problem. Possibly the HTML-thing was also part of the embargo? We don't know that.

And to disable HTML in Windows Live Mail you seem to dig into the system internals of windows, that's better done with proper guiding material.

@cherti @rixx No matter how flawed a crypto implementation is, how can sending the same content unencryptedly EVER by safer than still using crypto, except if the crypto implementation has a remote code execution vector (which it didn't)?

@rami @rixx
Problem is that the EFAIL-Bug allows to exfiltrate encrypted mails from the *past*, to break open your entire history of encrypted communication.

@cherti @rixx In the edge case of an attacker having access to the ciphertext already and then sending you all of your own email back to you which you all manually open. I don't think that's that plausible.

@cherti @rixx While it's correct that they only said you should disable decryption (not encryption), probably all users disabled PGP entirely – in my eyes causing more harm than good.

@rami @rixx As far as I understand cryptographers always assumed state level attackers, in my experience plausibility is hardly an argument in this realm, the pure existence of a problem is a killer here. The headline "all past e-mail communication was broken due to this bug" would hardly be a better headline, even if only one single case...

@cherti @rami No, cryptographers don't. As with everything, your threat model is the important part. *Some* people need to choose a state attacker as their primary threat model.

@cherti @rami Yeah, but I think nobody read "don't use GPG" as "don't even look at old emails". "Disable third party resource loading in your mail client" would have been a valid warning aswell, and would not have resulted in the same panic, or in things that would have been encrypted to be sent openly instead. I was fairly miffed when a customer sent me an unencrypted mail instead of an encrypted one as usual. Of course with a full quote.

@rixx @rami
Yeah, an unencrypted e-mail instead is also not quite the way it should have gone. Although in my experience "Disable third party resource loading in your mail client" would be hardly as easy for people not familiar with tech.

The only thing I'm saying is that in my experience the EFF-people are the good (and competent) guys, and they do have experience with PR. They will have considered all alternatives and they will not have made their choice lightheartedly, I'm certain.

@cherti @rami "Not easy for people not familiar with tech" is not an excuse if you already go through the trouble to provide guides for individual mail clients.

I trusted their warning and spread it, assuming that there was an RCE level threat out there. I will not do the same in the future, and my trust in their recommendations has been damaged. Their specific rec of Signal as the alternative did not help either.

@rixx @rami But they only had it for 3 and is it clear that this is the only way to exfiltrate content? Maybe something like automated key lookup for signatures or so can also be misused for that? Is it already ruled out that there is no other exfiltration channel besides HTML? I currently wouldn't say I know for sure, but if you do, I'd certainly be interested. :)