JDK-8219537 : Add TLS 1.0 and 1.1 to the jdk.tls.legacyAlgorithms security property
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 10,11,12,13
  • Priority: P3
  • Status: Resolved
  • Resolution: Won't Fix
  • Submitted: 2019-02-21
  • Updated: 2019-03-04
  • Resolved: 2019-03-04
Related Reports
Blocks :  
Description
Add "tlsv1" and "tlsv1.1" to the jdk.tls.legacyAlgorithms security property. These versions of the TLS protocol are not as strong as TLS 1.2 and 1.3 and should be not be negotiated if there is a stronger protocol that both client and server support.

This restriction depends on support for the "supported_versions" extension. This extension is currently supported in JDK 10 for TLS 1.2, and in JDK 11 it is supported for TLS 1.0, 1.1, 1.2, and 1.3. 

As background, TLS client lists the versions it supports in the supported_versions extension in preference order. A TLS server selects one that it also supports from the list. For security reasons, the JDK TLS server implementation doesn't necessarily use the client's preferred order, instead it bases it selection on its own preferred order. 

By default (i.e. no configuration changes) a Java client and server order the versions in the most secure order: "TLSv1.3, TLSv1.2, TLSv1.1, TLSv1".  However, if a client or server reconfigures this order, then a less secure version of the protocol may be used. This could happen accidentally, if the administrator unintentionally ordered weaker protocols before stronger ones.

To sum up, adding TLS 1.1 and 1.0 to the jdk.tls.legacyAlgorithms property has a benefit under the following circumstances: 

1. A JDK TLS server's enabled protocols have been explicitly configured (using the setEnabledProtocols API or jdk.tls.server.cipherSuites system property) to use a different order, either intentionally or accidentally such that a weaker protocol (1.1 or 1.0) is preferred. In this case, the weaker protocols would be moved to the end of the list. 

2. A JDK TLS client's enabled protocols have been explicitly configured (using the setEnabledProtocols API or jdk.tls.client.cipherSuites system property) to use a different order, either intentionally or accidentally such that a weaker protocol (1.1 or 1.0) is preferred. A non-JDK TLS Server implementation may respect the client's order and choose the weaker protocol (it is not known if any other TLS implementations do that, however). Thus, we should reorder the protocols such that TLS 1.1 and 1.0 is last.
Comments
I did some prototyping for this issue and I discovered that the code already sorts the protocols by default in HandshakeContext.getActiveProtocols: if (!protocols.isEmpty()) { if (enabledSSL20Hello) { protocols.add(ProtocolVersion.SSL20Hello); } Collections.sort(protocols); } Since ProtocolVersion is an enum it sorts it by the enum order: enum ProtocolVersion { TLS13 (0x0304, "TLSv1.3", false), TLS12 (0x0303, "TLSv1.2", false), TLS11 (0x0302, "TLSv1.1", false), TLS10 (0x0301, "TLSv1", false), SSL30 (0x0300, "SSLv3", false), SSL20Hello (0x0002, "SSLv2Hello", false), So even if a user configures different protocols or changes the order, it will always get sorted again such that the strongest protocols are tried first. Conclusion: Adding these to the legacyAlgorithms property does not have any value.
04-03-2019