This relands https://boringssl-review.googlesource.com/c/boringssl/+/54606, which was temporarily reverted. Update-Note: By default, clients will now require RSA server certificates used in TLS 1.2 and earlier to include the keyEncipherment or digitalSignature bit. keyEncipherment is required if using RSA key exchange. digitalSignature is required if using ECDHE_RSA key exchange. If unsure, TLS RSA server signatures should include both, but some deployments may wish to include only one if separating keys, or simply disabling RSA key exchange. The latter is useful to mitigate either the Bleichenbacher attack (from 1998, most recently resurfaced in 2017 as ROBOT), or to strengthen TLS 1.3 downgrade protections, which is particularly important for enterprise environments using client certificates (aka "mTLS") because, prior to TLS 1.3, the TLS client certificate flow was insufficiently encrypted or authenticated. Without reflecting an RSA key exchange disable into key usage, and then the client checking it, an attacker can spoof a CertificateRequest as coming from some server. This aligns with standard security requirements for using X.509 certificates, specified in RFC 5280, section 4.2.1.3, and reiterated in TLS as early as TLS 1.0, RFC 2246, section 7.4.2, published 24 years ago on January 1999. Constraints on usage of keys are important to mitigate cross-protocol attacks, a class of cryptographic attacks that is well-studied in the literature. We already checked this for each of ECDSA, TLS 1.3, and servers verifying client certificates, so this just fills in the remaining hole. As a result, this change is also important for avoiding some weird behaviors when configuration changes transition a server in or out of this hole. (We've seen connection failures get misattributed to TLS 1.3 when it was really a certificate misconfiguration.) Chrome has also enforced this for some time with publicly-trusted certificates. As a temporary measure for callers that need more time, the SSL_set_enforce_rsa_key_usage API, added to BoringSSL in January 2019, still exists where we need to turn this off. Fixed: 519 Change-Id: I91bf2cfb04c92aec7875e640f90ba6f837146dc1 Reviewed-on: https://boringssl-review.googlesource.com/c/boringssl/+/58805 Commit-Queue: David Benjamin <davidben@google.com> Reviewed-by: Bob Beck <bbe@google.com>fips-20230428
parent
fa7afff95a
commit
cee2dbb08c
4 changed files with 10 additions and 21 deletions
Loading…
Reference in new issue