RFR: 8341964: Add mechanism to disable different parts of TLS cipher suite [v5]

David Schlosnagle duke at openjdk.org
Fri Nov 8 02:15:55 UTC 2024


On Thu, 7 Nov 2024 22:13:04 GMT, Artur Barashev <abarashev at openjdk.org> wrote:

>> The current syntax of the jdk.tls.disabledAlgorithms makes it difficult to disable algorithms that affect both the key exchange and authentication parts of a TLS cipher suite. For example, if you add "RSA" to the jdk.tls.disabledAlgorithms security property, it disables all cipher suites that use RSA, whether it is for key exchange or authentication. If you only want to disable cipher suites that use RSA for key exchange, the only workaround is to list the whole cipher suite name, so an exact match is done, but if there are many cipher suites that use that key exchange algorithm, this becomes cumbersome.
>
> Artur Barashev has updated the pull request with a new target base due to a merge or a rebase. The incremental webrev excludes the unrelated changes brought in by the merge/rebase. The pull request contains 25 additional commits since the last revision:
> 
>  - Use atomic computeIfAbsent. Add more cipher suites to test.
>  - Merge branch 'master' into JDK-8341964_regex
>  - - Cache the patterns
>    - Make matching case-sensitive
>    - Update java.security documentation
>    - Refactor the tests
>  - "Cipher suites must start with TLS_" doc update
>  - Update doc
>  - Update the doc
>  - DisabledAlgorithmConstraints already caches the results of checkAlgorithm call
>  - Add cache of the wildcard matching results
>  - Make matching case-insensitive. Compact the code.
>  - 8341964: Add mechanism to disable different parts of TLS cipher suite
>  - ... and 15 more: https://git.openjdk.org/jdk/compare/1b74ebf7...98753b23

Had a couple questions about whether this needs to validate & sanitize any regex patterns in the inputs. https://github.com/openjdk/jdk/pull/21911 also seems to be addressing this in a more robust and expressive manner -- is the intent to support both mechanisms?

src/java.base/share/classes/sun/security/util/AbstractAlgorithmConstraints.java line 127:

> 125:             return patternCache.computeIfAbsent(
> 126:                             pattern,
> 127:                             p -> Pattern.compile(p.replace("*", ".*")))

Do we care if one uses other regex matching characters as part of the pattern input, e.g. should `TLS_[a-zA-Z0-9_]+` be a valid input that disables some algorithms?

Should the matching be case insensitive?

-------------

PR Review: https://git.openjdk.org/jdk/pull/21841#pullrequestreview-2422415237
PR Review Comment: https://git.openjdk.org/jdk/pull/21841#discussion_r1833534796


More information about the security-dev mailing list