Open Bug 1866822 Opened 2 years ago Updated 14 days ago

Creating a decrypted copy of a PGP signed+encrypted message strips the signature from the copy

Categories

(MailNews Core :: Security: OpenPGP, defect, P5)

Product:
MailNews Core
Component:
Security: OpenPGP
Version:
Thunderbird 115
Type:
defect

Tracking

(Not tracked)

People

(Reporter: mirai, Unassigned)

References

Details

(Whiteboard: [mailsec-broken-fixwanted])

Attachments

(1 file)

Tracking section of bugzilla
90.93 KB, image/png
Details

User Agent: Mozilla/5.0 (X11; Linux x86_64; rv:120.0) Gecko/20100101 Firefox/120.0

Steps to reproduce:

Right-click on a PGP signed+encrypted message, select 'Create Decrypted Copy in' and choose a destination folder.

Actual results:

A decrypted copy was placed in the destination folder but it is no longer PGP-signed.

Expected results:

The signature would have been preserved in the decrypted copy.

Status: UNCONFIRMED → NEW
Component: Untriaged → Security: OpenPGP
Ever confirmed: true
Product: Thunderbird → MailNews Core

We're also suffering from this issue. We'd like to see the signature even in decrypted messages (if it was present in the original messages). Plus, there are some situations where we may need a proof that a message has not been altered after having decrypted it permanently. Please consider the following situation:

You need to show a PGP-encrypted message to a third party, and you need to proof that you haven't altered it. You cannot give the encrypted message to that third party, because they cannot decrypt it without your private key, but surely you won't allow them to access your private key. The only way to solve that problem is to permanently decrypt the message and give the third party the decrypted copy. But now, if the signature is missing in the decrypted copy, you can't proof that you haven't altered the message.

And I am quite sure that I have already explained in detail why the signature is missing and what must be done to solve the problem:

https://bugzilla.mozilla.org/show_bug.cgi?id=1843860#c2

In other words, the reason that the signatures are missing in decrypted copies of encrypted messages is the same reason that a decrypted copy of an encrypted message cannot be forwarded or edited as new. If anybody is interested, please study the comment linked above thoroughly.

Sadly enough, the bug report linked above is still in status "UNCONFIRMED" even after 5 months, and nobody cares about it, although it is even related to a variety of further bugs, as comment #1 explains.

See Also: → 1843860

(In reply to Binarus from comment #2)

And I am quite sure that I have already explained in detail why the signature is missing and what must be done to solve the problem:

https://bugzilla.mozilla.org/show_bug.cgi?id=1843860#c2

In other words, the reason that the signatures are missing in decrypted copies of encrypted messages is the same reason that a decrypted copy of an encrypted message cannot be forwarded or edited as new. If anybody is interested, please study the comment linked above thoroughly.

I apologize. This statement was true 5 months ago, but is wrong now. Something has changed in TB since I lastly investigated the problem. The reason that I didn't notice that change is that there was no activity in the other bug report linked above until yesterday, so I assumed that the situation was the same as 5 months before.

For details, please see https://bugzilla.mozilla.org/show_bug.cgi?id=1843860#c9

In summary:

With the version from 5 months ago, after having decrypted a message, the signature MIME part did still exist in the decrypted version, but in most cases the signature was not displayed when viewing the decrypted message, because TB had problems with the MIME structure of the decrypted message.

With the current version, when decrypting a message, the signature MIME part is completely removed. That is, there is no trace of the signature in the decrypted message any more. At least, that's what a few tests have shown today.

I'm guessing it has to do with Thunderbird's changed creation of signed+encrypted messages.

In the past, TB always created two separate MIME layers.
When removing the outer MIME layer, the inner signature layer could remain.

However, there were complains that this type of layering is attackable - see bug 1688863.

So we changed Thunderbird to use the "combined" sign+encrypt approach.
With that, there is only one MIME layer, and that's removed when decrypting.

Depends on: 1688863

You could try to change pref mail.openpgp.separate_mime_layers back to true
and then check if messages sent with that setting, when decrypted, keep their signature layer.

Flags: needinfo?(info)

Binarus appears to be gone

Flags: needinfo?(info)

Thanks for not having forgotten this issue. No, I'm not gone :-)

But I am unsure about how to proceed. I believe that the reasons for the issue have been analyzed sufficiently. As Kai has pointed out, there seems to be a remedy (in form of the mail.openpgp.separate_mime_layers setting). But Kai also has pointed out that encrypted messages that are created while this setting is true are vulnerable to attacks.

I didn't have the time yet to understand the nature of the vulnerability or how severe it is in practice. However, the mere suspicion that the "old" MIME structure could put encrypted contents at risk is enough for us to avoid it. This means that we don't want to set the aforementioned setting to true.

Therefore, we live with the situation as it currently is.

A few remarks, though:

  1. Keeping the signature in permanently decrypted messages would be especially useful in professional environments.

For example, suppose the financial authorities are conducting an audit at your site, and the officials doubt that a certain invoice (that you have received in the form of an encrypted email message) is authentic. It would be nice if you then could simply prove the authenticity by the signature of the decrypted message.

This is currently not possible, unless you prove the authenticity by the original, encrypted message while an official sits besides you, or unless you give the company's private PGP keys to the officials so that they can themselves open the received encrypted messages to check their authenticity. Of course, the latter is not really an option.

  1. When permanently decrypting a message, why not re-add the original signature in decrypted form as a MIME part that contains the signature after the decryption has happened?

That is, the signature must be somewhere in the encrypted message, regardless of the actual structure of that message. But then the signature can be extracted in decrypted form. After the message decryption has happened, the extracted decrypted signature can be added to the decrypted message as a new MIME part.

That way, the decryption process could nearly stay as it currently is. "Only" the signature would have to be attached at the end, probably in form of an additional MIME part.

But I admit that 1) I have no clue how much effort that would take and that 2) there might be a misunderstanding at my side about how signatures are generated. AFAIK, when sending a PGP-encrypted message, the signature is built using the raw (yet unencrypted) message and is then attached to or embedded into that unencrypted message. After that, the message is actually encrypted (including the signature). The above proposition makes sense only if this is correct.

