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

Sean Mullan mullan at openjdk.org
Tue Nov 15 22:56:09 UTC 2022


On Tue, 15 Nov 2022 19:07:05 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

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

Which is fine. But we can still cover the behavior of `jdk.tls.disabledAlgorithms` in this one.

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

But I don't think there is general confusion over those other scenarios, so I am wary about going down that path where we feel obligated to document all possible scenarios. People using TLS should already know that a connection may not succeed for various reasons and the SSLException should provide a good reason for that. However, this one is not very visible and could be somewhat surprising.  An application may want to query the `jdk.tls.disabledAlgorithms` property and make sure the protocol is not disabled before creating the `SSLContext`. Although, in practice, we recommend calling `SSLContext.getDefault`.

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

It won't work - see my other reply.

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

Yes, it might be useful to add something like "The returned SSLContext implements the specified protocol version, and may also implement other protocol versions." But I think it could be covered in a separate issue.

The wording in this PR specifically refers to the protocol version that was specified. It isn't covering other optional protocols that may be supported.

I would like to hear from others if they feel this note is useful, or if it is opening up more questions that not.

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

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



More information about the security-dev mailing list