CVE-2024-30171: Bouncy Castle TLS Timing Vulnerability

CVE-2024-30171 Overview

CVE-2024-30171 is a timing-based side channel vulnerability discovered in Bouncy Castle Java TLS API and JSSE Provider before version 1.78. The vulnerability exists in RSA-based TLS handshakes where exception processing can leak timing information, potentially enabling attackers to recover sensitive cryptographic material through careful measurement of response times.

Critical Impact

Attackers can exploit timing differences in RSA exception handling during TLS handshakes to potentially recover private key material or decrypt session traffic through side channel analysis.

Affected Products

• Bouncy Castle Java TLS API versions before 1.78
• Bouncy Castle JSSE Provider versions before 1.78
• Bouncy Castle C# implementations (bc-csharp)

Discovery Timeline

• May 14, 2024 - CVE-2024-30171 published to NVD
• November 21, 2024 - Last updated in NVD database

Technical Details for CVE-2024-30171

Vulnerability Analysis

This vulnerability falls under the category of Timing Attack (CWE-203: Observable Discrepancy), a cryptographic side channel vulnerability. The issue stems from non-constant-time exception processing in the RSA decryption path during TLS handshakes. When processing RSA-encrypted premaster secrets, the Bouncy Castle library exhibits measurable timing differences based on the validity of the padding or other cryptographic operations.

Timing attacks against RSA implementations have a long history, with the most notable being the Bleichenbacher attack and its variants. CVE-2024-30171 represents a similar class of vulnerability where an attacker positioned on the network can send malformed ciphertext and measure response times to gradually recover the plaintext or private key information.

The attack requires network access and involves high complexity as the attacker must be able to accurately measure timing differences and send multiple carefully crafted requests. While no user interaction is required, the confidentiality impact is significant as successful exploitation could compromise encrypted communications.

Root Cause

The root cause lies in the exception handling logic within Bouncy Castle's RSA decryption implementation used during TLS handshakes. When processing RSA PKCS#1 v1.5 padding or similar operations, different error conditions trigger different code paths with varying execution times. These timing discrepancies, though potentially small, can be measured and exploited by an attacker capable of performing many handshake attempts.

Proper cryptographic implementations must ensure constant-time execution regardless of input validity to prevent timing-based information leakage. The vulnerable versions of Bouncy Castle failed to adequately mask these timing differences during exception processing.

Attack Vector

The attack vector is network-based, requiring the attacker to be able to initiate or intercept TLS handshakes with a vulnerable server or client using Bouncy Castle. The attacker would typically:

1. Establish multiple TLS connections with the target
2. Send carefully crafted RSA-encrypted premaster secrets with intentional padding errors
3. Measure the response timing for each attempt with high precision
4. Use statistical analysis to correlate timing variations with specific cryptographic states
5. Gradually recover the private key material or decrypt captured session traffic

This type of attack is particularly concerning for long-term exposure as attackers can passively collect encrypted traffic and later perform the timing attack to recover session keys.

Detection Methods for CVE-2024-30171

Indicators of Compromise

• Unusually high volume of failed TLS handshakes from specific source IPs
• Repeated connection attempts with malformed RSA ciphertext in ClientKeyExchange messages
• Pattern of connections with precise timing intervals suggesting automated attack tooling
• TLS error logs showing RSA decryption failures at rates above normal baseline

Detection Strategies

• Implement TLS handshake failure rate monitoring and alerting for anomalous patterns
• Deploy network intrusion detection systems with signatures for Bleichenbacher-style attack patterns
• Monitor Java application logs for Bouncy Castle exception traces related to RSA operations
• Use packet capture analysis to identify suspicious patterns in TLS handshake timing

Monitoring Recommendations

• Establish baseline metrics for TLS handshake failure rates and timing distributions
• Configure SIEM rules to correlate multiple failed handshakes from single sources
• Enable verbose logging for TLS operations during incident investigation periods
• Monitor for reconnaissance activity targeting TLS endpoints

How to Mitigate CVE-2024-30171

Immediate Actions Required

• Upgrade Bouncy Castle Java library to version 1.78 or later immediately
• Audit all applications and dependencies for Bouncy Castle usage
• Consider disabling RSA key exchange in favor of ECDHE where possible
• Review TLS configurations to ensure modern cipher suites are prioritized

Patch Information

The vulnerability has been addressed in Bouncy Castle version 1.78. Organizations should update their dependencies as follows:

For Maven-based projects, update your pom.xml to reference bcprov-jdk18on:1.78 or later. For Gradle projects, update the dependency declaration accordingly. The Bouncy Castle Latest Releases page provides the current versions and download links.

Additional vendor advisories are available:

• GitHub CVE-2024-30171 Wiki (Java)
• GitHub CVE-2024-30171 Wiki (C#)
• NetApp Security Advisory NTAP-20240614-0008

Workarounds

• Disable RSA-based key exchange cipher suites in TLS configuration where feasible
• Prefer ECDHE-based cipher suites which are not affected by this vulnerability
• Implement network-level rate limiting for TLS handshake attempts
• Use TLS 1.3 exclusively where possible, as it removes RSA key exchange entirely

# Example: Configuring Java TLS to prefer ECDHE cipher suites
# Add to JVM startup options or security.properties
# Disable RSA key exchange cipher suites as a workaround
jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
    DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
    TLS_RSA_WITH_AES_256_CBC_SHA256, TLS_RSA_WITH_AES_256_CBC_SHA, \
    TLS_RSA_WITH_AES_128_CBC_SHA256, TLS_RSA_WITH_AES_128_CBC_SHA