On Thu, 7 Nov 2024 22:13:04 GMT, Artur Barashev <abaras...@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
