@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 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.
@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.
@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 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.
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.
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. :)
chaos.social - because anarchy is much more fun with friends.
chaos.social is a small Mastodon instance for and by the Chaos community surrounding the Chaos Computer Club. We provide a small community space - Be excellent to each other, and have a look at what that means around here.
Follow @ordnung for low-traffic instance-related updates.
The primary instance languages are German and English.