RFR: 8296820: Add implementation note to SSLContext.getInstance noting subsequent behavior if protocol is disabled

[Xue-Lei Andrew Fan]

On Tue, 15 Nov 2022 18:37:50 GMT, Sean Mullan <mullan at 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