Java Bouncy Castle TLS 协议版本顺序？

Question

I'm using the Java Bouncy Castle TLS library (bctls-jdk15to18-1.68.jar). When I call SSLContext.getInstance , I specify "TLS" and the BCJSSE provider:

final SSLContext context    =   SSLContext.getInstance("TLS",BCJSSE);
                 context.init(kmf.getKeyManagers(), tmf.getTrustManagers(), keyStoreSalter);
logger.debug(Arrays.toString(context.getSupportedSSLParameters().getProtocols()));

When I query the SupportedSSLParameters of the context, it returns: [TLSv1.3, TLSv1.2, TLSv1.1, TLSv1, SSLv3]

As the client, are all of these versions communicated to the server, and the server chooses the highest that it supports?

If I denote a specific version SSLContext.getInstance("TLSv1.3",BCJSSE); and the server does not support that version is an exception thrown?

I'm trying to determine why you would ever specify a version in your call, if the negotiation will automagically determine the best match.

EDIT: Added so this is attached: Perfect test site for TLS/SSL

Answer 1

As the client, are all of these versions communicated to the server, and the server chooses the highest that it supports?

The client simply tells which versions are supported (TLS 1.3 supported_versions extension) or announces the best it can do (TLS 1.2 and lower). The server then simply picks the highest protocol version which is supported by both client and server.

If I denote a specific version SSLContext.getInstance("TLSv1.3",BCJSSE); and the server does not support that version is an exception thrown?

If there is no common protocol version supported by both client and server then the handshake will fail and an exception thrown.

I'm trying to determine why you would ever specify a version in your call, if the negotiation will automagically determine the best match.

This will usually only be done if there is a requirement to not support versions below a specific one, ie support only TLS 1.2 and higher. Since TLS 1.0 is considered too weak already in some situations, this can be a real-world requirement.

Answer 2

"Supported" in the context of the JSSE API means that it is supported by this JSSE implementation and thus COULD be enabled, but NOT that it is enabled by default. If you want to see the actual protocols enabled on a new SSLSocket or SSLEngine , call the getEnabledProtocols method on it.

You can then experiment with which of the "supported" protocols are actually auto-enabled depending on the algorithm you used to construct the SSLContext . Notably specifying just "TLS" will not automatically enable TLSv1.3 in v1.68 (since it's the first release to support TLSv1.3 and we are being cautious). Also SSLv3 is never automatically enabled.

Regardless of how you created the SSLContext , the enabled protocols can then be modified either through SSLSocket/SSLEngine.setEnabledProtocols , or through SSLParameters.setProtocols .

All of the ENABLED protocols are communicated to the server, and the server chooses the highest that it supports. (Roughly speaking; some servers may negotiate the cipher suite first, and then check for a suitable protocol version).

You should configure your socket with all the versions you want to support and just try one call. It is not advisable to try one version at a time since it may expose you to a downgrade attack .