Disabling and Restricting Cryptographic Algorithms in the JDK

Applies To

Java SE JDK and JRE - Version 8 and later
Information in this document applies to any platform.

Introduction

Weak cipher suites are vulnerable to cyber attacks and therefore can expose a security gap. This document describes the different methods for handling weak cipher suites.

Java security includes a large set of APIs, tools, and implementations of commonly-used security algorithms, mechanisms, and protocols. The Java security APIs span a wide range of areas, including cryptography, public key infrastructure, secure communication, authentication, and access control. Java security technology provides the developer with a comprehensive security framework for writing applications, and also provides the user or administrator with a set of tools to securely manage applications.

Also refer to Java Security Overview in the Security Developer’s Guide.

What is a java.security file?

The java.security file contains configuration data used to initialize the security framework, and security properties for keeping the JDK environment secure. The file itself has extensive information about how to use it. See the java.security File for more information.

An alternate java.security properties file may be specified from the command line via the system property:

-Djava.security.properties=[URL]

This properties file appends to the primary security properties file. If both properties files specify values for the same key, the value from the command-line properties file is selected, as it is the last one loaded.

Also, if you specify

-Djava.security.properties==[URL] (2 equals)

then that properties file completely overrides the primary security properties file.

In the following sections, we will describe some of the Java security properties that can be used to disable weak cipher suites. Note that java security properties cannot be set on the command line like a system property but can be either read at Security class load time via use of the java.security file OR controlled dynamically via the java.security.Security.setProperty and java.security.Security.getProperty methods. If you require a particular condition, you can reactivate it by either removing the associated value in the Security Property in the java.security file or dynamically setting the proper Security Property before JSSE is initialized.

Disabled and Restricted Cryptographic Algorithms

Also refer to Disabled and Restricted Cryptographic Algorithms in the Security Developer’s Guide.

In some environments, certain algorithms or key lengths might be undesirable when using TLS. The JDK uses the jdk.certpath.disabledAlgorithms, jdk.tls.disabledAlgorithm, jdk.jar.disabledAlgorithms, jdk.disabled.namedCurves, and jdk.security.legacyAlgorithms security properties to disable algorithms during TLS protocol negotiation, including version negotiation, cipher suites selection, peer authentication, and key exchange mechanisms. Note that these security properties are not guaranteed to be used by other JDK implementations.

The jdk.certpath.disabledAlgorithms Property

CertPath code uses this security property to determine which algorithms should not be allowed during CertPath checking. For example, when a TLS server sends an identifying certificate chain, a client TrustManager that uses a CertPath implementation to verify the received chain will not allow the stated conditions. For example, the following line blocks any MD2-based certificate, as well as SHA1 TLSServer certificates that chain to trust anchors that are pre-installed in the cacerts keystore. Likewise, this security setting blocks any RSA key less than 1024 bits.

Example: jdk.certpath.disabledAlgorithms=MD2, SHA1 jdkCA & usage TLSServer, RSA keySize < 1024

The syntax of the security properties and their current active values for jdk.certpath.disabledAlgorithms (from java.security file):

