Stop accepting certificates signed using SHA1 at security level 1
authorKurt Roeckx <kurt@roeckx.be>
Thu, 2 Jan 2020 22:25:27 +0000 (23:25 +0100)
committerKurt Roeckx <kurt@roeckx.be>
Wed, 5 Feb 2020 21:04:37 +0000 (22:04 +0100)
Reviewed-by: Viktor Dukhovni <viktor@openssl.org>
GH: #10786

CHANGES
NEWS
crypto/rsa/rsa_ameth.c
crypto/x509/x509_set.c
test/recipes/25-test_verify.t

diff --git a/CHANGES b/CHANGES
index 1750162a1081c50fa2ee12f08facf6228e0b9b85..7b18d510771574615ad92122a103bbb47c628399 100644 (file)
--- a/CHANGES
+++ b/CHANGES
@@ -9,6 +9,18 @@
 
  Changes between 1.1.1 and 3.0.0 [xx XXX xxxx]
 
+  *) X509 certificates signed using SHA1 are no longer allowed at security
+     level 1 and above.
+     In TLS/SSL the default security level is 1. It can be set either
+     using the cipher string with @SECLEVEL, or calling
+     SSL_CTX_set_security_level(). If the leaf certificate is signed with SHA-1,
+     a call to SSL_CTX_use_certificate() will fail if the security level is not
+     lowered first.
+     Outside TLS/SSL, the default security level is -1 (effectively 0). It can
+     be set using X509_VERIFY_PARAM_set_auth_level() or using the -auth_level
+     options of the apps.
+     [Kurt Roeckx]
+
   *) Reworked the treatment of EC EVP_PKEYs with the SM2 curve to
      automatically become EVP_PKEY_SM2 rather than EVP_PKEY_EC.
      This means that applications don't have to look at the curve NID and
diff --git a/NEWS b/NEWS
index de439d6bb134509597989994b8e916d9ddca2daf..4d7f0d01c6e45c862e5fa3b889bafa9f0607946c 100644 (file)
--- a/NEWS
+++ b/NEWS
@@ -7,6 +7,10 @@
 
   Major changes between OpenSSL 1.1.1 and OpenSSL 3.0.0 [under development]
 
+      o X509 certificates signed using SHA1 are no longer allowed at security
+        level 1 or higher. The default security level for TLS is 1, so
+        certificates signed using SHA1 are by default no longer trusted to
+        authenticate servers or clients.
       o enable-crypto-mdebug and enable-crypto-mdebug-backtrace were mostly
         disabled; the project uses address sanitize/leak-detect instead.
       o Added OSSL_SERIALIZER, a generic serializer API.
index 3246f33688bdaa89f7b36099753244f318daceb8..485ac35a6f7455eec75cf8e1cb181355bd80dbe1 100644 (file)
@@ -859,6 +859,7 @@ static int rsa_sig_info_set(X509_SIG_INFO *siginf, const X509_ALGOR *sigalg,
     uint32_t flags;
     const EVP_MD *mgf1md = NULL, *md = NULL;
     RSA_PSS_PARAMS *pss;
+    int secbits;
 
     /* Sanity check: make sure it is PSS */
     if (OBJ_obj2nid(sigalg->algorithm) != EVP_PKEY_RSA_PSS)
@@ -878,7 +879,24 @@ static int rsa_sig_info_set(X509_SIG_INFO *siginf, const X509_ALGOR *sigalg,
     else
         flags = 0;
     /* Note: security bits half number of digest bits */
-    X509_SIG_INFO_set(siginf, mdnid, EVP_PKEY_RSA_PSS, EVP_MD_size(md) * 4,
+    secbits = EVP_MD_size(md) * 4;
+    /*
+     * SHA1 and MD5 are known to be broken. Reduce security bits so that
+     * they're no longer accepted at security level 1. The real values don't
+     * really matter as long as they're lower than 80, which is our security
+     * level 1.
+     * https://eprint.iacr.org/2020/014 puts a chosen-prefix attack for SHA1 at
+     * 2^63.4
+     * https://documents.epfl.ch/users/l/le/lenstra/public/papers/lat.pdf
+     * puts a chosen-prefix attack for MD5 at 2^39.
+     */
+    if (mdnid == NID_sha1)
+        secbits = 64;
+    else if (mdnid == NID_md5_sha1)
+        secbits = 68;
+    else if (mdnid == NID_md5)
+        secbits = 39;
+    X509_SIG_INFO_set(siginf, mdnid, EVP_PKEY_RSA_PSS, secbits,
                       flags);
     rv = 1;
     err:
index e325a57b2971f3ff2ad702bf8cfec754c8745476..97676c2ecd6007505ddbac543ca2dcc24be300d8 100644 (file)
@@ -222,6 +222,20 @@ static void x509_sig_info_init(X509_SIG_INFO *siginf, const X509_ALGOR *alg,
         return;
     /* Security bits: half number of bits in digest */
     siginf->secbits = EVP_MD_size(md) * 4;
+    /*
+     * SHA1 and MD5 are known to be broken. Reduce security bits so that
+     * they're no longer accepted at security level 1. The real values don't
+     * really matter as long as they're lower than 80, which is our security
+     * level 1.
+     * https://eprint.iacr.org/2020/014 puts a chosen-prefix attack for SHA1 at
+     * 2^63.4
+     * https://documents.epfl.ch/users/l/le/lenstra/public/papers/lat.pdf
+     * puts a chosen-prefix attack for MD5 at 2^39.
+     */
+    if (mdnid == NID_sha1)
+        siginf->secbits = 63;
+    else if (mdnid == NID_md5)
+        siginf->secbits = 39;
     switch (mdnid) {
         case NID_sha1:
         case NID_sha256:
index 915c902b159c8f0492dc7dffb5a3b07c66e72dd4..219e7e1149a63d477b8b67a0fb0ee4d9e4a9fb04 100644 (file)
@@ -336,14 +336,14 @@ ok(!verify("badalt9-cert", "sslserver", ["root-cert"], ["ncca1-cert", "ncca3-cer
 ok(!verify("badalt10-cert", "sslserver", ["root-cert"], ["ncca1-cert", "ncca3-cert"], ),
    "Name constraints nested DNS name excluded");
 
-ok(verify("ee-pss-sha1-cert", "sslserver", ["root-cert"], ["ca-cert"], ),
-    "Certificate PSS signature using SHA1");
+ok(verify("ee-pss-sha1-cert", "sslserver", ["root-cert"], ["ca-cert"], "-auth_level", "0"),
+    "Accept PSS signature using SHA1 at auth level 0");
 
 ok(verify("ee-pss-sha256-cert", "sslserver", ["root-cert"], ["ca-cert"], ),
     "CA with PSS signature using SHA256");
 
-ok(!verify("ee-pss-sha1-cert", "sslserver", ["root-cert"], ["ca-cert"], "-auth_level", "2"),
-    "Reject PSS signature using SHA1 and auth level 2");
+ok(!verify("ee-pss-sha1-cert", "sslserver", ["root-cert"], ["ca-cert"], "-auth_level", "1"),
+    "Reject PSS signature using SHA1 and auth level 1");
 
 ok(verify("ee-pss-sha256-cert", "sslserver", ["root-cert"], ["ca-cert"], "-auth_level", "2"),
     "PSS signature using SHA256 and auth level 2");