Best regards,

Binarus

I had a look at this and there are various cases to distinguish.

As Kai said in comment 6, messages using a combined MIME layer from TB 115 onwards (bug 1688863) lose this layer upon permanent decryption, so the signature is gone.

Messages created before TB 115 show this after permanent decryption:

Content-Type: multipart/mixed; boundary="------------OvKt00wUAOWMx9M3hGGttuMA"

--------------OvKt00wUAOWMx9M3hGGttuMA
Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------wQUfzpuYAVAe51OwxDV73dkf"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------wQUfzpuYAVAe51OwxDV73dkf
Content-Type: multipart/mixed; boundary="------------0ehymILLkXIeWFd5SVtjKmfP";
 protected-headers="v1"

This is incorrect. Manually editing this to:

Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------wQUfzpuYAVAe51OwxDV73dkf"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------wQUfzpuYAVAe51OwxDV73dkf
Content-Type: multipart/mixed; boundary="------------0ehymILLkXIeWFd5SVtjKmfP";
 protected-headers="v1"

that is, removing the outer multipart/mixed layer, reinstates a properly signed message.

When a post 115 message is decrypted, the result is:

Content-Type: multipart/mixed; boundary="------------60HwA336U2O0cD07hRiDkxOK"

--------------60HwA336U2O0cD07hRiDkxOK
Content-Type: multipart/mixed; boundary="------------laayplObE6zGmWT8FThHgpy2";
 protected-headers="v1"

In general, the outer unneeded multipart/mixed layer can lead to forwarding/edit-as-new issues when the message has further attachments, as reported in bug 1843860.

Why is the outer multipart/mixed layer created? In summary it creates two issues: Permanently decrypted pre 115 messages don't show the signature (and are subject to bug 1843860) and post 115 messages are just subject to bug 1843860.

Flags: needinfo?(kaie)

BTW, I decrypted a pre 115 message using gpg -d and the result doesn't have the multipart/mixed:

Content-Type: multipart/signed; micalg=pgp-sha256;
 protocol="application/pgp-signature";
 boundary="------------wQUfzpuYAVAe51OwxDV73dkf"

This is an OpenPGP/MIME signed message (RFC 4880 and 3156)
--------------wQUfzpuYAVAe51OwxDV73dkf
Content-Type: multipart/mixed; boundary="------------0ehymILLkXIeWFd5SVtjKmfP";
 protected-headers="v1"

And for the post 115 "combined" message, the result looks like this:

Content-Type: multipart/mixed; boundary="------------lXyo7GXTdv64nd9r6iYmfztM";
 protected-headers="v1"

No additional multipart/mixed wrapper.

The additional multipart/mixed layer is used to transport the "protected headers", which includes the encrypted subject.

Flags: needinfo?(kaie)

Sorry, but if you look at comment 9, you can see two multipart/mixed layers. The outer one is inserted in
https://searchfox.org/comm-central/rev/745523fdeb9d73daaa985b08d7f6e1e98791bed5/mail/extensions/openpgp/content/modules/MimeTree.sys.mjs#623
and causes the issue. As detailed, it can be removed in a manual edit.

Sorry, I skimmed too quickly. Will look again.

I'd like to bring the following to the developers' attention:

https://bugzilla.mozilla.org/show_bug.cgi?id=1843860#c32 mentions a Betterbird patch that fixes some problems described there. But this patch also fixes the signature problem that is the subject of this bug report (for the TB version that this report relates to). This is expected because both bugs are closely related.

A few explanations, because the subject is complicated:

With encrypted messages that have been created by a recent TB version, there is currently no chance to have the signature in the decrypted copy. This is due to the fact that such messages have a so-called "combined" structure, and due to the fact that Thunderbird (and Betterbird) remove the signature completely from such messages without any traces upon permanent decryption.

