JDK 17 was released on September 14, 2021! As with my previous blogs, I have compiled a list of what I think are the most interesting and useful security enhancements in this release. I have also grouped them into appropriate categories (crypto, TLS, etc) which should make it easier to find out what has changed in each specific area. The JDK 17 release notes also contain further details on these and other enhancements.
Probably the most significant security related change in JDK 17 is JEP 411: Deprecate the Security Manager for Removal. JDK 17 begins that process by deprecating a number of Security Manager APIs and adding run time warnings for applications using the Security Manager. See the Security Manager section below for further details.
Also, three other important JDK 17 features that are not part of the security libraries area but have beneficial security benefits include:
With JEP 403, JDK 17 continues to strengthen the strong encapsulation of JDK internals by disabling the command line switch to enable relaxed strong encapsulation. Instead you must use the
--add-exportscommand-line options to individually open/export packages if necessary.
Sealed classes allow you to restrict what classes are allowed to extend or implement a specific class. This has obvious security benefits as it can be used to prevent unauthorized implementations of the class.
Deserialization filters were introduced in JDK 9 and allow applications and libraries to validate incoming serialized streams before deserializing them. This can be done statically via security properties or dynamically via a new
ObjectInputFilterAPI that applies to the
JEP 415 improves on this feature by introducing filter factories which can be used to apply different filters depending on the object stream.
Table of Contents
Support KWP in addition to KW
SunJCEprovider now supports the AES Key Wrap With Padding (KWP) mode. Also, the AES Key Wrap mode (KW) has been enhanced to support encryption of keys (in addition to wrapping), and custom IVs and padding schemes.
These standard modes are designed to protect cryptographic keys and are defined in NIST SP 800-38F.
Use these modes in your Java application with the
javax.crypto.CipherAPI with the algorithm transformations
Alternatively, you can specify
Cipheralgorithm which is equivalent to KW mode with NoPadding, or
"AESWrapPad"which is equivalent to KWP mode with NoPadding.
JCE doesn’t provide any class to handle RSA private key in PKCS#1
KeyFactorycan now generate private and public keys from a PKCS#1 encoding (in addition to PKCS#8).
Add ChaCha20 and Poly1305 support to SunPKCS11 provider
SunPKCS11provider now supports the ChaCha20 and Poly1305 stream ciphers, if the underlying PKCS#11 implementation also supports them.
Add support for RFC 8954: Online Certificate Status Protocol (OCSP) Nonce Extension
Support for the OCSP Nonce Extension has been added to the PKIX implementation. The Nonce extension can help prevent replay attacks where a previous good OCSPResponse for a certificate has not expired but the status of the certificate has changed (for example, it is now revoked) and the prior good OCSPResponse can be replayed.
For compatibility reasons, the extension is not enabled by default, but can be enabled by setting the
jdk.security.certpath.ocspNoncesystem property to
true. If not enabled, the default JDK implementation uses a time-based approach as specified by RFC 5019.
Java should support GET OCSP calls
The JDK PKIX implementation now uses HTTP GET (instead of POST) to submit OCSP requests if the request is less than 255 bytes. Using GET allows requests to be cached which can improve performance.
New HARICA root CA certificates added
Two new root CA certificates owned by HARICA have been added to the
HARICA Root CA 2015
This root certificate has the following distinguished name:
CN=Hellenic Academic and Research Institutions RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR
HARICA ECC Root CA 2015
This root certificate has the following distinguished name:
CN=Hellenic Academic and Research Institutions ECC RootCA 2015, O=Hellenic Academic and Research Institutions Cert. Authority, L=Athens, C=GR
These root certificates have also been added to the
cacertskeystore in Oracle’s JDK 16.0.1, 11.0.11, 8u291, and 7u301 releases.
Configurable extensions with system properties
TLS interoperability issues can sometimes occur if an implementation does not properly handle TLS extensions that it does not support. To help workaround these issues, two new system properties have been introduced that allow you to customize the extensions that are not enabled (i.e. disabled) when establishing a TLS connection.
The system properties apply to the client (
jdk.tls.client.disableExtensions) or the server (
jdk.tls.server.disableExtensions). The value of the property is a comma separated list of standard TLS extension names. For example:
java -Djdk.tls.client.disabledExtensions="status_request,signature_algorithms_cert" ...
Deprecate 3DES and RC4 in Kerberos
3DES and RC4 Kerberos encryption types have now been disabled by default. Both 3DES and RC4 are weak encryption algorithms that should not be used. The Kerberos 3DES and RC4 encryption types are officially deprecated in RFC 8429.
By default the
rc4-hmacencryption types are now disabled, but can be re-enabled, at your own risk, by setting the
allow_weak_cryptoproperty to true in the
krb5.confconfiguration file. However, note that will also re-enable other weak encryption types that are already disabled such as
des-cbc-md5. Alternatively, set the
permitted_enctypesproperties to the encryption types that are allowed.
Add SignatureMethodParameterSpec subclass for RSASSA-PSS params
A new class named
javax.xml.crypto.dsig.spec.RSAPSSParameterSpechas been added to the XML Signature API and can be used to specify parameters for the RSASSA-PSS signature algorithm. Also, a new String constant for the signature algorithm (RSA_PSS) has been defined.
The new API takes a
java.security.spec.PSSParameterSpecas the input parameter.
Disable SHA-1 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.secureValidationPolicysecurity property defined in the
Enable XML Signature secure validation mode by default
The XML Signature secure validation mode has been enabled by default. Previously, applications had to explicitly enable this mode by setting the
javax.xml.crypto.XMLCryptoContext.setProperty()method, or by running the code with a
The secure validation mode provides additional protection against XML Signatures that contain potentially hostile content, use weak algorithms, or contain constructs that may cause denial-of-service. Currently, this mode 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 signature or MAC algorithms
- Forbids the use of SHA-1 signature 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
For more information about this mode see the XML Signature Secure Validation Mode in the XML Signature API Overview and Tutorial.
Deprecate the Security Manager for Removal
In JDK 17, the Security Manager has been deprecated for removal. This includes the
java.lang.SecurityManagerAPI and several APIs related to the Security Manager – see the Deprecate APIs for removal section of the JEP for a full list of impacted APIs.
There are several reasons why the Security Manager is being deprecated, and these are covered in more detail in the Motivation section of the JEP.
Note that the Security Manager will still be fully supported in JDK 17 – however warnings will be emitted at run time if a Security Manager is enabled – this will help alert users and developers of the deprecation and prepare for the future removal.