Java

Test or Revert changes to Oracle's JDK and JRE Cryptographic Algorithms

This page contains instructions for testing and/or reverting changes to Oracle's JDK and JRE announced on the Oracle JRE and JDK Cryptographic Roadmap

Reverting changes is not recommended.  Instructions for reverting changes are provided as a temporary workaround, in controlled environments, until the system can be updated to comply with the new security standards.


Configuring Unlimited Cryptographic Policy

Due to import control restrictions of some countries, the version of the JCE policy files bundled in the Java Runtime Environment 8, 7, and 6 allow strong but limited cryptography.  In order to remove restrictions on cryptography one must download and apply the JCE Unlimited Strength Jurisdiction Policy Files for the corresponding release.

YOU ARE ADVISED TO CONSULT YOUR EXPORT/IMPORT CONTROL COUNSEL OR ATTORNEY TO DETERMINE YOUR COUNTRY'S EXACT REQUIREMENTS. If your country has restrictions that don't fit either "limited" or "unlimited", an appropriate set of policy files should be created and configured before using this distribution.  The jurisdiction policy file configuration must reflect the cryptographic restrictions appropriate for your country.

Use the following links to find the Unlimited Strength Policy Files for JDK 8, 7, and 6.

After downloading the Unlimited Strength Policy Files unzip the file and look for the README.txt file in the main directory for instructions.

JDK 9 (Early Access) includes both. the unlimited and the limited policy files.  By default JDK 9 uses the unlimited policy file.  Change the value of the crypto.policy property in the java.security file under conf/security/java.security for selecting the appropriate JCE policy file.


Increased minimum key length to 1024 for XML Signatures

The secure validation mode of the XML Signature implementation has been enhanced to restrict RSA and DSA keys less than 1024 bits by default as they are no longer secure enough for digital signatures. Additionally, a new security property named jdk.xml.dsig.SecureValidationPolicy has been added to the java.security file and can be used to control the different restrictions enforced when the secure validation mode is enabled.

The secure validation mode is automatically enabled if code is run with a SecurityManager. Alternatively, it can be enabled by setting the property org.jcp.xml.dsig.secureValidation to true with the setProperty method of the DOMValidateContext or DOMSignContext API, for example:

DOMValidateContext context = new DOMValidateContext(key, element);
context.setProperty("org.jcp.xml.dsig.secureValidation", Boolean.TRUE);

If an XML Signature is generated or validated with a weak key, an XMLSignatureException will be thrown with the message "RSA keys less than 1024 bits are forbidden when secure validation is enabled" or "DSA keys less than 1024 bits are forbidden when secure validation is enabled".

You can change the minimum key length, as follows:
For JDK 8 and earlier, edit lib/security/java.security and add the desired length to the jdk.xml.dsig.SecureValidationPolicy property by modifying the entries for minKeySize <type> <keylength>

In JDK 9, java.security, has been moved to conf/security/java.security

For example, if the current value is:

jdk.xml.dsig.secureValidationPolicy=\ disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\ maxTransforms 5,\ maxReferences 30,\ disallowReferenceUriSchemes file http https,\ minKeySize RSA 1024,\ minKeySize DSA 1024,\ noDuplicateIds,\ noRetrievalMethodLoops

and one wanted to increase the minimum key length to 2048, the new value would be:

jdk.xml.dsig.secureValidationPolicy=\ disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\ disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\ maxTransforms 5,\ maxReferences 30,\ disallowReferenceUriSchemes file http https,\ minKeySize RSA 2048,\ minKeySize DSA 2048,\ noDuplicateIds,\ noRetrievalMethodLoops

Added 3DES to the jdk.tls.legacyAlgorithms security property

To remove 3DES from the list of legacy algorithms:
  • On JDK 8 and earlier, edit the <java-home>/lib/security/java.security file and remove 3DES_EDE_CBC from the jdk.tls.legacyAlgorithms security property.
  • On JDK 9, edit the <java-home>/conf/security/java.security file and remove 3DES_EDE_CBC from the jdk.tls.legacyAlgorithms security property.

For example, if the current value is:

jdk.tls.legacyAlgorithms= \ K_NULL, C_NULL, M_NULL, \ DHE_DSS_EXPORT, DHE_RSA_EXPORT, DH_anon_EXPORT, DH_DSS_EXPORT, \ DH_RSA_EXPORT, RSA_EXPORT, \ DH_anon, ECDH_anon, \ RC4_128, RC4_40, DES_CBC, DES40_CBC, \ 3DES_EDE_CBC

The new value after removing 3DES_EDE_CBC would be:

jdk.tls.legacyAlgorithms= K_NULL, C_NULL, M_NULL, \ DHE_DSS_EXPORT, DHE_RSA_EXPORT, DH_anon_EXPORT, DH_DSS_EXPORT, \ DH_RSA_EXPORT, RSA_EXPORT, \ DH_anon, ECDH_anon, \ RC4_128, RC4_40, DES_CBC, DES40_CBC

Note that this is a low-risk change.  It is unlikely to cause a regression since it just affects the order of the negotiated algorithms.  3DES would still be used, if listed on the legacy algorithm list, if no other non-legacy algorithm is available.


