# OpenSSL Advisory: March 25th, 2021 (BoringSSL Not Affected)

OpenSSL have published a [security advisory](https://www.openssl.org/news/secadv/20210325.txt). Here's how it affects BoringSSL:

CVE | Summary | [Severity] in OpenSSL | Impact to BoringSSL
----|---------|-----------------------|---------------------
CVE-2021-3450 | CA certificate check bypass with X509_V_FLAG_X509_STRICT | High | Not affected, issue was introduced after fork
CVE-2021-3449 | NULL pointer deref in signature_algorithms processing | High | Not affected, issue was introduced after fork

[Severity]: https://openssl-library.org/policies/general/security-policy/index.html#issue-severity

## CVE-2021-3450: CA certificate check bypass with X509_V_FLAG_X509_STRICT

BoringSSL is not affected. While `X509_V_FLAG_X509_STRICT` existed before the fork, the bug itself was introduced afterwards. The issue was in a check for explicitly-encoded elliptic curve parameters in the certificate. BoringSSL’s public key parser has rejected such inputs since December 2015, so we handle those elsewhere.

## CVE-2021-3449: NULL pointer deref in signature_algorithms processing

BoringSSL is not affected. The bug was introduced after the fork. It is triggered by TLS renegotiation in servers, which we removed in May 2015.

The bug itself comes from a combination of mixing initial vs. renegotiation handshake state and forgetting to update both the pointer and length of a buffer together. BoringSSL keeps most handshake state on a separate `SSL_HANDSHAKE` structure which we destroy and recreate on each handshake. This reduces the risk of mixing state between initial and renegotiation handshakes. As part of our move to C++, we also moved most buffers in the TLS implementation to a `bssl::Array` structure which manages the pointer and length together.