RFR: 8202343: Disable TLS 1.0 and 1.1

Sean Mullan mullan at openjdk.java.net
Tue Nov 17 15:36:10 UTC 2020


On Mon, 16 Nov 2020 22:02:05 GMT, Xue-Lei Andrew Fan <xuelei at openjdk.org> wrote:

>> This change disables the TLSv1 and TLSv1.1 protocols by adding them to the jdk.tls.disabledAlgorithms security property in the java.security file. These protocols use weak algorithms and are being deprecated by the IETF. They should be disabled by default to improve the default security configuration of the JDK. See the CSR for more rationale: https://bugs.openjdk.java.net/browse/JDK-8254713
>> 
>> The fix mostly involves changes to existing tests that for one reason or another depend on the TLSv1 and TLSv1.1 protocols being enabled. There is a new test specifically for this issue: test/jdk/sun/security/ssl/SSLContextImpl/SSLContextDefault.java
>
> test/jdk/javax/net/ssl/sanity/ciphersuites/TLSCipherSuitesOrder.java line 76:
> 
>> 74:         if (protocol.equals("TLSv1") || protocol.equals("TLSv1.1")) {
>> 75:             SecurityUtils.removeFromDisabledTlsAlgs(protocol);
>> 76:         }
> 
> There are several property updates in method other than the main() method.  It should be fine as the constructor is private.  It is safer to make the update in the main() method as the property is loaded one time only in JVM.

I think it is safe to set the property in the constructor because the test always runs in its own VM using the jtreg `othervm` option and there are no methods called by main before the constructor that would cause the value of "jdk.tls.disabledAlgorithms" to be fetched and cached. Let me know if you think otherwise.

> test/jdk/sun/security/ssl/EngineArgs/DebugReportsOneExtraByte.java line 150:
> 
>> 148:         // Re-enable TLSv1 since test depends on it
>> 149:         SecurityUtils.removeFromDisabledTlsAlgs("TLSv1");
>> 150: 
> 
> I would like move this block to the main() method for safe, or have this method private.

Ok.

-------------

PR: https://git.openjdk.java.net/jdk/pull/1235



More information about the security-dev mailing list