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:

Establish multiple TLS connections with the target
Send carefully crafted RSA-encrypted premaster secrets with intentional padding errors
Measure the response timing for each attempt with high precision
Use statistical analysis to correlate timing variations with specific cryptographic states
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:

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

bash

# 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