Add support for SHA224withDSA and SHA256withDSA signature algorithms and increase maximum DSA keys to 2048 bits on JDK 7

This change will add support for the following security algorithms and key sizes on JDK 7:

  • The SHA224withDSA and SHA256withDSA signature algorithms
  • DSA keys with sizes up to 2048 bits. Prior to this change, the maximum size was 1024 bits.

Note that these features are already supported on JDK 8 and JDK 9 Early Access.

Applications may benefit from these new features when using security protocols or data that uses DSA keys or certificates. Applications will be able to verify certificates and TLS 1.2 protocol messages using these stronger algorithms and/or sizes. Also, the keytool utility will be able to create and verify keypairs and certificates with these stronger algorithms and key sizes.


Disable SHA-1 in certificate chains

Any TLS server certificate chain containing a SHA-1 certificate (end-entity or intermediate CA) anchored by root CA certificates included by default in Oracle's JDK will be blocked. Enterprise/private CAs are not affected. See JEP-288 for more information.

You can prepare for this change by testing with Early Access builds of JDK 8 or JDK 9 as follows:

With JDK 9 EA:
  1. Download a JDK 9 EA binary, build 157 or later from https://jdk9.java.net/download/
  2. Edit the conf/security/java.security file of your JDK installation.
With JDK 8 EA:
  1. Download a JDK 8u152 EA or later from https://jdk8.java.net/download.html
  2. Edit the lib/security/java.security file of your JDK installation.

If not already set, add the following constraint to the jdk.certpath.disabledAlgorithms property:     SHA1 jdkCA & usage TLSServer

For example, if the current value of the property is:

jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224

Then, after modifying it as suggested above, the value would be:

jdk.certpath.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, SHA1 jdkCA & usage TLSServer

Changing default TLS protocol version for client end points : TLS 1.0 to TLS 1.2

TLS 1.2 has been the default-enabled TLS protocol for JDK 8 since its release.  Due to concerns around TLS version intolerance, TLS 1.0 was left as the default enabled protocol for client end points on JDK 6 and JDK 7 when TLS 1.2 was added to those releases.

What is TLS version intolerance?

Since there are various versions of TLS (1.0, 1.1, 1.2, and possible future versions) and SSL, TLS protocols provide a built-in mechanism to negotiate the specific protocol version to use. When a client connects to a server, it announces the highest version it can support, and the server then responds with the protocol version that will actually be used for the connection. If the version chosen by the server is not supported or not acceptable by the client, the client terminates the negotiation and closes the connection. For example, if the client supports TLS 1.2 but the server only supports TLS 1.0, they will communicate using TLS 1.0; However, if the client does not support TLS 1.0, it will close the connection immediately.

In practice, some servers were not implemented properly and do not support protocol version negotiation. For example a server that supports TLS 1.0 only might simply reject a client request for TLS 1.2. Even if the client would have been able to supports TLS 1.0 a connection is not established.  This is a server bug, often called "version intolerance".

How to change the protocol version on client side

Several options exist for changing the default client-side TLS protocol version in the JDK.

Option 1. Use the "jdk.tls.client.protocols" system property

This property was introduced to JDK 7 in 7u95 and to JDK 6 in 6u121.

To enable specific TLS protocols on the client, specify them in a comma-separated list within quotation marks; all other supported protocols are then disabled on the client. For example, if the value of this property is "TLSv1.1,TLSv1.2", then the default protocol settings on the client for TLSv1.1 and TLSv1.2 are enabled on the client, while SSLv3, TLSv1, and SSLv2Hello are disabled on the client.

// Set the client default protocol versions to TLS 1.0, 1.1 and 1.2.
$ java -Djdk.tls.client.protocols="TLSv1,TLSv1.1,TLSv1.2" myApp

// Set the client default protocol version to TLS 1.0.
$ java -Djdk.tls.client.protocols="TLSv1" myApp

Note that the standard TLS protocol version names used in the JDK are SSLv3, TLSv1, TLSv1.1 and TLSv1.2.


Option 2. Use SSLContext to set TLS version

SSLContext of "TLSv1.2" protocol supports TLS 1.2. For example:

// Get SSLContext instance for "TLSv1.2".
SSLContext context = SSLContext.getInstance("TLSv1.2");

// Create SSLEngine object that enables TLS version 1.2.
SSLEngine sslEngine = context.createSSLEngine("www.example.com", 443);

Or
// Create SSLSocket object that enables TLS version 1.2.
SSLSocketFactory socketFac = context.getSocketFactory();
SSLSocekt sslSocket = (SSLSocekt)socketFac.createSocket("www.example.com", 443);

An SSLContext with "TLSv1" protocol supports TLS versions up to TLS 1.0 (no TLS 1.1 and 1.2).
An SSLContext created with "TLSv1.1" supports versions up to TLS 1.1 (no TLS 1.2).

// Get SSLContext instance that supports TLS versions up to TLS 1.0.
SSLContext context = SSLContext.getInstance("TLSv1");


