CVE-2024-12797: RFC7250 handshakes with unauthenticated servers don't abort as expected

Published Jan 29, 2025
·
Updated

Issue summary: Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a server may fail to notice that the server was not authenticated, because handshakes don't abort as expected when the SSLVERIFYPEER verification mode is set.

Impact summary: TLS and DTLS connections using raw public keys may be vulnerable to man-in-middle attacks when server authentication failure is not detected by clients.

RPKs are disabled by default in both TLS clients and TLS servers. The issue only arises when TLS clients explicitly enable RPK use by the server, and the server, likewise, enables sending of an RPK instead of an X.509 certificate chain. The affected clients are those that then rely on the handshake to fail when the server's RPK fails to match one of the expected public keys, by setting the verification mode to SSLVERIFYPEER.

Clients that enable server-side raw public keys can still find out that raw public key verification failed by calling SSLgetverifyresult(), and those that do, and take appropriate action, are not affected. This issue was introduced in the initial implementation of RPK support in OpenSSL 3.2.

The FIPS modules in 3.4, 3.3, 3.2, 3.1 and 3.0 are not affected by this issue.

Other sources

pyca/cryptography's wheels include a statically linked copy of OpenSSL. The versions of OpenSSL included in cryptography 42.0.0-44.0.0 are vulnerable to a security issue. More details about the vulnerability itself can be found in https://openssl-library.org/news/secadv/20250211.txt.

If you are building cryptography source ("sdist") then you are responsible for upgrading your copy of OpenSSL. Only users installing from wheels built by the cryptography project (i.e., those distributed on PyPI) need to update their cryptography versions.

GitHub

RFC7250 handshakes with unauthenticated servers don't abort as expected

Microsoft

Severity: (High) Issue summary: Clients using RFC7250 Raw Public Keys (RPKs) to authenticate a server may fail to notice that the server was not authenticated, because handshakes don't abort as expected when the SSLVERIFYPEER verification mode is set. Impact summary: TLS and DTLS connections using raw public keys may be vulnerable to man-in-middle attacks when server authentication failure is not detected by clients. RPKs are disabled by default in both TLS clients and TLS servers. The issue only arises when TLS clients explicitly enable RPK use by the server, and the server, likewise, enables sending of an RPK instead of an X.509 certificate chain. The affected clients are those that then rely on the handshake to fail when the server's RPK fails to match one of the expected public keys, by setting the verification mode to SSLVERIFYPEER. Clients that enable server-side raw public keys can still find out that raw public key verification failed by calling SSLgetverifyresult(), and those that do, and take appropriate action, are not affected. This issue was introduced in the initial implementation of RPK support in OpenSSL 3.2. The FIPS modules in 3.3, 3.2, 3.1 and 3.0 are not affected by this issue. OpenSSL 3.4, 3.3 and 3.2 are vulnerable to this issue. OpenSSL 3.4 users should upgrade to OpenSSL 3.4.1 once it is released. OpenSSL 3.3 users should upgrade to OpenSSL 3.3.2 once it is released. OpenSSL 3.2 users should upgrade to OpenSSL 3.2.4 once it is released. This issue was reported on 18th December 2024 by Apple Inc. The fix was developed by Viktor Dukhovni.

Red Hat

This CVE was automatically created from a reference found in an email or other text. If you are reading this, then this CVE entry is probably erroneous, since this text should be replaced by the official CVE description automatically.

Launchpad

Affected Software

9 affected componentsFixes available
pip/cryptography>=42.0.0<44.0.1
44.0.1
debian/openssl
1.1.1w-0+deb11u11.1.1w-0+deb11u23.0.15-1~deb12u13.0.14-1~deb12u23.4.1-1
OpenSSL OpenSSL>=3.2<3.4
Microsoft cbl2 cloud-hypervisor-cvm 38.0.72.2-5
Microsoft azl3 openssl 3.3.2-2
Microsoft azl3 openssl 3.3.3-1
Microsoft azl3 cloud-hypervisor-cvm 41.0.79-3
Microsoft azl3 cloud-hypervisor-cvm 38.0.72.2-3
IBM IBM® Db2® on Cloud Pak for Data and Db2 Warehouse on Cloud Pak for Data<=v4.8 v5.0v5.1v5.2v5.3

