PKCS#7/CMS verify reports bad signature
matt at openssl.org
Tue Apr 2 08:44:30 UTC 2019
On 01/04/2019 22:23, Steffen wrote:
> I believe that I have narrowed the problem down to one specific version of
> OpenSSL. Version 1.1.0b works as expected while OpenSSL 1.1.0c does not.
Using the cert/data files you provided me off-list (thanks), I was able to
confirm the above and narrow it down further to the following commit:
Author: David Benjamin <davidben at google.com>
Date: Sat Aug 20 13:35:17 2016 -0400
Implement RSASSA-PKCS1-v1_5 as specified.
RFC 3447, section 8.2.2, steps 3 and 4 states that verifiers must encode
the DigestInfo struct and then compare the result against the public key
operation result. This implies that one and only one encoding is legal.
OpenSSL instead parses with crypto/asn1, then checks that the encoding
round-trips, and allows some variations for the parameter. Sufficient
laxness in this area can allow signature forgeries, as described in
Although there aren't known attacks against OpenSSL's current scheme,
this change makes OpenSSL implement the algorithm as specified. This
avoids the uncertainty and, more importantly, helps grow a healthy
ecosystem. Laxness beyond the spec, particularly in implementations
which enjoy wide use, risks harm to the ecosystem for all. A signature
producer which only tests against OpenSSL may not notice bugs and
accidentally become widely deployed. Thus implementations have a
responsibility to honor the specification as tightly as is practical.
In some cases, the damage is permanent and the spec deviation and
security risk becomes a tax all implementors must forever pay, but not
here. Both BoringSSL and Go successfully implemented and deployed
RSASSA-PKCS1-v1_5 as specified since their respective beginnings, so
this change should be compatible enough to pin down in future OpenSSL
See also https://tools.ietf.org/html/draft-thomson-postel-was-wrong-00
As a bonus, by not having to deal with sign/verify differences, this
version is also somewhat clearer. It also more consistently enforces
digest lengths in the verify_recover codepath. The NID_md5_sha1 codepath
wasn't quite doing this right.
Reviewed-by: Kurt Roeckx <kurt at roeckx.be>
Reviewed-by: Rich Salz <rsalz at openssl.org>
(cherry picked from commit 608a026494c1e7a14f6d6cfcc5e4994fe2728836)
Implemented via this pull request:
So, based on the above description, it appears that older versions of OpenSSL
were unduly lenient in tolerating incorrectly formatted signatures. As a
security hardening measure that tolerance was removed. If you want to know more
then David Benjamin may be able to expand.
More information about the openssl-users