1834004 - X-Forwarded-Message passed along in the clear, even if the forward is E2E encrypted!

Status: NEW

(Thunderbird :: Security, defect)

Description

[Fredrick Brennan]

User Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/112.0.0.0 Safari/537.36

Steps to reproduce:

Forwarded a message as an attachment, and E2E encrypted it via the GUI.

Actual results:

The forwarded mail contained header:

X-Forwarded-Message-Id: <[e-mail]>

Expected results:

This header is privacy-related and should not be passed along in the clear.

Comment 1

[Magnus Melin [:mkmelin]]

It's expected that mail headers are not protected. (Subject is special.)
It seems possible snooping parties already have the information that you communicated with someone one domain x: whoever was monitoring during transfers, your ISP, you, the recipient.

Comment 2

[Kai Engert [:KaiE:]]

Yes, email e2ee doesn't claim to protect meta information.

It isn't an easy question whether Thunderbird should try to remove such meta information when forwarding a message.

Does anyone have additional thoughts?

Comment 3

[andrewg]

I think it comes down to user expectation: does the metadata of the original email count as "data" or "metadata" when it is forwarded via an encrypted attachment? I'd imagine that most people would think "data", just like they think of a subject line as "data" rather than "metadata". But understanding email metadata is already a challenge for users - do people fully understand that In-Reply-To is also unencrypted? I suspect not.

It is noted at https://www.ietf.org/archive/id/draft-autocrypt-lamps-protected-headers-02.html#name-obscured-headers that obscuring threading-metadata headers could cause difficulties with the inbox display of MUAs (e.g. sorting), so I don't think we should consider redacting X-Forwarded-Message-Id by default - however there are cases where such redaction may be useful, so perhaps there could be an option (e.g. "Redact threading metadata") for those who really need it, which removes all such headers.

Comment 4

[Fredrick Brennan]

it should be warned that it will not be redacted, if this will not just be fixed by default, i view it as quite the breach of trust that it leaks forwarded msg ID's. especially because i included msg as .eml, why does it need the header there if i included attachment as file?

if inline, it makes sense, which is why i did not send an inline forward.

Comment 5

[andrewg]

I think "breach of trust" is unfair, but email security is full of gotchas and better transparency about what is and is not protected is a good thing.

For reference, here's the discussion that led to X-Forwarded-Message-Id: https://bugzilla.mozilla.org/show_bug.cgi?id=583587

Comment 6

[Fredrick Brennan]

To be frank, I don't think it's unfair because of the context in which I did the forward.

Had I just pressed forward and it had opened up a new message window with the message in the window in line in the HTML. And then I had just written my message above it and then sent that, and then GPG encrypted that, well, I would have expected that there would have been a header like X-Forwarded-Message-ID.

But I didn't do that. I used the ability that Thunderbird has to attach the message as an attachment in the forward.

So it is equivalent to actually saving the message as a .EML file and then attaching it to a brand new message and then sending that along. I don't think that in that case you would get the same header. However, I had not tested it.

The thread that you linked (№583587) does not even really distinguish between the two cases. The keyword "EML" never appears in it at all, and also, the word "attachment" scarcely appears.

So, to be certain, I do think that it's reasonable for Thunderbird to include the header when you just press forward and it doesn't inline, but it's unreasonable when you attach it as an EML.

Comment 7

[andrewg]

Hm, I think this boils down to: what does "forward as attachment" mean to the end user? From an implementation POV, it has always been thought of as "replicate inline forwarding but without loss of original message (meta)data". It isn't an exact equivalent to "save the original as a .eml and then attach it separately" because that doesn't replicate the full feature set of inline forwarding (e.g. threading etc.).

So IMO this is in part a problem of exposing just enough implementation details to the end user to give them a misleading impression of what is actually going on, leading to an erroneous assessment of the security properties. "Forward as attachment" doesn't clearly describe what is happening from a security POV, however it's a well-understood term that is used across multiple client implementations, so changing it in Thunderbird may create more confusion than it solves. On the other hand, removing the threading header will alter behaviour of the receiving client.

Comment 8

[Kai Engert [:KaiE:]]

(In reply to andrewg from comment #7)

Hm, I think this boils down to: what does "forward as attachment" mean to the end user?

In my opinion, the intention is to enable the recipient to view the message exactly as is, keeping the original formatting and attachments - because forwarding inline may drop formatting.

I think the bug should be resolved in the following way:

If we send a message that has a cleartext subject, then observers can already learn the context, because often the original subject is kept (in adjusted form) when forwarding a message.

However, if the message is sent with subject encryption, then we should drop the header (or potentially move it into the same encrypted header space that is already used to transport the original message subject).

Comment 9

[Kai Engert [:KaiE:]]

Fredrick, would you consider the solution described in comment 8 as a sufficient fix for this bug?

Comment 10

[Fredrick Brennan]

I had to think about it but yes I would.

Comment 11

[Kai Engert [:KaiE:]]

Instead of completely removing the header, I think it would be better to remove the header from the unencrypted outer layer only, but keep it in the inner space that contains protected headers like the subject. This way, any cross-referencing functionality could keep working. (This is just a thought of today, I haven't yet thought about the consequences.)