Option 3 Use the SSLSocket/SSLEngine.setEnabledProtocols() API

Applications can set the enabled protocols explicitly in an SSLSocket/SSLEngine object. For example:

// Enable TLS 1.0, 1.1 and 1.2 in an SSLSocket object.
sslSocket.setEnabledProtocols(new String[] {"TLSv1", "TLSv1.1", "TLSv1.2"});

// Enable TLS 1.0, 1.1 and 1.2 in an SSLEngine object.
sslEngine.setEnabledProtocols(new String[] {"TLSv1", "TLSv1.1", "TLSv1.2"});

Or
// Enable TLS 1.0 only in an SSLSocket object.
sslSocket.setEnabledProtocols(new String[] {"TLSv1"});

// Enable TLS 1.0 only in an SSLEngine object.
sslEngine.setEnabledProtocols(new String[] {"TLSv1"});


Option 4. Use the SSLParameters.setProtocols() API

Applications can set the protocols in an SSLParameters object, and then apply it to a connection via the SSLSocket.setSSLParameters() and SSLEngine.setSSLParameters() methods. For example:

// Set TLS 1.0, 1.1 and 1.2 in an SSLParameters object.
sslParameters.setProtocols(new String[] {"TLSv1", "TLSv1.1", "TLSv1.2"});

Or
// Set TLS 1.0 only in an SSLParameters object.
sslParameters.setProtocols(new String[] {"TLSv1"});

// Apply the parameters to an SSLSocket object.
sslSocket.setSSLParameters(sslParameters);

// Apply the parameters to an SSLEngine object.
sslEngine.setSSLParameters(sslParameters);

For client applications, administrators may have to remove TLS 1.1 or TLS 1.2 from the default enabled protocol list to work around a TLS version intolerance issue on the server side.


Disable MD5 or MD2 signed jars

For JDK 8 and earlier, edit lib/security/java.security and add the algorithm to be disabled to the jdk.jar.disabledAlgorithms property by appending the algorithm name.

In JDK 9, java.security, has been moved to conf/security/java.security

For example,

if the current value is:

jdk.jar.disabledAlgorithms=MD2, RSA keySize < 1024
and one wanted to disable MD5 signed jars the new value would be:
jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024

To check if a weak algorithm or key was used to sign a JAR file you must use JDK 8u111, 7u121, 6u131, or later. After configuring the java.security file, you can use the jarsigner binary that ships with the JDK. Running jarsigner -verify -J-Djava.security.debug=jar on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.


Changing minimum key length for RSA signed jars

For JDK 8 and earlier, edit lib/security/java.security and add the desired length to the jdk.jar.disabledAlgorithms property by appending RSA keySize < min keylength

In JDK 9, java.security, has been moved to conf/security/java.security

For example,

if the current value is:

jdk.jar.disabledAlgorithms=MD2, RSA keySize < 1024
and one wanted to increase the minimum key length to 2048 the new value would be:
jdk.jar.disabledAlgorithms=MD2, RSA keySize < 2048

If no value is set for RSA keySize, just append it at the end of the property after a comma.

To check if a weak algorithm or key was used to sign a JAR file you must use JDK 8u111, 7u121, 6u131, or later. After configuring the java.security file, you can use the jarsigner binary that ships with the JDK. Running jarsigner -verify -J-Djava.security.debug=jar on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.


Changing minimum key length for EC

For JDK 8 and earlier, edit lib/security/java.security and add the desired length to the jdk.certpath.disabledAlgorithms property by appending EC KeySize < min keylength

In JDK 9, java.security, has been moved to conf/security/java.security

For example,

if the current value is:

jdk.certpath.disabledAlgorithms=MD2, MD5, EC keySize < 160
and one wanted to increase the minimum key length to 224 the new value would be:
jdk.certpath.disabledAlgorithms=MD2, MD5, EC keySize < 224

If no value is set for EC keySize, just append it at the end of the property after a comma.


Changing minimum key length for DSA

For JDK 8 and earlier, edit lib/security/java.security and add the desired length to the jdk.certpath.disabledAlgorithms property by appending DSA KeySize < min keylength

In JDK 9, java.security, has been moved to conf/security/java.security

For example,

if the current value is:

jdk.certpath.disabledAlgorithms=MD2, MD5, DSA keySize < 768
and one wanted to increase the minimum key length to 1024 the new value would be:
jdk.certpath.disabledAlgorithms=MD2, MD5, DSA keySize < 1024

If no value is set for DSA keySize, just append it at the end of the property after a comma.


Changing minimum key length for Diffie-Hellman

For JDK 8 and earlier, edit lib/security/java.security and add the desired length to the jdk.tls.disabledAlgorithms property by appending DH KeySize < min keylength

In JDK 9, java.security, has been moved to conf/security/java.security

For example,

if the current value is:

jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize <  768
and one wanted to increase the minimum key length to 1024 the new value would be:
jdk.tls.disabledAlgorithms=SSLv3, RC4, MD5withRSA, DH keySize <  1024

If no value is set for DSA keySize, just append it at the end of the property after a comma.


Privacy  | Terms of Use | Trademarks | Feedback

Oracle