Botan is a widely used cryptographic library written in C++. It handles a lot of crucial crypto tasks, like TLS handshakes and certificate checks. If you use TLS or anything that trusts public certificates, you probably depend indirectly on libraries like Botan—even if you don’t know it!

In late 2022, a security vulnerability was found in Botan (all versions before 2.19.3) that could let an attacker *forge OCSP responses*, tricking clients into believing a certificate is valid even when it might be revoked or fake. This is tracked as CVE-2022-43705.

Let’s break down how this bug happened, why it’s dangerous, and how an attacker could work with it. We'll even look at some code and the official fix.

What is OCSP and Why Should You Care?

When you visit an HTTPS website, your browser checks whether that site's certificate is still good or if it’s been revoked (for example, because of a security breach or the owner abandoning it). The Online Certificate Status Protocol (OCSP) is a way for software to check this, by asking a trusted third-party *OCSP responder*. If someone messes with OCSP, you might end up trusting revoked or fraudulent certificates, opening the door to phishing and man-in-the-middle attacks.

When did it start?

This issue was introduced in Botan 1.11.34 (November 2016) and wasn’t fixed until version 2.19.3.

What went wrong?

When Botan code verified an OCSP response, it didn’t properly check that the response was *signed by the correct authority*—the CA that actually issued the certificate, or a delegated OCSP responder. Instead, Botan might accept any OCSP response signed by any certificate that looks valid.

This means: an attacker who can create or get a certificate trusted by the application can forge OCSP responses, making revoked or fake certificates look valid.

Real-World Impact

- Fake Certificate Trust: Attackers can pretend that a revoked or malicious certificate is still good, defeating OCSP checking.
- Man-in-the-Middle (MitM) Attacks: Malicious servers can serve up forged OCSP responses, making users trust (and connect to) a server they shouldn’t.
- Used in Everything: Botan is used in a lot of open source projects and even some commercial products.

Let's see what went wrong. Here's a simplified version of the vulnerable verification logic

// Old Broken Logic (before 2.19.3)
bool OCSP::Response::check_signature(const X509_Certificate& ca_cert)
{
   // Check signature with the provided CA cert
   if(m_response_sig_algo == ca_cert.subject_public_key_algo() &&
      ca_cert.check_signature(m_tbs_bits, m_response_signature))
   {
      return true;
   }

   // ...but what if a CA with valid signature?
   // BAD: Fails to check the issuer is the correct one!
   return false;
}


The crucial missing part: does the certificate used for OCSP signing actually match the *issuer* of the certificate being checked? Here, any cert that can sign could be accepted.

After the fix, Botan checks the responder’s identity strictly matches the legit CA who issued the original cert (or a properly delegated responder).

Fixed code uses stricter checks

// Simplified example of new logic
bool OCSP::Response::check_signature(const X509_Certificate& ca_cert)
{
   if(responder_is_authorized(responder_cert, ca_cert))
   {
      // Only accept responses signed by the correct CA
      return responder_cert.check_signature(m_tbs_bits, m_response_signature);
   }
   return false;
}

For full details, see the official fix PR on Github.

Signs it with their own cert.

- Says "Yep, this revoked/fake cert is totally fine!"

Here’s a simplified Python example using Scapy (not production, illustrative)

# Crafts a fake OCSP response (pseudocode)
from scapy.layers.ssl_tls import *

# Load attacker's signer certificate (trusted, but not CA)
signer_cert = load_certificate("attacker_cert.pem")

# Forge a "good" OCSP response for a revoked or fake cert
ocsp_response = build_ocsp_response(
    responder_cert=signer_cert,
    status="good",
    cert_serial="123456789",
    signature=sign_with_attacker_cert()
)

# Send to client or server using Botan before 2.19.3


The details would vary depending on the real deployment, but if you control the OCSP response Botan sees, you can defeat revocation checks.

Mitigation

Upgrade to Botan >= 2.19.3 as soon as you can.

Be suspicious of custom OCSP responders or responses (e.g., local proxies or "middleboxes").

- Consider using Certificate Transparency and/or CAA as additional layers of trust.

References

- CVE-2022-43705 (NIST NVD)
- Botan Security Release
- GitHub issue and fix
- Botan Changelog

Conclusion

This bug in Botan demonstrates how a seemingly minor mistake in signature validation logic can lead to a major security hole: *forged OCSP responses*, and thus the risk of trusting revoked, spoofed, or even stolen certificates. If you're using Botan, update to 2.19.3 or later now to ensure your application isn't tricked by fake OCSP answers!

Timeline

Published on: 11/27/2022 04:15:00 UTC
Last modified on: 12/01/2022 19:20:00 UTC