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.

If it will be addressed in the future issue, the current specification may need to weight the impact in.  Otherwise, the specification added here might need to re-work to cover more cases.

> Also, most of those other cases above (except for #4) are influenced by additional methods subsequently invoked by the application. 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. The JCK team requested this clarification.

I understand the concerns.  There are many cases in security components that an instance could return, but will not work in the following process if not set or configured properly.   The impact of disabled properties is just one case of many.  Maybe, a simple description is sufficient, "the instance may not work if not configured or set properly, for example ... ".

It may be not an option to stop at SSLContext.getInstance() if the protocol is disabled rather than delay to handshaking, as  an application still can have the protocol back by overriding the default security properties.

BTW, the protocol for SSLContext.getInstance() method is not a TLS protocol.  It is more of a context-algorithm.  For example, SSLContext.getInstance("TLSv1.3") could support TLS 1.0/1.1/1.2/1.3.  It may be not usual, but if TLS 1.3 is disabled, and TLS 1.2 not, the connection should be able to established with TLS 1.2.  In the description, it would be nice to make it clean what the 'protocol" means in different circumstances.

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

PR: https://git.openjdk.org/jdk/pull/11172