JDK 17 Security Enhancements

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:

• JEP 403: Strongly Encapsulate JDK Internals

  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-opens or --add-exports command-line options to individually open/export packages if necessary.

• JEP 409: Sealed Classes

  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.

• JEP 415: Context-Specific Deserialization Filters

  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 ObjectInputFilter API that applies to the ObjectInputStream.

  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

1. Crypto
2. PKI
3. TLS
4. Kerberos
5. XML Signature
6. Security Manager

Crypto

• Support KWP in addition to KW

  The SunJCE provider 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.Cipher API with the algorithm transformations "AES/KWP/NoPadding", "AES/KW/PKCS5Padding" or "AES/KW/NoPadding".

  Alternatively, you can specify "AESWrap" as the Cipher algorithm which is equivalent to KW mode with NoPadding, or "AESWrapPad" which is equivalent to KWP mode with NoPadding.

  Issue: JDK-8248268

• JCE doesn’t provide any class to handle RSA private key in PKCS#1

  The "RSA" implementation of KeyFactory can now generate private and public keys from a PKCS#1 encoding (in addition to PKCS#8).

  Issue: JDK-8023980

• Add ChaCha20 and Poly1305 support to SunPKCS11 provider

  The SunPKCS11 provider now supports the ChaCha20 and Poly1305 stream ciphers, if the underlying PKCS#11 implementation also supports them.

  Issue: JDK-8255410

PKI

• 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.ocspNonce system property to true. If not enabled, the default JDK implementation uses a time-based approach as specified by RFC 5019.

  Issue: JDK-8256895

• 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.

  Issue: JDK-8179503

• New HARICA root CA certificates added

  Two new root CA certificates owned by HARICA have been added to the cacerts keystore:

  1. 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

  2. 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 cacerts keystore in Oracle’s JDK 16.0.1, 11.0.11, 8u291, and 7u301 releases.

  Issue: JDK-8256421

TLS

• 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" ...

  Issue: JDK-8217633

Kerberos

• 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 des3-hmac-sha1 and rc4-hmac encryption types are now disabled, but can be re-enabled, at your own risk, by setting the allow_weak_crypto property to true in the krb5.conf configuration file. However, note that will also re-enable other weak encryption types that are already disabled such as des-cbc-crc and des-cbc-md5. Alternatively, set the default_tkt_enctypes, default_tgs_enctypes, and permitted_enctypes properties to the encryption types that are allowed.

  Issue: JDK-8139348

XML Signature

• Add SignatureMethodParameterSpec subclass for RSASSA-PSS params

  A new class named javax.xml.crypto.dsig.spec.RSAPSSParameterSpec has 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.PSSParameterSpec as the input parameter.

  Issue: JDK-8259575

• 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.secureValidationPolicy security property defined in the java.security configuration file.

  Issue: JDK-8259709

• 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 org.jcp.xml.dsig.secureValidation property to true with the javax.xml.crypto.XMLCryptoContext.setProperty() method, or by running the code with a SecurityManager enabled.

  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.

  Issue: JDK-8259801

Security Manager

• Deprecate the Security Manager for Removal

  In JDK 17, the Security Manager has been deprecated for removal. This includes the java.lang.SecurityManager API 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.

  JEP: https://openjdk.java.net/jeps/411