#
# Algorithm restrictions for certification path (CertPath) processing
#
# In some environments, certain algorithms or key lengths may be undesirable
# for certification path building and validation.  For example, "MD2" is
# generally no longer considered to be a secure hash algorithm.  This section
# describes the mechanism for disabling algorithms based on algorithm name
# and/or key length.  This includes algorithms used in certificates, as well
# as revocation information such as CRLs and signed OCSP Responses.
# The syntax of the disabled algorithm string is described as follows:
#   DisabledAlgorithms:
#       " DisabledAlgorithm { , DisabledAlgorithm } "
#
#   DisabledAlgorithm:
#       AlgorithmName [Constraint] { '&' Constraint } | IncludeProperty
#
#   AlgorithmName:
#       (see below)
#
#   Constraint:
#       KeySizeConstraint | CAConstraint | DenyAfterConstraint |
#       UsageConstraint
#
#   KeySizeConstraint:
#       keySize Operator KeyLength
#
#   Operator:
#       <= | < | == | != | >= | >
#
#   KeyLength:
#       Integer value of the algorithm's key length in bits
#
#   CAConstraint:
#       jdkCA
#
#   DenyAfterConstraint:
#       denyAfter YYYY-MM-DD
#
#   UsageConstraint:
#       usage [TLSServer] [TLSClient] [SignedJAR]
#
#   IncludeProperty:
#       include <security property>
#
# The "AlgorithmName" is the standard algorithm name of the disabled
# algorithm. See the Java Security Standard Algorithm Names Specification
# for information about Standard Algorithm Names.  Matching is
# performed using a case-insensitive sub-element matching rule.  (For
# example, in "SHA1withECDSA" the sub-elements are "SHA1" for hashing and
# "ECDSA" for signatures.)  If the assertion "AlgorithmName" is a
# sub-element of the certificate algorithm name, the algorithm will be
# rejected during certification path building and validation.  For example,
# the assertion algorithm name "DSA" will disable all certificate algorithms
# that rely on DSA, such as NONEwithDSA, SHA1withDSA.  However, the assertion
# will not disable algorithms related to "ECDSA".
#
# The "IncludeProperty" allows a implementation-defined security property that
# can be included in the disabledAlgorithms properties.  These properties are
# to help manage common actions easier across multiple disabledAlgorithm
# properties.
# There is one defined security property:  jdk.disabled.NamedCurves
# See the property for more specific details.
#
#
# A "Constraint" defines restrictions on the keys and/or certificates for
# a specified AlgorithmName:
#
#   KeySizeConstraint:
#     keySize Operator KeyLength
#       The constraint requires a key of a valid size range if the
#       "AlgorithmName" is of a key algorithm.  The "KeyLength" indicates
#       the key size specified in number of bits.  For example,
#       "RSA keySize <= 1024" indicates that any RSA key with key size less
#       than or equal to 1024 bits should be disabled, and
#       "RSA keySize < 1024, RSA keySize > 2048" indicates that any RSA key
#       with key size less than 1024 or greater than 2048 should be disabled.
#       This constraint is only used on algorithms that have a key size.
#
#   CAConstraint:
#     jdkCA
#       This constraint prohibits the specified algorithm only if the
#       algorithm is used in a certificate chain that terminates at a marked
#       trust anchor in the lib/security/cacerts keystore.  If the jdkCA
#       constraint is not set, then all chains using the specified algorithm
#       are restricted.  jdkCA may only be used once in a DisabledAlgorithm
#       expression.
#       Example:  To apply this constraint to SHA-1 certificates, include
#       the following:  "SHA1 jdkCA"
#
#   DenyAfterConstraint:
#     denyAfter YYYY-MM-DD
#       This constraint prohibits a certificate with the specified algorithm
#       from being used after the date regardless of the certificate's
#       validity.  JAR files that are signed and timestamped before the
#       constraint date with certificates containing the disabled algorithm
#       will not be restricted.  The date is processed in the UTC timezone.
#       This constraint can only be used once in a DisabledAlgorithm
#       expression.
#       Example:  To deny usage of RSA 2048 bit certificates after Feb 3 2020,
#       use the following:  "RSA keySize == 2048 & denyAfter 2020-02-03"
#
#   UsageConstraint:
#     usage [TLSServer] [TLSClient] [SignedJAR]
#       This constraint prohibits the specified algorithm for
#       a specified usage.  This should be used when disabling an algorithm
#       for all usages is not practical. 'TLSServer' restricts the algorithm
#       in TLS server certificate chains when server authentication is
#       performed. 'TLSClient' restricts the algorithm in TLS client
#       certificate chains when client authentication is performed.
#       'SignedJAR' constrains use of certificates in signed jar files.
#       The usage type follows the keyword and more than one usage type can
#       be specified with a whitespace delimiter.
#       Example:  "SHA1 usage TLSServer TLSClient"
#
# When an algorithm must satisfy more than one constraint, it must be
# delimited by an ampersand '&'.  For example, to restrict certificates in a
# chain that terminate at a distribution provided trust anchor and contain
# RSA keys that are less than or equal to 1024 bits, add the following
# constraint:  "RSA keySize <= 1024 & jdkCA".
#
# All DisabledAlgorithms expressions are processed in the order defined in the
# property.  This requires lower keysize constraints to be specified
# before larger keysize constraints of the same algorithm.  For example:
# "RSA keySize < 1024 & jdkCA, RSA keySize < 2048".
#
# Note: The algorithm restrictions do not apply to trust anchors or
# self-signed certificates.
#
# Note: This property is currently used by Oracle's PKIX implementation. It
# is not guaranteed to be examined and used by other implementations.
#
# Example:
#   jdk.certpath.disabledAlgorithms=MD2, DSA, RSA keySize < 2048
#
#
**jdk.certpath.disabledAlgorithms=MD2, MD5, SHA1 jdkCA & usage TLSServer, \
    RSA keySize < 1024, DSA keySize < 1024, EC keySize < 224, \
    include jdk.disabled.namedCurves**

