On Tue, 12 Apr 2022 13:38:17 GMT, Claes Redestad <redes...@openjdk.org> wrote:

>> During TLS handshake, hundreds of constraints are evaluated to determine 
>> which cipher suites are usable. Most of the evaluations are performed using 
>> `HandshakeContext#algorithmConstraints` object. By default that object 
>> contains a `SSLAlgorithmConstraints` instance wrapping another 
>> `SSLAlgorithmConstraints` instance. As a result the constraints defined in 
>> `SSLAlgorithmConstraints` are evaluated twice.
>> 
>> This PR improves the default case; if the user-specified constraints are 
>> left at defaults, we use a single `SSLAlgorithmConstraints` instance, and 
>> avoid duplicate checks.
>
> src/java.base/share/classes/sun/security/ssl/SSLAlgorithmConstraints.java 
> line 73:
> 
>> 71: 
>> 72:     static AlgorithmConstraints wrap(AlgorithmConstraints 
>> userSpecifiedConstraints) {
>> 73:         if (userSpecifiedConstraints == DEFAULT) {
> 
> Just thinking out loud: It seems all this does when 
> `userSpecifiedConstraints` is a `SSLAlgorithmConstraints` is force the 
> `enableX509..` flag to `true`. So in addition to the obvious thing for 
> `DEFAULT`, you could also return `DEFAULT` for `DEFAULT_SSL_ONLY`. Or more 
> generally: if `userSpecifiedConstraints instanceof SSLAlgorithmConstraints` 
> then you could either return `userSpecifiedConstraints` as-is if 
> `enabledX509DisabledAlgConstraints` is `true` or else return a clone of it 
> with `enabledX509DisabledAlgConstraints` set to `true`.

While this is technically true, `SSLAlgorithmConstraints` is an internal class, 
so it's very unlikely that we will ever get `SSLAlgorithmConstraints` other 
than `DEFAULT` here.

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

PR: https://git.openjdk.java.net/jdk/pull/8199

Reply via email to