JDK-8209318 : Disable all DES cipher suites
  • Type: CSR
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Priority: P3
  • Status: Closed
  • Resolution: Approved
  • Fix Versions: 12
  • Submitted: 2018-08-09
  • Updated: 2018-08-20
  • Resolved: 2018-08-20
Related Reports
CSR :  
DES-based TLS cipher suites should be disabled.  They are currently available but not enabled by default.  To use them they must be explicitly enabled by an application, for example, by calling `SSLSocket.setEnabledCipherSuites`.  Due to the age and insecurity of 56-bit DES, these cipher suites should no longer be available without additional intervention by the user or administrator through the `jdk.tls.disabledAlgorithms` Security property.

The DES algorithm has been deemed weak by the cryptographic community for a long time.  We previously added export-grade 40-bit DES suites to the disabled algorithms property, but not the standard 56-bit DES.  The DES algorithm only gets relatively more weak over time and needs to be disabled in its entirety.  Administrators can still take action to reenable it for legacy use if needed.

The proposed solution would be to replace the DES40_CBC identifier in the `jdk.tls.disabledAlgorithms` System property found in the `java.security` file with the identifier "DES"  This identifier will encompass both the 40-bit and 56-bit cipher suite variants.  Also to simplify things we propose removing RC4_40 since it is similarly encompassed by the RC4 identifier which is in the current property string.

While there are no API changes there is a behavioral change.  Formerly non-export DES-based cipher suites could be explicitly added (e.g. by calling `SSLSocket.setEnabledCipherSuites`) and allow clients to assert support for these suites.  On the server side, servers could negotiate these suites if explicitly added.  This is no longer the case.  The suite names can still be added, but will not show up in ClientHello messages or be negotiated by the server.  If only disabled suites are provided, `SSLHandshakeException` will be thrown upon generation of ClientHello messages.  This is an extremely rare case given most TLS libraries do not enable these suites in their products.  Administrators may re-enable these suites by removing the "DES" identifier in the `jdk.tls.disabledAlgorithms` property in the `java.security` file.

The proposed change in `java.security` is as follows:

diff -r aa3bfacc912c src/java.base/share/conf/security/java.security
--- a/src/java.base/share/conf/security/java.security
+++ b/src/java.base/share/conf/security/java.security
@@ -675,8 +675,8 @@
 # Example:
 #   jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048
-jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize < 1024, \
-    EC keySize < 224, DES40_CBC, RC4_40, 3DES_EDE_CBC
+jdk.tls.disabledAlgorithms=SSLv3, RC4, DES, MD5withRSA, DH keySize < 1024, \
+    EC keySize < 224, 3DES_EDE_CBC
 # Legacy algorithms for Secure Socket Layer/Transport Layer Security (SSL/TLS)

Moving to Approved. I note a release note is already planned for this change, which is appropriate given the behavioral compatibility impact.

I've changed the fix version to 12 only. Backports will probably be done for 11, 10, 8 and 7.

Please correct the "Fix Version/s:" field on the CSR and the parent bug; there should only be a single value in the field. Which releases is this change being proposed for? In the mean time, moving to Provisional. Please plan for a release note before the CSR is finalized.