The jdk.tls.disabledAlgorithms Property

SunJSSE code uses the jdk.tls.disabledAlgorithms Security Property to disable TLS/DTLS protocols, cipher suites, keys, and so on. The syntax is similar to the jdk.certpath.disabledAlgorithms Security Property. For example, the following line disables the SSLv3 algorithm and all of the TLS_*_RC4_* cipher suites:

jdk.tls.disabledAlgorithms=SSLv3, RC4

The syntax of the security properties and their current active values for

jdk.tls.disabledAlgorithms (from java.security file):

#
# Algorithm restrictions for Secure Socket Layer/Transport Layer Security
# (SSL/TLS/DTLS) processing
#
# In some environments, certain algorithms or key lengths may be undesirable
# when using SSL/TLS/DTLS.  This section describes the mechanism for disabling
# algorithms during SSL/TLS/DTLS security parameters negotiation, including
# protocol version negotiation, cipher suites selection, named groups
# selection, signature schemes selection, peer authentication and key
# exchange mechanisms.
#
# Disabled algorithms will not be negotiated for SSL/TLS connections, even
# if they are enabled explicitly in an application.
#
# For PKI-based peer authentication and key exchange mechanisms, this list
# of disabled algorithms will also be checked during certification path
# building and validation, including algorithms used in certificates, as
# well as revocation information such as CRLs and signed OCSP Responses.
# This is in addition to the jdk.certpath.disabledAlgorithms property above.
#
# See the specification of "jdk.certpath.disabledAlgorithms" for the
# syntax of the disabled algorithm string.
#
# Note: The algorithm restrictions do not apply to trust anchors or
# self-signed certificates.
#
# Note: This property is currently used by the JDK Reference implementation.
# It is not guaranteed to be examined and used by other implementations.
#
# Example:
#   jdk.tls.disabledAlgorithms=MD5, SSLv3, DSA, RSA keySize < 2048, \
#       rsa_pkcs1_sha1, secp224r1
**jdk.tls.disabledAlgorithms=SSLv3, TLSv1, TLSv1.1, RC4, DES, MD5withRSA, \
    DH keySize < 1024, EC keySize < 224, 3DES_EDE_CBC, anon, NULL, \
    include jdk.disabled.namedCurves**

Here is an example of a stack trace you could get as a result of using a property that’s on the disabled list:

javax.net.ssl.SSLHandshakeException: Server chose TLSv1, but that protocol version is not enabled or not supported by the client.
at sun.security.ssl.ClientHandshaker.serverHello(ClientHandshaker.java:452)
at sun.security.ssl.ClientHandshaker.processMessage(ClientHandshaker.java:206)
at sun.security.ssl.Handshaker.processLoop(Handshaker.java:979)
at sun.security.ssl.Handshaker$1.run(Handshaker.java:919)

The jdk.tls.legacyAlgorithms Property

