If you use Java for SSL communication, chances are you've bumped into Bouncy Castle, a popular library for cryptographic functions. But until version 1.78, Bouncy Castle’s Java APIs were quietly vulnerable to DNS poisoning attacks, thanks to a subtle slip in how they handled endpoint identification. This bug is tracked as CVE-2024-34447.

In this deep dive, I’ll explain what the problem was, how it can be exploited, and show real code snippets. If you’re running an affected version, you’ll want to fix this right away.

What’s CVE-2024-34447?

Summary:
Bouncy Castle Java Cryptography APIs (before 1.78) could perform SSL certificate hostname verification against an _IP address_ (from DNS), not the expected hostname, when endpoint identification is enabled and no explicit hostname is provided. This mostly surfaces with app code using Java’s HttpsURLConnection with BCJSSE as the provider.

What’s the Risk?

If an attacker can poison the DNS lookup—controlling the IP returned for a trusted hostname—they can get the certificate check to match their own server's cert (with that IP as a subjectAltName entry), bypassing the actual hostname. This cracks open the door to MITM (Man-in-the-Middle) attacks.

The root is in how endpoint identification is applied when establishing an SSL socket

- When you use HttpsURLConnection without an explicit hostname, the verification falls back to the DNS-resolved IP, not the hostname.
- If that IP is spoofed (DNS poisoning), a malicious party can slip in a valid certificate for their _IP address_, and BCJSSE happily trusts it.

Suppose you fetch data from https://secure.mybank.com

import javax.net.ssl.HttpsURLConnection;
import java.net.URL;

public class VulnerableFetch {
    public static void main(String[] args) throws Exception {
        URL url = new URL("https://secure.mybank.com/data");
        HttpsURLConnection conn = (HttpsURLConnection) url.openConnection();
        conn.connect();
        // Read data...
    }
}

If you’re using BCJSSE as the JSSE provider (often configured via Security.insertProviderAt(...)), the library establishes an SSL socket, but doesn't explicitly remember the hostname intended (secure.mybank.com). It relies on the resolved IP from DNS, even for certificate checks.

The Tricky Part

If an attacker poisons your DNS (controls the IP for secure.mybank.com), and serves up an SSL certificate valid _for that IP_ (but not for the actual hostname), BCJSSE (pre-1.78) will incorrectly trust it.

Exploiting the Flaw: Step-by-Step

1. Poison DNS: Attacker makes your client believe secure.mybank.com points to their server (e.g., via local rogue DNS or ARP spoofing).
2. Malicious Certificate: Attacker’s server presents a certificate valid for the IP address, _not_ for secure.mybank.com.
3. BCJSSE Connection: When your Java code runs with Bouncy Castle < 1.78, the SSL session verifies the cert subjectAltName against the IP returned, not the real hostname.

Edit your /etc/hosts or Windows hosts file

127...66   secure.mybank.com

Step 2: Set up a test HTTPS server at 127...66 with a cert _for that IP only_

openssl req -nodes -new -x509 -keyout key.pem -out cert.pem \
    -subj "/CN=127...66" \
    -addext "subjectAltName=IP:127...66"

Official Fix

- Upgrade to Bouncy Castle 1.78 or newer
- The bug is fixed: BCJSSE now ties the endpoint identification _to the intended hostname_, not just the resolved IP.

- CVE-2024-34447 NVD page
- Bouncy Castle release notes
- Bouncy Castle Java security provider info
- MitM attacks explained (Wikipedia)

Final Thoughts

This is a classic example of how tiny details in cryptographic APIs create major risks, especially when standard Java patterns (like HttpsURLConnection) are involved. If your Java apps use Bouncy Castle for SSL/TLS, upgrade now and check for this pattern in your code. Don’t let an attacker sneak through the backdoor using something as old-fashioned as a DNS trick.

Stay patched, stay safe!

If you found this useful, bookmark, share, and subscribe for more explainers on real-world Java security gotchas.

Timeline

Published on: 05/03/2024 16:15:11 UTC
Last modified on: 03/20/2025 20:15:32 UTC