On Tue, 15 Nov 2022 18:37:50 GMT, Sean Mullan <mul...@openjdk.org> wrote:
> > As you are already there, it may be nice to cover more options that the > > protocol may not be used for the handshaking. Here are some cases I'm aware > > of: > > > > 1. the protocol is disabled with Security property > > 2. the protocol is not set while setting the SSLParameters > > 3. the protocol is not set while set the enabled protocol > > 4. the protocol is not supported by the peer > > 5. the protocol is not supported by any cipher suites enabled. > > Good point, but I feel that should be handled in a separate issue, if > necessary. Also, most of those other cases above (except for #4) are > influenced by additional methods subsequently invoked by the application. I think it twice. It may be not necessary to invoke additional methods subsequently by the application. The impact could be configurations (security properties, key store, etc) other than `jdk.tls.disabledAlgorithms`. > For this one, it may be a bit surprising for the SSLContext to be returned > when the protocol is disabled (although it is still compliant with the API as > specified), and then later it doesn't work, so the implementation note is > useful. If the purpose is to make sure an SSLContext instance work later, more options may be considered. IMO, I did not see the value if we cannot make the description in a general and accuracy way. The "jdk.tls.disabledAlgorithms" is just one of many impacts. All jdk.xxx.disabledAlgorithms properties could play a role to break the connection. It may be not enough to check the "jdk.tls.disabledAlgorithms" and than can make sure an SSLContext instance will work for sure. ------------- PR: https://git.openjdk.org/jdk/pull/11172
