We get the call SSLContext.getInstance("TLS") reported as vulnerability. The recommended fix is to use SSLContext.getInstance("TLSv1.2").
I learnt that TLSv1.1 and TLSv1 are disabled anyway since April 2021 in Java implementations, but when I experimented with this fix, I found out that this will disable TLSv1.3 (even if I add it via sslSocket.setEnabledProtocols(protocols)).
When I use SSLContext.getInstance("TLSv1.3"), sslSocket.getEnabledProtocols() returns both TLSv1.3 and TLSv1.2 and if the server side only supports TLSv1.2, a connection is established.
This is unexpected to me. For me, this would be an "algorithm downgrade".
Documentation says only "may support other SSL/TLS versions", so when I specify "TLSv1.3", I cannot expect that fallback to "TLSv1.2" works, right?
Although it looks like the SSLContext.getInstance parameter is the highest supported TLS version.
So what is the right way to implement an SSL connection were the server side may support either TLSv1.2 or TSLv1.3 or both (and don't get a vulnerability reported)?
Regards, Andreas
CodePudding user response：
You don't say which vulnerability checker you are using, but the report matches this:
Assuming so, you should also read this Sonar bug report:
It makes the point that the argument in a SSLContext.getInstance(...) does not constrain the TLS version that is used. Thus, the vulnerability report is a false positive. Feel free to make the false positive "go away" by using a different value. But be aware you are NOT addressing the potential / real vulnerability.
To properly constrain the SSL/TLS versions used for a specific connection, you can configure the SSLEngine object:
serverEngine = serverSslContext.createSSLEngine();
serverEngine.setEnabledProtocols(new String[] { "TLSv1.2", "TLSv1.3" });
Alternatively, you can constrain this JVM-wide by setting JVM properties on the command line:
java -Dhttps.protocols="TLSv1.2,TLSv1.3" \
-Djdk.tls.client.protocols="TLSv1.2,TLSv1.3" <MyApp>
Reference: