332639 - force display of Sender header if S/MIME sender is the signer

Status: RESOLVED FIXED

(MailNews Core :: Security: S/MIME, defect)

Description

[Niels Endres]

User-Agent:       Mozilla/4.0 (compatible; MSIE 6.0; Windows NT 5.1; SV1; .NET CLR 1.1.4322; .NET CLR 2.0.50727; InfoPath.1)
Build Identifier: version 1.5 (20051201)

When displaying a signed message, the sender certificate is verified against the email address provided in the From: header, but not the friendly name.  It would be a good idea to have an option to force the display of the CN from the certificate and ignore the From: line as it may have been tampered with.

Reproducible: Always

Steps to Reproduce:
1. sign a message with a fake name (that differs from the certificate CN)

Actual Results:  
The message is displayed with a valid signature and the fake friendly name.  The only way to obtain the verified name is to click on the signature icon.

Expected Results:  
An option is needed to display the CN from the certificate when a message is displayed that has a valid signature.

Comment 1

[Bob Lord]

I agree that when I receive a signed email that TB should be conservative about what it claims to be true. The CN may not be the right thing to display, however.  In my case, I sign some emails with a cert that looks like this:
    CN = StartCom Free Certificate Member
    O = Persona Not Validated

So that won't work. Perhaps not showing the friendly name? Or making it gray?

Comment 3

[František Kučera]

#728607 was marked as duplicate of this bug, but it is not the same issue/request.

The Common name is not so important* but the e-mail addres is crucial – it is unique identifier.

So i think that the first step** should be: showing the value of Sender header (see #728607). And second step may be: showing the Common name from the certificate.

*) it can be e.g. „Ing. František Kučera“ in From/Sender header but „Frantisek Kucera“ in certificate – it is same person (from human perspective), but not exactly the same string (from computer perspective).

**) and also it is easier step – just show Sender header in GUI if present and differs from the From header value.

Comment 4

[Kai Engert (:KaiE:)]

In my opinion, the "valid signature icon" justifies showing only information that we are sure about.

I agree showing the non-signed email's From name is bad.
Showing information taken out of the mail header's isn't better, it can be forged, too.

I guess in order to make a reliable decision whether the certificate's CN contains a real name or not, would require to know something about the verification level of the certificate (e.g. class 1, class 2, etc.)

But I'm worried there is no standard yet to automatically determine that, or is there?

Maybe the most basic information that can be shown is the email address contained in the certificate.
If the certificate has multiple email addresses, we should choose the one that matches the sender from the headers.

In addition, we could say, if there is a sufficient "similarity" between "From name" and "CN attribute", we could decide to show the CN.

(We could use one of the existing algorithms that create a similarity ratio for two strings.)

Comment 5

[František Kučera]

Coud be the config option "mailnews.headers.showSender" set to "true" by default?

It will lead to showing the Sender header in GUI (if present in message), so the recipient will know, who sent or may be signed the message.

Comment 6

[Niels Endres]

Showing headers doesn't fix this, as headers can be forged as they're not part of the signed portion of the email.  (even the subject is suspect).

The only sensible solution is to either:

a) display nothing at all
b) display only info from the certificate itself, (even if that results in a 'From' of "StartCom Free Certificate Member" being displayed).

I'm not a fan of trying to detect if the 'From' is similar to the 'CN' or not.  The simple state of play is that the 'From' is untrusted, and showing the signed icon gives a false sense of security.  Also, any such processing just opens up exploits.

I logged this bug more than 6 years ago, and no longer use this mail client, so can't even confirm if the issue is even present, but wanted to reply to the previous few comments as don't fix the fundamental problem.

Comment 7

[František Kučera]

Yes, From and Sender headers can be forged. But if they are*, Thunderbird shows different icon**, so user will not trust them.

But if the Sender header is hidden in GUI and only From is visible, the message can be signed with Sender's certificate, the valid signature icon will be shown and user may think that message was signed byl From's certificate.

If both headers are shown, user will see that message can be signed by anobody of them (and will look at signature details or just trust, if both persons are OK for him).

*) Address in certificate does not match with neither From nor Sender headers.

**) the one with question mark „Signed, but the signature is doubtful“ – http://kb.mozillazine.org/Message_security#Receiving_mail

Comment 8

[Frederik Braun [:freddy]]

German tech news site heise.de just reported about this. The article comes with a screenshot of a fake email with a "From" header showing Angela Merkel and a valid and S/MIME signed "Sender" that is somebody else. Brace for impact :)

I guess the article should be readable in English with your favorite translation service.

Comment 9

[Roland Tanglao needinfo please :rolandtanglao, :mohnkuchen, :adobo, :sinigang, :roland]

http://www.thunderbird-mail.de/forum/viewtopic.php?f=33&t=64700

Comment 10

[Steffen Wilberg]

http://www.heise.de/security/meldung/Thunderbird-gibt-falschem-Absender-das-Echtheits-Siegel-2044405.html
describes a bug where the From email header is forged, the Sender is [e-mail] and the certificate matches [e-mail], but we don't show neither the Sender header nor the email given in the certificate, so we display the message as coming from the person claimed in the From header (which is forged), *and* having a valid certificate.

Outlook, Apple Mail and Evolution show a "Signed by: [e-mail]" header. Can't we at least do that as well?
Live Mail even presents a big scary warning if the From header and the email in the certificate don't match.

Comment 11

[Florian Bender]

Raising importance because this allows spoofing of signatures. Bug 940678 has other solutions to the underlying issue.

Comment 12

[Magnus Melin [:mkmelin]]

Attachment: proposed fix

This forces displaying the Sender if it was the sender that signed the message.

Comment 13

[Magnus Melin [:mkmelin]]

If we take bug 940678 does make this whole approach less needed. But I'd give is some values still... (my patch needs some slight adjustment then)

As for forcing the common name form the cert (like the title suggests), those are often just the email address so it might not be so nice. (Like comment 1 suggests.)

Comment 14

[Mark Banner (:standard8)]

Comment on attachment 8336306 [details] [diff] [review]
proposed fix

So I think its generally right to rely on the from field as per bug 940678. Can you update the patch or document your thoughts on how we further improve this?

Comment 15

[Wayne Mery (:wsmwk)]

(In reply to Mark Banner (:standard8) from comment #14)
> Comment on attachment 8336306 [details] [diff] [review]
> proposed fix
> 
> So I think its generally right to rely on the from field as per bug 940678.
> Can you update the patch or document your thoughts on how we further improve
> this?

Comment 16

[Magnus Melin [:mkmelin]]

Attachment: proposed fix, v2

So after bug 940678 we show the question mark if it's the Sender that signed the message. The mismatch icon can be clicked to see the Sender (address) that signed the message - I think it's reasonable to have a possible Sender header showing in the header pane for that case, so that you can easily make the mental connection.

Comment 17

[Mark Banner (:standard8)]

Comment on attachment 8432210 [details] [diff] [review]
proposed fix, v2

Review of attachment 8432210 [details] [diff] [review]:
-----------------------------------------------------------------

This looks reasonable, please make sure that mozmill tests are still passing before you land it.

Comment 18

[Florian Bender]

Magnus: Can you please verify this passes the tests?

Comment 19

[Magnus Melin [:mkmelin]]

try looks ok - https://tbpl.mozilla.org/?tree=Thunderbird-Try&rev=0736def4da31

Comment 20

[Magnus Melin [:mkmelin]]

Updating summary to what was done in this bug. I realize it not exactly what was initially asked for, but using what is in the cert directly doesn't seem doable as discussed above.

https://hg.mozilla.org/comm-central/rev/bf38e999b0d8 -> FIXED