1359327 - S/MIME verification failure

Status: UNCONFIRMED

(Thunderbird :: Security, defect)

Description

[lauffer]

Attachment: ok.eml contains a smime.p7s with a "good" signature

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

Steps to reproduce:

Send a s/mime singned messages from the Horde Webmail Groupware. Horde is using php (openssl_pkcs7) to create the signed messages. We have php5-openssl-5.5.14 and openssl-1.0.2j (from the opensuse-42.2 distribution).

Thunderbird (tested versions: 45.8.0 and 53.0b2) now says this messages does not have a valid signature. openssl says the signatures are ok (so horde and Outlook 2010 says ok, too).


Actual results:

As long as we used an older opensuse-13.1 distribution for the groupware we did not have any problems with Thunderbird.

I tried to compare the sended eml files with openssl. If I diff the output of "openssl cms -in <file> -cmsout -print" of a "falid" in "invalid" messages I can see that that the digestAlgorithms has changed from sha1 to sha256. I don't think this is the problem but who knows...

Attached are three files. One message with a messages "valid" signature, one with a "invalid" and a diff between the "openssl cms -in <file> -cmsout -print" results.


Expected results:

I guess the openssl signed messages are ok. Poorly I can not say if openssl (php... horde) does something wrong or Thunderbird does...
Hopefully you may know what is wrong. ;-)

Comment 1

[lauffer]

Attachment: TB-smime-verify-failed.eml contains a "invalid" signature

Comment 2

[lauffer]

Attachment: diff the output of the "openssl cms -in ... -cmsout -print"

Comment 3

[Alfred Peters [:infofrommozilla]]

(In reply to lauffer from comment #1)
> Created attachment 8861309 [details]
> TB-smime-verify-failed.eml contains a "invalid" signature

Confirmed.

The Content-Type header of this mail is:

|Content-Type: multipart/signed; boundary="=__atOQJ7Wv69D2oXwRoRsNmh";
| protocol="application/pkcs7-signature"; micalg=sha-1

If I change it to:

|Content-Type: multipart/signed; boundary="=__atOQJ7Wv69D2oXwRoRsNmh";
| protocol="application/pkcs7-signature"; micalg=sha256

TB confirms that the signature is correct.
So, TB uses apparently the algorithm from the header.

Comment 4

[lauffer]

Hello Alfred,

good eyes, thank you! :) I will check the horde/php part because of the wrong header information.

What do you think for TB... "won't fix" or maybe be so friendly try to workaround, check for the real used digest Algorithm?

Comment 5

[Alfred Peters [:infofrommozilla]]

That is not my decision.

RFC 5751 does not mention what is to be done with an incorrect value.
Only:
| The micalg parameter allows for one-pass processing when the
| signature is being verified.  The value of the micalg parameter is
| dependent on the message digest algorithm(s) used in the calculation
| of the Message Integrity Check. [...]

and:
| Receiving agents SHOULD be able to recover gracefully from a micalg
| parameter value that they do not recognize.

But "not recognize" is something other than "wrong"