In contrast, the messages that have been encrypted with an older TB version (e.g., 115) have another MIME structure. When using TB to permanently decrypt such a message, the signature is not removed from it. But due to the same bug as described in #1843860, TB (all versions including the newest one at the time of writing) creates a MIME structure in the decrypted message that it cannot read afterwards (although it is syntactically correct). That is, the signature is still in the source code of the decrypted message, but TB cannot process and display it.

This is the point where the Betterbird patch mentioned above comes into play. When using the newest Betterbird version to decrypt a message from TB 115, for example, Betterbird now creates a simpler MIME structure in the decrypted copy. Thunderbird (all versions) can correctly process that structure and consequently then shows the signature when opening the message.

As mentioned above, this works only (and is expected to work only) if the original encrypted message has the "old" structure. I am sure that this is the case for all messages that have been encrypted using TB 115 or earlier, and that this is not the case for TB 140. I am unsure about TB 128, though, since I did not research when exactly the change from the old structure to the new "combined" structure took place.

In summary we have the following situation:

The problem that the reporter has described is not solved (in no version of Thunderbird). Regardless of the technical reason (the end user does not care about MIME structures), the signature vanishes if you permanently decrypt received encrypted messages.

Even if that Betterbird patch would be applied to Thunderbird, this would solve the problem only

(a) for messages that have the "old" structure (in TB terms: that have been encrypted using an old TB version), and
(b) if you are ready to permanently decrypt those "old" messages again, using the newest Betterbird version. This might be quite some work, depending on the number of those messages, and it may be impossible if you have already permanently decrypted the messages you have received, and have thrown away the original encrypted messages.

Finally, a general question:

Is it possible to add other TB version tags to a bug report? For example, this bug report says "Version: Thunderbird 115". However, the problem is exactly the same in 128 and 140. This is currently not reflected in the bug report. Should be create a new report with version tag 140, or can new version tags be added?

Is it possible to add other TB version tags to a bug report? For example, this bug report says "Version: Thunderbird 115". However, the problem is exactly the same in 128 and 140. This is currently not reflected in the bug report. Should be create a new report with version tag 140, or can new version tags be added?

No new bug report is needed for newer versions. The tracking section of the bug report has Tracking Flags that can be set, as seen in this screen shot.

But in general tracking is not needed, because if a bug report is in the open state, then all versions higher than the setting of the version field are assumed to be affected.

Thank you very much for the fast reply. This makes perfect sense, and I've learned something new :-)

See my comments from today in bug 1843860.
As I understand this, this bug here is a wontfix, and making the structure work right and be usable for edit-as-new and forward-inline can be tracked in bug 1843860.
[edit: changed reference bug number to 1843860]

(In reply to Kai Engert [:KaiE:] from comment #18)

See my comments from today in bug 1843860.
As I understand this, this bug here is a wontfix, and making the structure work right and be usable for edit-as-new and forward-inline can be tracked in bug 1843860.

This is correct if we only take encrypted messages into account that have been created by old Thunderbird versions. Such messages don't have the "combined" structure yet. For such messages, bug 1843860 and this bug arise from exactly the same technical reason (Thunderbird can't process a problematic MIME structure that it creates when permanently decrypting such messages).

After 1843860 is fixed, the problem that is described here will not appear any more for the type of messages described above (that is, for messages with the "old" structure).

However, the problem will still arise with encrypted messages that are created by new Thunderbird versions, e.g., TB 140. Such messages have the "combined" structure, which (as you have explained elsewhere) is necessary to mitigate potential attacks. The downside is that the signature is now removed completely when permanently decrypting "new" messages.

That is, this bug report remains valid even after the fix for 1843860.

To summarize:

  • With "non-combined" encrypted messages, TB creates a problematic MIME structure upon permanent decryption. When opening the decrypted message, the signature is missing because TB cannot process that MIME structure correctly. But the signature is still in the source code of the decrypted message. TB just does not display it because it has problems with the MIME structure. The fix to that problem is indeed exactly the same fix as for 1843860.
  • However, for the new "combined" encrypted message structure, the fix for 1843860 won't effect anything (AFAIK). For such messages, the signature gets completely removed upon permanent decryption, with no traces left in the source code of the decrypted message. When opening the decrypted message, the signature cannot be displayed because it simply does not exist any more.

Consequence for the status of this bug:

If the consensus is to accept that signatures get lost upon permanent decryption, this bug is a won't-fix.

But if the consensus is that we want to see signatures in decrypted messages, especially including messages that have originally been created using the "combined" method, then this bug should be left active, and a separate fix should be developed for it. As explained above, a possible fix to 1843860 does not solve the problem with the missing signature in a decrypted message if that message originally had the "combined" structure.

Severity: -- → S3
Priority: -- → P5
Whiteboard: [mailsec-broken-fixwanted]
You need to log in before you can comment on or make changes to this bug.

Attachment

General

Creator:
Created:
Updated:
Size: