Info about CVE-2024-34447

[samueloph]

Hello,

I'm trying to find the commit that fixed CVE-2024-34447: When endpoint identification is enabled in the BCJSSE and an SSL socket is not created with an explicit hostname (as happens with HttpsURLConnection), hostname verification could be performed against a DNS-resolved IP address., it looks like it's this one but I wanted to confirm: c47f644

The website could also be updated to mention the CVE ID now: https://www.bouncycastle.org/latest_releases.html

CVE-2024-"TBD" - When endpoint identification is enabled in the BCJSSE and an SSL socket is not created with an explicit hostname (as happens with HttpsURLConnection), hostname verification could be performed against a DNS-resolved IP address. This has been fixed (we are still waiting on a CVE ID).

The ultimate goal is to find out what is the first affected version, for Linux distros that ship older releases to know whether they are affected or not. So in case you already did this check yourself, could you share this information, please? Otherwise I can check previous versions myself once I confirm what's the fixing commit ID.

Regards

[peterdettman]

Yes, c47f644 is the correct commit. I have compiled a brief history of the issue as follows:

The BCJSSE provider was added in 1.56. Initially it did not support endpoint identification (indeed it silently ignored that field in SSLParameters, which could be surprising in a bad way).

Support for endpoint identification was added in 1.61. Essentially the issues around incorrectly trusting DNS have been present ever since. "jdk.tls.trustNameService" system property was always supported, but is not often a useable/useful workaround. The best solution would normally be to use a custom SSLSocketFactory.

In 1.69 we added some utility classes to make that workaround easier to use:

• org.bouncycastle.jsse.util.SNISocketFactory
• org.bouncycastle.jsse.util.URLConnectionUtil (simple replacement for URL.openConnection("https://...") use cases)

Unfortunately these classes missed a case since SNI verification could still fall back to checking a DNS-resolved IP address.

1.70 added a BCJSSE-specific system property "org.bouncycastle.jsse.client.assumeOriginalHostName", but this again has limited usefulness.

Now 1.78 has ensured that things will fail by default without a workaround in place. We also added a better utility:

• org.bouncycastle.jsse.util.SetHostSocketFactory (also now used by URLConnectionUtil)

SetHostSocketFactory is a much tidier solution and would in fact work correctly all the way back to the original endpoint ID support in 1.61 (though users would have to supply their own copy of course).

[samueloph]

Awesome, thank you very much for the write-up @peterdettman