Today, Thunderbird will attempt to strip conditional CSS prior to rendering received/stored emails.

The reason is, with conditional CSS, it's possible to trick users. Sender and recipient might see different renderings on screen. The different rendering could completely alter the meaning of the message. A person could be tricked into signing content that they cannot see. (bug 1530106)

We've repeatedly gotten feedback that users are unhappy with this situation.

An in addition, the newest report is in bug 1780361, which also complains that our implementation is incomplete anyway. (As I understand it, but 1780361 claims that with the attributes that we currently don't strip, it would still be possible to trick the user.)

Furthermore, bug 1780361 asks that we consider to remove that code, in order to simplify maintenance of the related code module.

So, it seems, we need to do something about this situation.

However, I'd be very uncomfortable with simply dropping the attempt protection at all.

In my opinion, we need to work on a new implementation to solve the concerns.

In other words, we need a solution that:

• allows people to see full CSS rendering, including conditional CSS
• avoid the risk that a recipient considers the message shown by Thunderbird to match what the sender had intended to sign

If the request is to render conditional CSS by default, then I'd like to require that by default, we also don't show digital signature for emails that involve rendering of CSS.

How could this work?

If all inline rendered message parts are plain text, then it seems safe to continue doing what we do today: Immediately show the computed signature status of the message.

For all other messages, which have the risk that the rendering might not match what the sender saw (and this applies to any HTML messages I guess), do NOT show signature status by default.

Instead, we could display a notice that more information is available. For example, in the place where we show the OpenPGP or S/MIME labels today, we could show something like: "View Digital Signature Status"

If the user clicks that, we could show a popup to educate the user, in addition to the signature status.

It could potentially say: "This message includes a valid digital signature from the sender. The valid signature confirms that the message was not altered by anyone. However, this message isn't simple text, it uses text formatting to visually enhance the message. It isn't guaranteed that the information shown by Thunderbird matches what the sender wanted you to see, some text or images might be missing, or shown in addition. If you need unambiguous communication with the sender, you should ask them to send you digitally signed email with simple text, only."

The idea is to make it clear that when using HTML email, the signature status cannot guarantee correctness of text seen by the user, it can only guarantee the technical integrity of the raw data the sender has sent.

The previous comment was about displaying of received/stored email.

If we start to allow conditional CSS to be composed/forwarded/quoted, then in my opinion, we also should educate the user when attempting to digitally sign an email the user composes (or replies to, or forwards).

When composing an email that contains risky HTML (and some say that all HTML is risky, you could even use <small><small><small><small><small><small>hidden text<small/><small/><small/><small/><small/><small/> to make something invisible), I suggest to inform the user, possibly with a notification.

The notification text could say (with OpenPGP or S/MIME dynamically set based on the selected technology):

"Warning: When sending an OpenPGP message that includes a digital signature, you should prefer the use of simple text. [Convert to simple text] [Learn More] [Stop reminding me today]"

If the user clicks "convert", then we'd convert all message contents (including forwarded/quoted parts) to plain text, and the warnings is hidden. Also, the mode of composing should change to plain text - to ensure that all further text pasted into this message is immediately converted to plain text, too.

If the user clicks "learn more", we show an explanation text similar to the one in comment 1.

If the user clicks "stop reminding me today", we could stop showing this notification. However, I'd prefer if this button click isn't immediately persistent forever, so I'd start with a time-scoped suppression.

A few meta-comments:

• It makes no sense to sanitize during sending. The attack will come from outside, as an incoming email. The attacker will not use Thunderbird. We need to sanitize incoming, not outgoing.
• We should sanitize agressively during reply while including a quote from a replied-to email. Part of efail https://efail.de would have been stopped by sanitizing quotes. All quotes should run through the sanitizer, unconditionally. (Yes, that will strip external images, but that's good and a security feature. I don't want pings to third party servers, which other people inserted, in emails that I write and send.)
• For display of incoming mail, you need to come up with a good balance between security and user expectations of "pretty". Whether you or me like it or not, many people today appreciate colors and images and pretty emails. Reading encrypted emails shouldn't be a throw-back to 1980, otherwise that hinders adoption. I don't have a concrete implementation suggestion for this one, sorry. Emilio seems to have a suggestion in bug 1780361.

I think we should flat-out refuse to include CSS in signed replies, if not all replies. Users expect that when they reply to a message, the recipient will see exactly what they saw. That this fails to hold is a significant problem.

The only solution I can think of has two parts:

1. Strip out problematic Unicode sequences.
2. Render the replied message to a bitmap or another unambiguous representation. SVG is the most obvious one.

Strip out problematic Unicode sequences.

Good idea. The sanitizer wouldn't be able to do that. Can you file a new bug about that? Because it is a task on its own.

Render the replied message to a bitmap or .... SVG

hahaha. That is technically catastrophic. And destroys accessibility, readability, font sizes etc. for the recipients. That's not a good technical solution.

It's worth reading bug 1530106 comment 17 from the original security researcher and reporter of that bug: "I personally would give up here, and accept the fact an attacker herself can sign a message with two meanings.".

Even with plaintext there are "attack" possibilities.

What we could do is to inline all styles on reply/fwd. That would make these kind of attacks quite limited. Maybe completely fixed, since I don't then the styles don't leak into the normal reply. It would also fix other problems of reply content styles affecting the message text the user types in. Bug 1731198/bug 1720311.

(In reply to Ben Bucksch (:BenB) from comment #5)

Strip out problematic Unicode sequences.

Good idea. The sanitizer wouldn't be able to do that. Can you file a new bug about that? Because it is a task on its own.

Done: bug 1780710.

Render the replied message to a bitmap or .... SVG

hahaha. That is technically catastrophic. And destroys accessibility, readability, font sizes etc. for the recipients. That's not a good technical solution.

Not surprised in the slightest. Qubes OS’s “Convert to trusted PDF” does exactly this with PDF files, but this not being viable for replied-to emails is something I am quite okay with.

(In reply to Magnus Melin [:mkmelin] from comment #6)

It's worth reading bug 1530106 comment 17 from the original security researcher and reporter of that bug: "I personally would give up here, and accept the fact an attacker herself can sign a message with two meanings.".

Even with plaintext there are "attack" possibilities.

Magnus, I think your partial quote gives the wrong impression that the researcher may be willing to give up. It's important to note what other statement the researcher also made:

"But we should at least be able to protect from being misused as a signing oracle (i.e., the attacker makes the victim sign a message that is displayed differently to a third party)"

This is the core of the problem we want to fix.

If Eve tricks Alice into forwarding a crafted message to Bob, which causes Eve's text to be shown to Bob, and causes Alice's text to be manipulated or hidden, then the attacker succeeded.

What we could do is to inline all styles on reply/fwd. That would make these kind of attacks quite limited. Maybe completely fixed, since I don't then the styles don't leak into the normal reply. It would also fix other problems of reply content styles affecting the message text the user types in. Bug 1731198/bug 1720311.

How would you handle conditional CSS? Is it possible that all CSS is made inline?

Is it realistic that we could get an implementation that transforms all CSS?

Wouldn't it still require that we'd have to strip all CSS that is problematic, which cannot be scoped?

I'm worried that after comment 6 and comment 8 this bug may get side tracked.

Please let's avoid mixing too many things at the same time.
We should handle this problem space in steps.

As the first step, we must find an agreement on how to handle received email that contains digitally signed contents with dynamic rendering.

Option 1:
Keep today's filtering attempts, strip away the most obvious dynamic rules.
If we can, improve the situation further, by stripping away more, but also try to keep styling visually appealing.
Show the digital signature immediately, as we do today.

Option 2:
Only display the plain text parts of a digitally signed message.
Show the digital signature immediately, as we do today.

Option 3:
Don't filter HTML/CSS, allow full dynamic rendering.
Don't show the digital signature by default, as explained in comment 0 and comment 1.
Only show it, after the user has been made aware of the limitations of the digital signature.

Once we have reached an agreement on the first step, we can continue to discuss how we want to handle forwarded/pasted dynamic content.

(In reply to Kai Engert (:KaiE:) from comment #8)

"But we should at least be able to protect from being misused as a signing oracle (i.e., the attacker makes the victim sign a message that is displayed differently to a third party)"

This is the core of the problem we want to fix.

Correct. If we inline every style that can be inlined, there would never be an impact on the text that the user themselves entered. The situation at the moment is that styles in the reply can make an impact on that text.

How would you handle conditional CSS? Is it possible that all CSS is made inline?

I guess it depends on what we want to define as conditional css. Media queries etc can't be made inline. Using calc() for widths and such can.
It would seem the problematic cases would be covered.

Is it realistic that we could get an implementation that transforms all CSS?

Sure, there are many implementations out there which we can at least take inspiration from.

Wouldn't it still require that we'd have to strip all CSS that is problematic, which cannot be scoped?

Yes, but I wouldn't consider that much of an issue for reply/forwarded content parts. The effects of styles from those bleeding into the the "real" mail are much worse.

(In reply to Kai Engert (:KaiE:) from comment #9)
As long as we can't fix option 1 100%, it's not an option. And we can't. As noted with the original bug there are also problems even with plain text. There are problems with pdf attachments. Remote images showing text only, dynamically adjusting per IP would be cause similar bad effects. There's only so much we can do.

I don't think option 2 is an option either. There shouldn't be any difference in appearance just because you sign.

I think it option 3 would make much sense. We can simply add that information next to the text inside the popup, where signing status is/would be shown. It would also fix bug 1731984 which is a huge bug.

If we don't show signatures anymore, what's the point of having them in the first place? Using encryption shouldn't show one warning after the other.

I'd suggest to strip the problematic CSS. This should take care of most real world cases. We can then deal with the remaining cases in other (possibly more drastic) ways. The goal here is to preserve security, while minimizing actual user impact for the most common cases.

Signatures are essential when using encryption. Encrypted but not signed is a red flag, which we should handle as such.

For plain text signed, there are not that many use cases. For the few cases one wants to check the signature I think it's acceptable to have to do an extra click to find out the status.

(In reply to Magnus Melin [:mkmelin] from comment #11)

(In reply to Kai Engert (:KaiE:) from comment #9)
As long as we can't fix option 1 100%, it's not an option. And we can't. As noted with the original bug there are also problems even with plain text.

If there are problems with plain text, then those need to be fixed. Is the problem that HTML/CSS rendering is not bit-for-bit reproducible? What about basic HTML with no CSS? Because most users do not want plain-text email; they will consider it ugly.

There are problems with pdf attachments.

Any specifically you can think of?

Remote images showing text only, dynamically adjusting per IP would be cause similar bad effects. There's only so much we can do.

Thunderbird should refuse to sign a mail that has remote images of any sort, and should (if it does not already) ignore such images by default

I don't think option 2 is an option either. There shouldn't be any difference in appearance just because you sign.

I suggest asking a user experience expert what options users are going to use. A likely consequence might well be that users just stop signing their mail.

(In reply to Ben Bucksch (:BenB) from comment #12)

If we don't show signatures anymore, what's the point of having them in the first place? Using encryption shouldn't show one warning after the other.

I'd suggest to strip the problematic CSS. This should take care of most real world cases. We can then deal with the remaining cases in other (possibly more drastic) ways. The goal here is to preserve security, while minimizing actual user impact for the most common cases.

I agree.