In some environments, a certain algorithm may be undesirable but it cannot be disabled because of its use in legacy applications. Legacy algorithms may still be supported, but applications should not use them as the security strength of legacy algorithms is usually not strong enough. During TLS/DTLS security parameters negotiation, legacy algorithms are not negotiated unless there are no other candidates. The Security Property jdk.tls.legacyAlgorithms specifies which algorithms the Oracle JDK considers as legacy algorithms.

The syntax of the security properties and their current active values for jdk.tls.legacyAlgorithms (from java.security file):

#
# Legacy algorithms for certification path (CertPath) processing and
# signed JAR files.
#
# In some environments, a certain algorithm or key length may be undesirable
# but is not yet disabled.
#
# Tools such as keytool and jarsigner may emit warnings when these legacy
# algorithms are used. See the man pages for those tools for more information.
#
# The syntax is the same as the "jdk.certpath.disabledAlgorithms" and
# "jdk.jar.disabledAlgorithms" security properties.
#
# Note: This property is currently used by the JDK Reference
# implementation. It is not guaranteed to be examined and used by other
# implementations.

**jdk.security.legacyAlgorithms=SHA1, \
    RSA keySize < 2048, DSA keySize < 2048**

The jdk.jar.disabledAlgorithms Property

The jarsigner command uses the jdk.jar.disabledAlgorithms and jdk.security.legacyAlgorithms Security Properties to determine which algorithms are considered a security risk. If the JAR file was signed with any algorithms that are disabled, it will be treated as an unsigned JAR file. If the JAR file was signed with any legacy algorithms, it will be treated as signed with an informational warning to inform users that the legacy algorithm will be disabled in a future update. For detailed verification output, include -J-Djava.security.debug=jar.

The syntax of the security properties and their current active values for jdk.jar.disabledAlgorithms (from java.security file):

#
# Algorithm restrictions for signed JAR files
#
# In some environments, certain algorithms or key lengths may be undesirable
# for signed JAR validation.  For example, "MD2" is generally no longer
# considered to be a secure hash algorithm.  This section describes the
# mechanism for disabling algorithms based on algorithm name and/or key length.
# JARs signed with any of the disabled algorithms or key sizes will be treated
# as unsigned.
#
# The syntax of the disabled algorithm string is described as follows:
#   DisabledAlgorithms:
#       " DisabledAlgorithm { , DisabledAlgorithm } "
#
#   DisabledAlgorithm:
#       AlgorithmName [Constraint] { '&' Constraint }
#
#   AlgorithmName:
#       (see below)
#
#   Constraint:
#       KeySizeConstraint | DenyAfterConstraint
#
#   KeySizeConstraint:
#       keySize Operator KeyLength
#
#   DenyAfterConstraint:
#       denyAfter YYYY-MM-DD
#
#   Operator:
#       <= | < | == | != | >= | >
#
#   KeyLength:
#       Integer value of the algorithm's key length in bits
#
# Note: This property is currently used by the JDK Reference
# implementation. It is not guaranteed to be examined and used by other
# implementations.
#
# See "jdk.certpath.disabledAlgorithms" for syntax descriptions.
#
**jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024, \
      DSA keySize < 1024, include jdk.disabled.namedCurves**

The jdk.disabled.namedCurves Property

The syntax of the security properties and their current active values for

jdk.disabled.namedCurvesAlgorithms (from java.security file):

#
# This property contains a list of disabled EC Named Curves that can be included
# in the jdk.[tls|certpath|jar].disabledAlgorithms properties.  To include this
# list in any of the disabledAlgorithms properties, add the property name as
# an entry.
**jdk.disabled.namedCurves = secp112r1, secp112r2, secp128r1, secp128r2, \
    secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, \
    secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, \
    sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, \
    sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, \
    sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, \
    X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, \
    X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, \
    X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1, \
    brainpoolP320r1, brainpoolP384r1, brainpoolP512r1**

Disabled TLS_ECDH Cipher Suites (October 2024 CPU)

TLS_ECDH cipher suites do not preserve forward-secrecy and are rarely used in practice. Note that some TLS_ECDH cipher suites were already disabled because they use algorithms that are disabled, such as 3DES and RC4. This action will disable the rest. Any attempts to use cipher suites starting with “TLS_ECDH_” will fail with an SSLHandshakeException.

