3

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

Andreas Mueller
  • 201
  • 4
  • 13
  • (Assuming JSSE) getInstance(1.2) sets protocols _and ciphersuites_ for 1.2 (and lower if you undisable them); if I both setEnabledProtocols to add 1.3 _and_ setEnabledCipherSuites to add all or some 1.3 _suites_ it works. But hardcoding current 1.3 suites isn't robust if new ones are developed, nor do you want to enable all supported suites because some older ones are bad, so this approach is kind of ugly. getInstance(1.3) _in JSSE_ does support 1.2 (and lower if undisabled) even though not documented and thus not 'guaranteed'. – dave_thompson_085 Oct 14 '21 at 20:29

1 Answers1

4

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:

Stephen C
  • 698,415
  • 94
  • 811
  • 1,216
  • We use Veracode but I also found the Sonar comment you mentioned above. We already restrict the versions with setEnabledProtocols. – Andreas Mueller Oct 14 '21 at 16:05
  • https.protocols only controls HttpsURLConnection (though the Oracle page isn't as clear as it should be). jdk.tls.client.protocols is a _default_ (which currently doesn't change anything) but not a constraint. OP is using socket not engine, and 'v2' and 'v3' are wrong. – dave_thompson_085 Oct 14 '21 at 20:33