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
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, i.e. 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.