Refer to Disable TLS_ECDH Cipher Suites

Disabled SHA-1 JARs signed after 2019-01-01 (October 2022 CPU)

JARs signed with SHA-1 algorithms will be disabled by default and treated as if they were unsigned. However, see exceptions to this policy below. This applies to the algorithms used to digest, sign, and optionally timestamp the JAR. It also applies to the signature and digest algorithms of the certificates in the certificate chain of the code signer and the Timestamp Authority, and any CRLs or OCSP responses that are used to verify if those certificates have been revoked.

See also Disable SHA-1 signed jars.

Disable SHA-1 XML Signatures

Refer to XML Signature Secure Validation Mode in the Security Developer’s Guide.

XML signature validations work by parsing third-party data that cannot be trusted until it is actually validated. Unrestricted validation of third-party XML signatures can lead to security vulnerabilities which can range from denial of service to confidentiality breaches. XML Signature secure validation mode can protect you from XML Signatures that may contain potentially hostile constructs that can cause denial-of-service or other types of security issues.

XML Signature secure validation mode is enabled by default when you run your application with a security manager. You can also enable XML Signature secure validation mode by setting the org.jcp.xml.dsig.secureValidation property to TRUE. You must set this property to TRUE before validating an XML Signature.

To set this property in an application, call the javax.xml.crypto.dsig.dom.DOMValidateContext.setProperty method:

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

When XML Signature secure validation mode is enabled, XML Signatures are processed more securely. Limits are set on various XML Signature constructs to avoid conditions such as denial-of-service attacks. By default, it enforces the following restrictions:

• Forbids the use of XSLT transforms
• Restricts the number of SignedInfo or Manifest Reference elements to 30 or less
• Restricts the number of Reference transforms to 5 or less
• Forbids the use of MD5-related signatures or MAC algorithms
• Ensures that Reference IDs are unique to help prevent signature wrapping attacks
• Forbids Reference URIs of type http, https, or file
• Does not allow a RetrievalMethod element to reference another RetrievalMethod element
• Forbids RSA or DSA keys less than 1024 bits and EC keys less than 224 bits

In addition, you can use the jdk.xml.dsig.secureValidationPolicy Security Property to control and fine-tune the restrictions listed previously or add additional restrictions. See the definition of this Security Property in the java.security file for more information.

Enhancements in JDK 17

Secure Validation Mode

The XML Signature secure validation mode has been enabled by default in JDK 17. See issue JDK-8259801.

Disable SHA1-XML Signatures

XML Signatures that contain SHA-1 based digest or signature algorithms are now disabled by default. SHA-1 is a weak digest algorithm that is no longer recommended for digest and signature algorithms. Validation of XML signatures that violate this constraint will fail.

If necessary, and at their own risk, users can re-enable SHA-1 by modifying or overriding the jdk.xml.dsig.secureValidationPolicy security property defined in the java.security configuration file.

See issue JDK-8259709.

Deprecate Weak Algorithms 3DES and RC4 in Kerberos

Since the October 2022 CPU, the 3DES and RC4 Kerberos encryption types are disabled by default. Both 3DES and RC4 are weak encryption algorithms that should not be used. They are officially deprecated in RFC 8429.

The des3-hmac-sha1 and rc4-hmac encryption types are disabled by default, but can be re-enabled, at your own risk, by setting the allow_weak_crypto property to true in the krb5.conf configuration file. Note that this will re-enable other weak encryption types that are already disabled, such as des-cbc-crc and des-cbc-md5. Alternatively, you can set the default_tkt_enctypes, default_tgs_enctypes, and permitted_enctypes properties to the encryption types that are allowed.

For more information, see:

• JDK-8139348
• Deprecating 3DES and RC4 In Kerberos (Doc ID 2908438.1)

Last reviewed on Sat Feb 01 2025 00:00:00 GMT+0000 (Coordinated Universal Time)