Remediation

Recommended actions to resolve this vulnerability, in priority order.

  1. Upgrade

    Upgrade pip/cryptography to a version that resolves this vulnerability.

    Fixed in 44.0.1
  2. Upgrade

    Upgrade debian/openssl to a version that resolves this vulnerability.

    Fixed in 1.1.1w-0+deb11u1Fixed in 1.1.1w-0+deb11u2Fixed in 3.0.15-1~deb12u1Fixed in 3.0.14-1~deb12u2Fixed in 3.4.1-1
  3. Upgrade

    Upgrade OpenSSL 3.2 to a version that resolves this vulnerability.

    Fixed in 3.2.4
  4. Upgrade

    Upgrade OpenSSL 3.3 to a version that resolves this vulnerability.

    Fixed in 3.3.2
  5. Upgrade

    Upgrade OpenSSL 3.4 to a version that resolves this vulnerability.

    Fixed in 3.4.1
  6. Upgrade

    Upgrade cryptography (pyca/cryptography) bundled OpenSSL to a version that resolves this vulnerability.

    Patch CVE-2024-12797

Event History

Jan 29, 2025
Data Sourced
via Red Hat·09:28 AM
DescriptionSeverityAffected Software
Feb 11, 2025
CVE Published
via MITRE·03:59 PM
Data Sourced
via MITRE·03:59 PM
DescriptionWeakness
Data Sourced
via NVD·04:15 PM
DescriptionSeverityWeakness
Advisory Published
via GitHub·06:06 PM
Feb 15, 2025
Data Sourced
via Ubuntu·11:28 PM
RemedyDescriptionSeverityAffected Software
Feb 21, 2025
Data Sourced
via Microsoft·12:00 AM
DescriptionSeverityWeaknessAffected Software
Updated
via Microsoft·08:00 AM
DescriptionSeverity
Updated
via Microsoft·08:00 AM
SeverityAffected Software
Feb 24, 2025
Data Sourced
via Launchpad·10:48 PM
Description
Jun 19, 2026
Data Sourced
via IBM·12:00 AM
DescriptionAffected Software

Parent advisories

This vulnerability appears in the following advisories.

Free Weekly Intel

Don't miss critical vulnerabilities

Join thousands of security professionals who receive our weekly digest of trending CVEs, zero-days, and exploited vulnerabilities.

No spam. Unsubscribe anytime.

Frequently Asked Questions

1

What is the severity of CVE-2024-12797?

CVE-2024-12797 is considered a high severity vulnerability due to the potential for unauthenticated server connections.

2

How do I fix CVE-2024-12797?

To mitigate CVE-2024-12797, ensure that the SSL_VERIFY_PEER verification mode is set correctly during TLS handshakes.

3

What impact does CVE-2024-12797 have on OpenSSL versions?

CVE-2024-12797 affects OpenSSL versions from 3.2 up to, but not including, 3.4.

4

What type of authentication is affected by CVE-2024-12797?

CVE-2024-12797 impacts clients using RFC7250 Raw Public Keys for server authentication.

5

When was CVE-2024-12797 disclosed?

CVE-2024-12797 was disclosed on February 11, 2025.

Contact

SecAlerts Pty Ltd.
132 Wickham Terrace
Fortitude Valley,
QLD 4006, Australia
info@secalerts.co
By using SecAlerts services, you agree to our services end-user license agreement. This website is safeguarded by reCAPTCHA and governed by the Google Privacy Policy and Terms of Service. All names, logos, and brands of products are owned by their respective owners, and any usage of these names, logos, and brands for identification purposes only does not imply endorsement. If you possess any content that requires removal, please get in touch with us.
© 2026 SecAlerts Pty Ltd.
ABN: 70 645 966 203, ACN: 645 966 203