CVE-2024-30171

What it actually does

Bouncy Castle Java TLS API and JSSE Provider versions before 1.78 can leak information during RSA-based TLS handshakes through timing differences caused by exception processing. A remote unauthenticated attacker who can repeatedly initiate or observe affected RSA handshakes may be able to distinguish subtle processing differences and use them as a side channel against RSA key material or encrypted handshake secrets. The flaw affects confidentiality only; it does not directly allow code execution, authentication bypass, or service disruption. Exploitation is high-complexity because it requires precise timing measurement, many handshake attempts, favorable network conditions, and use of vulnerable RSA-based TLS handshake behavior.

Why it matters to the business

Systems using vulnerable Bouncy Castle TLS or JSSE components for RSA-based TLS handshakes may expose encrypted communications or cryptographic secrets to a sophisticated attacker. The practical risk is lower than many remotely reachable vulnerabilities because exploitation is difficult and there is no known public exploitation or CISA KEV listing, but organizations relying on Bouncy Castle in internet-facing Java services, embedded products, middleware, or compliance-sensitive encryption paths should treat this as a confidentiality risk and upgrade during normal security patch cycles.

How an attack unfolds

An attacker identifies a Java application, service, appliance, or library stack that uses the Bouncy Castle Java TLS API or Bouncy Castle JSSE Provider before version 1.78 and supports RSA-based TLS handshakes. The attacker repeatedly initiates TLS handshakes or positions themselves to measure handshake behavior. Because vulnerable versions handle certain RSA handshake exceptions in a way that creates timing differences, the attacker collects a large number of timing samples and statistically analyzes them to infer information about cryptographic processing. If conditions are favorable, the timing signal may reveal sensitive information associated with RSA-based TLS operations. This attack does not normally produce a clear application error or obvious compromise artifact, and it is most feasible for well-resourced attackers with reliable network proximity or the ability to generate many handshake attempts.

How to fix it

Upgrade Bouncy Castle Java TLS API and JSSE Provider to version 1.78 or later. In Java dependency managers, update Bouncy Castle artifacts such as bctls, bcprov, bcpkix, and related provider packages to a fixed release line where applicable, ensuring no older transitive dependency remains packaged in the final application. Rebuild and redeploy applications, services, containers, and appliances that embed vulnerable Bouncy Castle JARs. Where immediate upgrade is not possible, reduce exposure by disabling RSA key exchange and legacy RSA-based TLS handshakes, preferring TLS 1.2/1.3 configurations that use ECDHE/DHE key exchange and modern cipher suites. Remove obsolete cipher suites, restrict access to affected TLS endpoints, and place sensitive services behind controlled network paths until patched.

How to confirm the fix worked

Confirm all deployed Bouncy Castle components report version 1.78 or later, including application dependencies, shaded JARs, container images, bundled vendor components, and embedded runtime distributions. Use software composition analysis, dependency tree review, and filesystem searches for Bouncy Castle JAR manifests. Validate TLS configuration with tools such as testssl.sh, nmap ssl-enum-ciphers, or equivalent scanners to ensure RSA key exchange and legacy RSA-based handshakes are disabled where feasible. After upgrade, confirm the runtime classpath loads the fixed Bouncy Castle version and not an older copy earlier in the classpath. For packaged products, verify vendor advisories and fixed firmware/software releases rather than relying only on top-level application version strings.

Typical attack path

1. Identify a target service, product, or Java application using Bouncy Castle TLS API or JSSE Provider before version 1.78.
2. Confirm that RSA-based TLS handshakes or RSA key exchange behavior are enabled or reachable.
3. Generate or observe many TLS handshake attempts while precisely measuring response timing.
4. Trigger handshake paths that exercise vulnerable RSA exception processing behavior.
5. Perform statistical analysis on timing differences to distinguish cryptographic processing outcomes.
6. Use the recovered side-channel information to weaken confidentiality of RSA-based TLS communications or related secret material.

How to detect it

There are no reliable exploit-specific indicators for this vulnerability because timing side-channel attacks may look like normal TLS handshakes and typically do not create distinctive application logs, files, processes, or error messages. To investigate possible prior exploitation, review TLS termination logs, load balancer logs, reverse proxy logs, Java application logs, packet captures, NetFlow, and firewall records for unusually high volumes of short-lived TLS handshakes, repeated handshake failures, or repeated connections to the same TLS service from a limited set of source IPs over sustained periods. Look for activity targeting endpoints that used Bouncy Castle before 1.78 and allowed RSA-based TLS handshakes. If packet capture is available, analyze cipher suite negotiation attempts and repeated RSA-based handshake patterns. Correlate suspicious handshake bursts with external scanning, failed TLS alerts, and source infrastructure reputation. Absence of logs or visible errors does not rule out exploitation, so detection should be supplemented with exposure assessment and dependency validation.

What your security team should do

• Inventory Java applications, services, containers, and vendor products that include Bouncy Castle TLS or JSSE components.
• Prioritize internet-facing, partner-facing, payment, identity, VPN, API gateway, and compliance-sensitive systems that terminate or initiate TLS using Java.
• Upgrade Bouncy Castle dependencies to version 1.78 or later and rebuild artifacts to remove vulnerable transitive or shaded copies.
• Disable RSA key exchange and legacy TLS cipher suites where operationally possible, favoring TLS 1.2/1.3 with forward-secret key exchange.
• Run software composition analysis across source repositories, build artifacts, container images, and runtime hosts to identify embedded vulnerable JARs.
• Ask vendors of Java-based appliances or applications whether they bundle affected Bouncy Castle versions and obtain patched releases.
• Monitor for abnormal volumes of failed or repeated TLS handshakes against services using Bouncy Castle, especially from a small set of source addresses.
• Because exploitation leaves few direct artifacts, treat patch verification and cryptographic configuration hardening as the primary control.