CVE-2024-34447: Bouncy Castle Information Disclosure Bug

CVE-2024-34447 Overview

CVE-2024-34447 is a hostname verification bypass vulnerability discovered in the Bouncy Castle Crypto Package for Java. This Certificate Validation Bypass vulnerability affects the BCJSSE (Bouncy Castle Java Secure Socket Extension) implementation when endpoint identification is enabled and an SSL socket is created without an explicit hostname. In these situations, hostname verification may be performed against a DNS-resolved IP address rather than the intended hostname, creating an opportunity for DNS poisoning attacks that could lead to man-in-the-middle scenarios.

Critical Impact

Attackers capable of performing DNS poisoning attacks could potentially intercept TLS connections, leading to confidential data exposure when applications rely on HttpsURLConnection without explicit hostname specification.

Affected Products

• Bouncy Castle Java versions before 1.78
• Bouncy Castle Java (LTS) versions before 2.73.6
• BC TLS Java versions before 1.0.19
• BC FIPS TLS Java versions before 1.0.19

Discovery Timeline

• 2024-05-03 - CVE-2024-34447 published to NVD
• 2025-06-17 - Last updated in NVD database

Technical Details for CVE-2024-34447

Vulnerability Analysis

This vulnerability stems from improper certificate validation within the BCJSSE TLS implementation. The flaw is classified under CWE-297 (Improper Validation of Certificate with Host Mismatch), which describes scenarios where a certificate's host identity is not properly verified against the intended connection target.

When Java applications use HttpsURLConnection to establish secure connections, the underlying TLS implementation should verify that the server's certificate matches the hostname being connected to. However, when an SSL socket is created without an explicit hostname parameter in affected Bouncy Castle versions, the hostname verification process may incorrectly validate against a DNS-resolved IP address instead of the original hostname.

This creates a window of opportunity for attackers who can manipulate DNS responses. By poisoning DNS records to point a legitimate hostname to an attacker-controlled IP address, and presenting a certificate that matches the IP address (or exploiting the verification gap), an attacker could potentially intercept encrypted communications.

Root Cause

The root cause of this vulnerability lies in the BCJSSE's hostname verification logic when processing SSL/TLS connections initiated through HttpsURLConnection without explicit hostname specification. The implementation fails to properly propagate the original target hostname through the certificate validation chain, instead falling back to IP address-based verification in certain code paths. This behavior violates the expected TLS hostname verification semantics and creates a trust boundary issue.

Attack Vector

This vulnerability is exploitable via network-based attacks. An attacker must be positioned to perform DNS poisoning against the target application's DNS resolver. The attack scenario involves:

1. The victim application initiates an HTTPS connection using HttpsURLConnection without specifying an explicit hostname in the SSL socket creation
2. The attacker poisons the DNS response, redirecting the hostname to an attacker-controlled server
3. The attacker's server presents a certificate that passes the weakened verification (or exploits the IP-based validation path)
4. The victim application establishes what it believes is a secure connection, but traffic is intercepted

The attack requires no privileges or user interaction, making it a network-accessible vulnerability that could be exploited remotely against vulnerable Java applications using Bouncy Castle for TLS operations.

Detection Methods for CVE-2024-34447

Indicators of Compromise

• Unexpected DNS resolution results for trusted hostnames pointing to unfamiliar IP addresses
• TLS certificate mismatches in application logs where the certificate subject does not match the intended hostname
• Network traffic anomalies showing connections to unexpected IP addresses for known service endpoints
• Certificate chain validation warnings in Java application logs using Bouncy Castle JSSE

Detection Strategies

• Implement DNS monitoring to detect potential poisoning attempts targeting critical application domains
• Deploy network traffic analysis to identify TLS connections to unexpected destinations for known service hostnames
• Review Java application dependencies to identify usage of vulnerable Bouncy Castle versions (bcprov-jdk*, bctls-jdk*)
• Monitor certificate validation events in application logs for hostname/certificate mismatches

Monitoring Recommendations

• Enable verbose TLS debugging in Java applications (-Djavax.net.debug=ssl) during security assessments to observe hostname verification behavior
• Implement DNS Security Extensions (DNSSEC) validation to reduce DNS poisoning attack surface
• Deploy certificate transparency monitoring for domains your applications connect to
• Use application performance monitoring (APM) tools to track SSL/TLS connection patterns and detect anomalies

How to Mitigate CVE-2024-34447

Immediate Actions Required

• Upgrade Bouncy Castle Java to version 1.78 or later immediately
• For LTS users, upgrade to Bouncy Castle Java (LTS) version 2.73.6 or later
• Upgrade BC TLS Java and BC FIPS TLS Java to version 1.0.19 or later
• Audit Java applications to identify usage of HttpsURLConnection without explicit hostname configuration
• Consider implementing additional certificate pinning for critical connections as defense-in-depth

Patch Information

Bouncy Castle has released patched versions that address this hostname verification issue. The fix ensures that hostname verification is performed against the intended target hostname rather than DNS-resolved IP addresses.

Workarounds

• Explicitly specify hostnames when creating SSL sockets rather than relying on implicit hostname resolution
• Implement custom HostnameVerifier implementations that enforce strict hostname matching
• Consider using alternative TLS providers (such as the default JDK provider) until upgrades can be completed
• Implement certificate pinning for critical external service connections as an additional layer of protection

# Maven dependency update example - upgrade Bouncy Castle to patched version
# Update pom.xml with:
# <dependency>
#     <groupId>org.bouncycastle</groupId>
#     <artifactId>bcprov-jdk18on</artifactId>
#     <version>1.78</version>
# </dependency>
# <dependency>
#     <groupId>org.bouncycastle</groupId>
#     <artifactId>bctls-jdk18on</artifactId>
#     <version>1.78</version>
# </dependency>

# Verify installed Bouncy Castle version in your application
mvn dependency:tree | grep -i bouncycastle

# For Gradle projects, update build.gradle:
# implementation 'org.bouncycastle:bcprov-jdk18on:1.78'
# implementation 'org.bouncycastle:bctls-jdk18on:1.78'