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.
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
