Chapter 3. Red Hat build of OpenJDK new features and enhancements
The Red Hat build of OpenJDK 21.0.10 release includes the following new features or enhancements to existing features that were introduced in earlier releases.
For all the other changes and security fixes, see OpenJDK 21.0.10 Released.
Improved robustness of String constructors with mutable array inputs
The introduction of Compact Strings (JEP 254) in OpenJDK 9 changed the implementation of the String class to use a byte array for storing character data in either Latin-1 or UTF-16 encoding. Latin-1 encoding uses one byte per character. UTF-16 encoding uses two bytes per character.
This optimization reduced the memory usage over a character array when using String objects with only Latin-1 characters. However, this change also introduced a potential race condition if the input character array was modified externally while being converted to bytes.
From Red Hat build of OpenJDK 21.0.10 onward, the conversion includes an additional verification step to check that the first non Latin-1 character has not changed to Latin-1 in the original array after all characters have been copied. If the first non Latin-1 character has changed to Latin-1, the JDK makes a second attempt to compress the character data to Latin-1 encoding. The documentation for relevant methods in the AbstractStringBuilder, Appendable, and String classes has also been updated to indicate that the contents of the final String are unspecified if the character array is modified during construction.
See JDK-8311906 (JDK Bug System).
Improved JMX connections
From Red Hat build of OpenJDK 21.0.10 onward, SSL connections created by javax.rmi.ssl.SslRMIClientSocketFactory objects enable HTTPS-based endpoint identification by default.
You can disable this feature by setting the jdk.rmi.ssl.client.enableEndpointIdentification property to false.
JDK bug system reference ID: JDK-8341496
Enhanced certificate checking
When the com.sun.security.enableAIAcaIssuers system property is set to true, Red Hat build of OpenJDK supports the authorityInfoAccess extension in X.509 certificates.
Red Hat build of OpenJDK 21.0.10 adds a new system and security property, com.sun.security.allowedAIALocations, that acts as a filter on the Uniform Resource Identifiers (URIs) that are specified in the authorityInfoAccess extension. By default, this property has an empty value, which means all URIs are denied when the extension is enabled. If you want to allow all URIs, set this property to any.
For more granular control, you can specify a whitespace-separated list of filters. The java.security file provides information on the syntax for the list of filters.
If you specify a value for the system property, it takes precedence over the security property.
JDK bug system reference ID: JDK-8368032
TLS_RSA cipher suites are disabled by default
The TLS Rivest-Shamir-Adleman (TLS_RSA) cipher suites do not preserve forward secrecy and they are rarely used. Red Hat build of OpenJDK 21.0.10 disables the TLS_RSA cipher suites by adding the TLS_RSA_* option to the jdk.tls.disabledAlgorithms security property in the java.security configuration file. If you attempt to use the TLS_RSA cipher suites, Red Hat build of OpenJDK now throws an SSLHandshakeException error.
If you want to continue using the TLS_RSA cipher suites, you can remove TLS_RSA_* from the jdk.tls.disabledAlgorithms security property either by modifying the java.security configuration file or by using the java.security.properties system property.
Continued use of the TLS_RSA cipher suites is at your own risk.
RSA cipher suites that use DES, 3DES, RC4, or NULL were disabled previously. This change results in the following cipher suites also being disabled:
-
TLS_RSA_WITH_AES_256_GCM_SHA384 -
TLS_RSA_WITH_AES_256_CBC_SHA256 -
TLS_RSA_WITH_AES_256_CBC_SHA -
TLS_RSA_WITH_AES_128_GCM_SHA256 -
TLS_RSA_WITH_AES_128_CBC_SHA256 -
TLS_RSA_WITH_AES_128_CBC_SHA
See JDK-8245545 (JDK Bug System).
SHA-1 algorithm is disabled in TLS 1.2 and DTLS 1.2 handshake signatures
The Internet Engineering Task Force (IETF) RFC 9155 deprecates the use of the SHA-1 algorithm by default in TLS 1.2 and Datagram TLS (DTLS) 1.2 handshake signatures. This algorithm has been considered insecure since 2005 and the first public attack was published on February 23 2017.
Red Hat build of OpenJDK 21.0.10 disables the SHA-1 algorithm by default in TLS 1.2 and DTLS 1.2 handshake signatures by adding the following options to the jdk.tls.disabledAlgorithms security property in the java.security configuration file:
-
rsa_pkcs1_sha1 usage HandshakeSignature -
ecdsa_sha1 usage HandshakeSignature -
dsa_sha1 usage HandshakeSignature
If you attempt to use SHA-1 in these types of handshake signatures, Red Hat build of OpenJDK now throws an SSLHandshakeException error.
If you want to continue using SHA-1 in TLS 1.2 and DTLS 1.2 handshake signatures, you can remove rsa_pkcs1_sha1 usage HandshakeSignature, ecdsa_sha1 usage HandshakeSignature, and dsa_sha1 usage HandshakeSignature from the jdk.tls.disabledAlgorithms security property either by modifying the java.security configuration file or by using the java.security.properties system property.
Continued use of the SHA-1 algorithm in TLS 1.2 and Datagram TLS (DTLS) 1.2 handshake signatures is at your own risk.
This change results in the following signature schemes being disabled for handshaking:
-
dsa_sha1 -
ecdsa_sha1 -
rsa_pkcs1_sha1