Page MenuHome GnuPG
Create Task
Maniphest T3986

GpgOL: Mitigate manipulations of encrypted S/MIME mails
Closed, ResolvedPublic
Actions

Description

It is possible that an attacker could insert data before and after the plaintext of an unsigned encrypted S/MIME mail. In combination with HTML and Image downloading / active content in HTML an attacker could access the plaintext of a mail.

To mitigate:

  • If an S/MIME Mail is unsigned: Prefer the Text part over the HTML part regardless of the settings if the mail is multipart/alternative.
  • If an S/MIME Mail is unsigned and has attachments or is HTML only: Show a big yes/no warning that an attacker might gain the plaintext because the message is unsigned.

The warning should help to educate users that they need to sign and encrypt S/MIME mails and that encrypting is not enough to ensure confidentiality of S/MIME.

To clarify. By unsigned we mean that it does not follow the mime structure:

  • Encrypted
    • multipart/signed
      • content.

Details

Version
master

Revisions and Commits

rO GpgOL
rOc9a173782e33 Clean reply / forwards of unsigned S/MIME Mails
rOa1a0f0aa53b0 Extend mail class for better reply/forward handling
rO49cc27fd092d Improve unsigned S/MIME HTML handling
rOb2ed39c55af2 Block HTML for unsigned S/MIME messages

Related Objects
Search...

Event Timeline

• aheinecke created this task.May 15 2018, 2:08 PM
• werner added a subscriber: • werner.May 15 2018, 3:59 PM

That was actually our old stance on OpenPGP encryption: For integrity we rely on the signing of messages. Remember that signing is an integral part of OpenPGP messages and does not need MIME. Some people explained that they have valid reasons not to sign and so we added the MDC.

• aheinecke added a comment.May 15 2018, 4:29 PM

Yes. For S/MIME we don't have the comfort to change the standards. I also would like to have a quick solution. After much deliberation with Bernhard we think that it is a good compromise from usability vs. security that we further reduce the usability for S/MIME in that we only allow (any) signed content to be displayed as a file or HTML. This is not extending the standard, not changing GPGSM but a design decision in GpgOL.
We don't have full control over our Mail client so we can't prevent the load of external references like KMail does. This suggestion is a compromise and a pragmatic solution.

We might somehow make it easier for S/MIME users if we do some GnuPG extension that contains the hash of a message but I don't think that it is neccessary and this issue is not about that.

• aheinecke added a comment.May 22 2018, 2:02 PM

I've tried to prevent the download of external references selectively for S/MIME Mails. There is PR_BLOCK_STATUS but I was unable to stop the question for the user if she want's to download the external references anyway. :-/

We now have the following logic.

In case of an S/MIME Mail that was decrypted and does not have one of the following signature states we go into "Block HTML" mode.

case GpgME::Signature::Valid:
case GpgME::Signature::Green:
case GpgME::Signature::KeyRevoked:
case GpgME::Signature::KeyExpired:
case GpgME::Signature::SigExpired:
case GpgME::Signature::CrlMissing:
case GpgME::Signature::CrlTooOld:
case GpgME::Signature::TofuConflict:

In that mode we silently prefer a text/plain part of a multipart/alternative mail.

If there is no text/plain part but only a text/html part. We show a warning:

And then insert the HTML part as plain text.

This is super ugly, but If I tried to convert it to plain text using Outlook (by setting it as HTML first and then taking the plain body to set this again as the HTML Body) I still got the question to load external references. And it might be dangerous to put any manipulated URL into Outlook in case it does automatic download or so.

I wonder if I should enable the same logic for OpenPGP without MDC, based on decryption_result.symkey_algo.
And if I should show a message box warning if we have attachments on a plain/text or multipart/alterative S/MIME enc only mail.

• werner added a comment.May 31 2018, 1:26 PM

There won't be anything without MDC in 2.2.8 anymore.

• aheinecke added a commit: rOb2ed39c55af2: Block HTML for unsigned S/MIME messages.Jun 1 2018, 10:42 AM
• aheinecke added a comment.Jun 11 2018, 6:15 PM

Here is what we have now. We decided explictly not to offer a "yes I want to do something less secure" button as we think that using Unsigned S/MIME Mails is avoidable. Also we want to be more secure by default then Outlook. From a User Experience standpoint a "Yes more convenient but less secure" button basically educates users to always select that button.

The first time a multipart/alternative unsigned S/MIME mail is shown when we would normally show the HTML (because of Outlooks settings) we show a message box to inform the user that we prefer text/plain parts. Let's hope that this reduces bugreports about this ;-) We then only show text/plain parts.

If there is no multipart/alternative we do the handling from my last comment. (With a better message).

Additionally to thwart reply / forward injection we catch replys and forwards of unsigned s/mime mails:

And remove all contents from the reply / foward templates.

I'm not very happy with the implementation. As we receive the reply / forward events before the reply / forward is populated with contents we remove the decrypted contents after an "arbitrary" delay of one second in the hope that one second is enough even for slow Outlooks to build up the contents of the reply / forward. I think if it does not work reliably that we need to fix it in a future release but for now the intention to the user should be clear and warning flags should be raised.

Additionally our forward / reply of crypto mail detection is very heuristic :-/ Its a Hack, Hack, Sausage, Beans and Hack,...

I currently also hope that unsigned S/MIME Mails are a corner case.

There is a large regression risk because I had to change how the forward is detected to have it more reliable. This might have unwanted side effects due to the way we detect this interally. I'll have to test it more. Especially with normal OpenPGP Forwards.

• aheinecke added a commit: rO49cc27fd092d: Improve unsigned S/MIME HTML handling.Jun 11 2018, 6:54 PM
• aheinecke added a commit: rOa1a0f0aa53b0: Extend mail class for better reply/forward handling.
• aheinecke added a commit: rOc9a173782e33: Clean reply / forwards of unsigned S/MIME Mails.
• werner added a comment.Jun 11 2018, 6:56 PM

Thanks for the writeup. Maybe this could be the base for a gnupg.org/blog article.

• aheinecke closed this task as Resolved.Jun 18 2018, 4:08 PM
• aheinecke added a parent task: T3925: Gpg4win 3.1.2.

The changes were released with Gpg4win-3.1.2.