0

I have a very strange problem and i would like to get some guidance on this. Problem description: My application is sending S/MIME signed Email messages to clients. It worked perfectly no problems were reported and also in my mail client and with openssl i could verify the S/MIME Signature. Now something odd happened: When sending a large number of mails (200k) some users reported the email signature seems to be invalid. One of the users sent me the mail as an .eml and i tried to verify the signature with openssl.

openssl smime -verify -in invalidSignature.eml -noverify

Output:

408160FD01000000:error:10800065:PKCS7 routines:PKCS7_signatureVerify:digest failure:crypto/pkcs7/pk7_doit.c:1089:
408160FD01000000:error:10800069:PKCS7 routines:PKCS7_verify:signature failure:crypto/pkcs7/pk7_smime.c:363:

The .eml also appears with an invalid signature in my email clients. So the problems seems to be the message digest. Users are also reporting, if they are clicking on the certificate itself the certificate appears to be valid.

So i compared the invalidSignature.eml to a successfullMail.eml and the mails are exactly the same. The only difference is the signature and the boundary numbers. I cannot explain to myself how this happened the problem is i cannot replicate this issue.

I know this is a very broad question but can somebody of you provide some guidance on how to debug this? The problem is im 100% sure this is about my application or the mail system and not some malicious activity. Maybe somebody has experience with troubleshooting such issues and can provide guidance. Thank you

Edit: I made some wrong assumptions. I think my solution may still provide value to some people: The problem was in the S/MIME implementation i signed the subject header as well. The odd thing is it seems like in 90% of cases this actually works and most mail clients will indeed verify the signature. However some very special subject headers break the signature. I still cannot figure out what's exactly causing this, but in general i read up about the topic and the subject header shouldn't be signed. Thanks for your help!

Lorem ipsum
  • 111
  • 4
  • 1
    Are these mails only signed or signed and encrypted? If only signed - are any non-ASCII characters used in the mail (might be an issue with recoding the mail in MTA triggered by missing support for 8BITMIME in upstream). Do you see a common pattern with the users, like always same users and/or same organisation affected (i.e. same path of email delivery)? – Steffen Ullrich Nov 14 '23 at 19:37
  • Thanks for your response! The mails are not encrypted + signed. Yes they contain a lot of non ascii characters, however the mail is a html mail and the non ascii characters are encoded. The same path of delivery is an interesting point i'm still investigating this. But how could the path of email delivery affect this? – Lorem ipsum Nov 14 '23 at 20:43
  • 1
    How did you compare them to find they are 'exactly the same'? Many comparison programs deliberately ignore differences like LF versus CRLF or trailing spaces which don't matter to people, but DO matter to digital signature. If the signature blocks are different, do they contain the same messageDigest attribute or not? – dave_thompson_085 Nov 15 '23 at 00:47
  • 2
    "however the mail is a html mail and the non ascii characters are encoded" - are you sure? The usual way is to simply define the charset in HTML and to not encode. Also mails commonly contain also an alternative text/plain part together with the text/html part, where this encoding might not happen. Apart from that SMTP limits the line length to 1000, which might be not properly done in the sender too and thus will be recoded on the path. – Steffen Ullrich Nov 15 '23 at 05:46
  • 2
    What I have in mind is a recoding for some recipients but not for others, similar to what I have described here for DKIM. While the latter is about DKIM is basically the same problem - not properly encoding content to ASCII before signing so that it gets recoded on the way due to properties of the MTA which then breaks the signature. – Steffen Ullrich Nov 15 '23 at 05:47
  • Thank you for your help i will take a look at this. – Lorem ipsum Nov 15 '23 at 06:36
  • @dave_thompson_085 I compared them in vs code also copy and pasted part of the mails to check if the openssl command will still verify the mail as successful. Regarding the messageDigest: The problem is i'm not sure how to get the messageDigest to be honest. I did the following: openssl cms -in failedMail.eml -cmsout -print for the failed and the valid mail both have different octet-strings for the attribute messageDigest – Lorem ipsum Nov 15 '23 at 07:38
  • 1
    @Loremipsum You may want to try extracting just the part that is signed from each of the messages, then taking a hash (e.g. sha256) of each. If the hashes are not the same, then there is some difference between the two. If that's the case, then diff could be handy for finding where the differences are. My hunch is that Steffen is right that some MTA somewhere in the delivery path is altering these messages, causing the signature to break - possibly because of some invalid character, line length limit, or some other anomaly. – mti2935 Nov 15 '23 at 10:21
  • (1) I don't use/know vscode but other programming tools I have used often ignore line-ending difference (CRLF/LF) or change one to the other to allow programs to work between Unix and Windows. Some also ignore or alter space/tab and Unicode 'features' like BOM and bidi. Cut-and-paste usually changes line-endings and spacing and other invisible characters. (2) cms -cmsout -print is indeed a good way to see the messageDigest attribute (in signedAttrs in signerInfos), and if it is different then the data in those messages IS DIFFERENT even if they LOOK the same or compare 'equal' – dave_thompson_085 Nov 15 '23 at 22:39
  • Thank you for all your help! The problem was about the Subject of the mail it was speciffiic to a mail not clients. The S/MIME implementation i'm using is signging the subject header as well and this leads to problems for like 1% of subject headers apparently. Does somebody know if it's common to sign the subject header as well? I cannot find any information on this unfortunately. Some mention it's allowed some mention it's not. – Lorem ipsum Nov 16 '23 at 09:28
  • It is uncommon to include any header. There is an experimental draft, but I wouldn't know of any implementation. There are 'Protected Headers' approaches, but then these headers become part of the message body, which guarantees back compatibility. Authenticated Encryption with Associated Data (AEAD) is another approach, but I'm not aware of clients using it. Did your emails come across an Outlook server? They're infamous for rewriting emails, causing signatures to fail. – not2savvy Nov 16 '23 at 09:44

0 Answers0