JDK 13 will soon be released! As with my JDK 12 blog, I have gathered up a list of the most interesting and useful security enhancements in this release. And as before, I have grouped them into appropriate categories (crypto, TLS, etc) which should make it easier to find out what has changed in each specific area.
Table of Contents
Support for Microsoft Cryptography Next Generation (CNG) API
On Windows, the
SunMSCAPIJCE provider has been enhanced to support CNG. The provider can now load RSA and EC keys in CNG format from Windows keystores. The provider also now supports elliptic curve
PKCS#11 version 2.40
Java Algorithm PKCS#11 Mechanism MessageDigest.SHA-512/224 CKM_SHA512_224 MessageDigest.SHA-512/256 CKM_SHA512_256 MAC.HmacSHA512/224 CKM_SHA512_224_HMAC MAC.HmacSHA512/256 CKM_SHA512_256_HMAC Signature.RSASSA-PSS CKM_RSA_PKCS_PSS Signature.SHA1withRSASSA-PSS CKM_SHA1_RSA_PKCS_PSS Signature.SHA224withRSASSA-PSS CKM_SHA224_RSA_PKCS_PSS Signature.SHA256withRSASSA-PSS CKM_SHA256_RSA_PKCS_PSS Signature.SHA384withRSASSA-PSS CKM_SHA384_RSA_PKCS_PSS Signature.SHA512withRSASSA-PSS CKM_SHA512_RSA_PKCS_PSS Signature.SHA224withDSA CKM_DSA_SHA224 Signature.SHA256withDSA CKM_DSA_SHA256 Signature.SHA384withDSA CKM_DSA_SHA384 Signature.SHA512withDSA CKM_DSA_SHA512 Cipher.AES/GCM/NoPadding CKM_AES_GCM
javax.security.certAPIs marked for removal
javax.security.certAPIs have been marked for removal and are subject to removal in a future release. These APIs exist only to support applications written against early versions of the Java Secure Socket Extension (JSSE), prior to its inclusion in JDK 1.4. Applications should use the
X25519 and X448 Diffie-Hellman elliptic curve support
SunJSSEprovider has been enhanced to support the x25519 and x448 elliptic curve named groups with x25519 being the highest preferred group. These curves are supported for TLS versions 1.0, 1.1, 1.2, and 1.3. The default list of named groups is now:
x25519, secp256r1, secp384r1, secp521r1, x448, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, secp256k1, ffdhe2048, ffdhe3072, ffdhe4096, ffdhe6144, ffdhe8192
This order can be overridden using the
SunJSSEprovider now supports stateless sessions, which can significantly improve the performance and scalability of a TLS server under large workloads.
For this release, the feature is not yet enabled by default. On the client side, it can be enabled by setting the
jdk.tls.client.enableSessionTicketExtensionsystem property to “true” and on the server side, by setting the
jdk.tls.server.enableSessionTicketExtensionsystem property to “true”.
Enabled cipher suites order changed to improve security
The order of the default list of enabled TLS cipher suites has been modified with several changes to improve security. See the CSR for full details.
Server-side cipher suite order now preferred
The TLS cipher suite selection algorithm has been modified to use the server’s cipher suite order, rather than the client’s.
GSS-API and Kerberos
Kerberos cross-realm referrals
Client support for principal name canonicalization and cross-realm referrals, as specified in RFC 6806 has been added to the Kerberos implementation.
This feature can greatly simplify usability and configuration in a Kerberos environment of multiple realms.
Native GSS-API library on Windows
A Windows implementation of the GSS-API library has been added to the JDK. This provides better interoperability and integration with Windows. For example, it can directly read Windows login user credentials.
This implementation is supported on the client-side only and it is not enabled by default. To enable it, set the
sun.security.jgss.nativesystem property to “true”.
SASL mechanisms can now be restricted
A new security property named
jdk.sasl.disabledMechanismshas been introduced to allow you to disable SASL mechanisms that you no longer want to be used. There are no mechanisms disabled by default. Mechanisms can be added to the property in the
java.securityconfiguration file. Here is the definition of the property:
# Disabled mechanisms for the Simple Authentication and Security Layer (SASL) # # Disabled mechanisms will not be negotiated by both SASL clients and servers. # These mechanisms will be ignored if they are specified in the mechanisms argument # of `Sasl.createClient` or the mechanism argument of `Sasl.createServer`. # # The value of this property is a comma-separated list of SASL mechanisms. # The mechanisms are case-sensitive. Whitespaces around the commas are ignored. # # 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.sasl.disabledMechanisms=PLAIN, CRAM-MD5, DIGEST-MD5 jdk.sasl.disabledMechanisms=
String constants for Canonical XML 1.1
New public constants named
INCLUSIVE_11_WITH_COMMENTShave been added to the
javax.xml.crypto.dsig.CanonicalizationMethodAPI. These represent the URIs for the Canonical XML 1.1 and Canonical XML 1.1 with Comments algorithms for XML Signature. Now you can use the constants instead of the URIs in your application, ex:
A new public constant (
EC_TYPE) representing the URI of the
ECKeyValueelement has been added to the
javax.xml.crypto.dsig.keyinfo.KeyValueAPI. This allows you to identify this type in your applications using the constant instead of the URI.
keytool command for displaying TLS configuration information
keytoolutility has a new command (
-showinfois the command and
-tlsis the option) that displays information about the TLS configuration of the system that the command is run on. This information includes a list of the enabled protocols and cipher suites, ordered by priority.
Here is an example output of running the command:
$ keytool -showinfo -tls Enabled Protocols ----------------- TLSv1.3 TLSv1.2 TLSv1.1 TLSv1 Enabled Cipher Suites --------------------- TLS_AES_256_GCM_SHA384 TLS_AES_128_GCM_SHA256 TLS_CHACHA20_POLY1305_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_RSA_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_CHACHA20_POLY1305_SHA256 TLS_DHE_DSS_WITH_AES_256_GCM_SHA384 TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 TLS_DHE_DSS_WITH_AES_128_GCM_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_RSA_WITH_AES_256_CBC_SHA256 TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 TLS_DHE_RSA_WITH_AES_128_CBC_SHA256 TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 TLS_ECDH_ECDSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_RSA_WITH_AES_256_GCM_SHA384 TLS_ECDH_ECDSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_RSA_WITH_AES_128_GCM_SHA256 TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_RSA_WITH_AES_256_CBC_SHA384 TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA256 TLS_ECDH_RSA_WITH_AES_128_CBC_SHA256 TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDHE_RSA_WITH_AES_256_CBC_SHA TLS_ECDHE_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_RSA_WITH_AES_256_CBC_SHA TLS_DHE_DSS_WITH_AES_256_CBC_SHA TLS_DHE_RSA_WITH_AES_128_CBC_SHA TLS_DHE_DSS_WITH_AES_128_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_256_CBC_SHA TLS_ECDH_RSA_WITH_AES_256_CBC_SHA TLS_ECDH_ECDSA_WITH_AES_128_CBC_SHA TLS_ECDH_RSA_WITH_AES_128_CBC_SHA TLS_RSA_WITH_AES_256_GCM_SHA384 TLS_RSA_WITH_AES_128_GCM_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA256 TLS_RSA_WITH_AES_128_CBC_SHA256 TLS_RSA_WITH_AES_256_CBC_SHA TLS_RSA_WITH_AES_128_CBC_SHA TLS_EMPTY_RENEGOTIATION_INFO_SCSV