81–90 of 306 posts
Let me tell you, if my emails were sensitive enough to require PGP, I would also use an email client which does not load images or evaluate HTML by default.
Earlier quoted context omitted.
Because the vulnerability is just about adding HTML tags which will send decrypted content to a remote server controlled by attacker. Example : If you disable remote content, it can't be exploited on thunderbird (which is disabled by default) BUT there may be other attack vector on other software/email client. Anyway, the attacker still need to get a hand on your encrypted email.
What about attack vectors like this one (from the paper)? For example, in Thunderbird and Postbox we can completely redress the UI with CSS and trick the user into submitting the plaintext with an HTML form if he clicks somewhere into the message. That sounds like something that can easily happen, even with remote content disabled. (Edit: Formatting)
https://mobile.twitter.com/ProtonMail/status/996006094605570...
Earlier quoted context omitted.
E-Mail needs better tools and better standards than GPG IMO. For one, GPG tools are difficult to use. Anything beyond a simple 1-click-setup-ready-to-use-including-keyserver-publication will make any wide market adoption difficult. On the other, the GPG standard is a bit ... clunky. Ideally it should be modernized to take advantage of the email format; add generic messages about encryption in alternate mime content b…
Better tools yes, better standards no. There isn't a single production-quality library implementation of the OpenPGP standard; anyone who uses OpenPGP in production ends up with some variant on a crappy 700-line python script wrapping the GPG executable. (There are dozens or hundreds of those out there, every company has their own). I'll never understand what possesses people who aren't up to writing a solid library…
Earlier quoted context omitted.
I can see how it would work against Apple Mail/iOS Mail since they load HTML and external elements by default. I would be interested to see the attack working on a Thunderbird client with Enigmail installed and no other settings changes (like; loading external resources).
According to this table Thunderbird is vulnerable: https://twitter.com/matthew_d_green/status/99599862678571417...
1. Use movemail to receive email instead of IMAP or POP (there's an interesting vector to get your remote resources loaded by using movemail. If you read the code, you can probably guess it).
2. Enable remote loading for all senders by default.
3. Try to send an email with a sender you think will be whitelisted.
4. Convince the user to click on a link.
Matt Green gave a pretty good summary of this: https://twitter.com/matthew_d_green/status/99598925414360678... Some of these thoughts are echoed by Filippo: > No, in 2018 you don’t get to claim the high ground and blame users and implementations if your crypto API returns the plaintext on a decryption error. from https://twitter.com/FiloSottile/status/996010161427935233 So yeah, most clients seem vulnerable but since…
¹: where GPG does the right thing
Earlier quoted context omitted.
What about attack vectors like this one (from the paper)? For example, in Thunderbird and Postbox we can completely redress the UI with CSS and trick the user into submitting the plaintext with an HTML form if he clicks somewhere into the message. That sounds like something that can easily happen, even with remote content disabled. (Edit: Formatting)
Wouldn't disabling HTML email take care of this?
Ruling out the presence of an exfiltration channel is hard. It's better to prevent rendering of messages with invalid authentication code in the first place (and not rendering it and showing a warning).
Earlier quoted context omitted.
Because the vulnerability is just about adding HTML tags which will send decrypted content to a remote server controlled by attacker. Example : If you disable remote content, it can't be exploited on thunderbird (which is disabled by default) BUT there may be other attack vector on other software/email client. Anyway, the attacker still need to get a hand on your encrypted email.
What about attack vectors like this one (from the paper)? For example, in Thunderbird and Postbox we can completely redress the UI with CSS and trick the user into submitting the plaintext with an HTML form if he clicks somewhere into the message. That sounds like something that can easily happen, even with remote content disabled. (Edit: Formatting)
Matt Green gave a pretty good summary of this: https://twitter.com/matthew_d_green/status/99598925414360678... Some of these thoughts are echoed by Filippo: > No, in 2018 you don’t get to claim the high ground and blame users and implementations if your crypto API returns the plaintext on a decryption error. from https://twitter.com/FiloSottile/status/996010161427935233 So yeah, most clients seem vulnerable but since…
Is this vulnerability seriously due to improperly escaped (quoted) inputs? Correct me if I am wrong, but FFS.
This is the big fail of MIME, that literally concatenating different sections together into one document is the intended way of implementing much of multipart handling.