On Thu, 16 Jul 2026 15:06:31 GMT, Artur Barashev <[email protected]> wrote:
>> Improve the definition of the jdk.tls.disabledAlgorithm security property to >> specify how components of the cipher suite can be disabled. This has never >> been clearly specified. >> >> --------- >> - [x] I confirm that I make this contribution in accordance with the >> [OpenJDK Interim AI Policy](https://openjdk.org/legal/ai). > > src/java.base/share/conf/security/java.security line 749: > >> 747: # the key exchange algorithm "ECDH_ECDSA" will disable all cipher >> suites >> 748: # that contain ECDH_ECDSA as the key exchange algorithm. Similarly, >> the >> 749: # bulk encryption algorithm "3DES_EDE_CBC" will disable all cipher >> suites > > - `3DES_EDE_CBC` is already disabled by default in > `jdk.tls.disabledAlgorithms`, should we use a more realistic example like > `AES_128_CBC`? > - Should we also include an example for `HmacSHA256`? It's far from being > obvious that such algorithm disables all cipher suites anding with `_SHA256`. The reason I chose 3DES_EDE_CBC is because it is a case where one can see already that we have implemented something that is not specified. But I'm not tied to it, I can switch it to AES_128_CBC. As for HmacSHA256 disabling cipher suites with SHA256 as the Mac in the name, I agree that is not obvious. Let me think about it as it is a bit awkward to document. It's a corner case but might be useful where you want to disable a Mac but not the algorithm if used as the hash algorithm in other places, like certificate signatures. ------------- PR Review Comment: https://git.openjdk.org/jdk/pull/31933#discussion_r3596735664
