Closed Bug 332639 Opened 16 years ago Closed 7 years ago
force display of Sender header if S/MIME sender is the signer
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.
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?
Component: Mail Window Front End → Security: S/MIME
Product: Thunderbird → MailNews Core
QA Contact: front-end → s.mime
#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.
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.)
Status: UNCONFIRMED → NEW
Ever confirmed: true
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.
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.
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
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.
OS: Windows XP → All
Hardware: x86 → All
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 email@example.com and the certificate matches firstname.lastname@example.org, 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: email@example.com" 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.
Raising importance because this allows spoofing of signatures. Bug 940678 has other solutions to the underlying issue.
Severity: enhancement → major
This forces displaying the Sender if it was the sender that signed the message.
Assignee: nobody → mkmelin+mozilla
Status: NEW → ASSIGNED
Attachment #8336306 - Flags: review?(mbanner)
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 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?
Attachment #8336306 - Flags: review?(standard8)
(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?
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 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.
Attachment #8432210 - Flags: review?(standard8) → review+
Magnus: Can you please verify this passes the tests?
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
Status: ASSIGNED → RESOLVED
Closed: 7 years ago
Resolution: --- → FIXED
Summary: force display of S/MIME sender CN from certificate instead of From name → force display of Sender header if S/MIME sender is the signer
Target Milestone: --- → Thunderbird 35.0
You need to log in before you can comment on or make changes to this bug.