RELEASE NOTES: JDK 17.0.17

java.net.http.HttpClient Is Enhanced to Report HTTP/2 Flow Control Errors to the Server

The java.net.http.HttpClient will now report HTTP/2 flow control errors to the server when they are detected. This is an implementation detail that should be transparent to users of the HttpClient API, but could result in streams being reset or connections being closed if connecting to a non-conformant HTTP/2 server.

java.net.http.HttpClient Is Enhanced to Report HTTP/2 Flow Control Errors to the Server

The java.net.http.HttpClient will now report HTTP/2 flow control errors to the server when they are detected. This is an implementation detail that should be transparent to users of the HttpClient API, but could result in streams being reset or connections being closed if connecting to a non-conformant HTTP/2 server.

The flow control limits enforced by the client can be specified with two system properties, which can be set on the java command line:

• jdk.httpclient.connectionWindowSize specifies the HTTP/2 client connection window size in bytes. The default value if unspecified is 2^26. Valid values are in the range [2^16-1, 2^31-1]. If an invalid value is provided, the default value is used. The implementation guarantees that the actual value will be no smaller than the stream window size, which can be configured through the jdk.httpclient.windowsize system property.

• jdk.httpclient.windowsize specifies the HTTP/2 client stream window size in bytes. The default value if unspecified is 16777216 or 16 MB. Valid values are in the range [2^14, 2^31-1]. If an invalid value is provided, the default value is used.

Update XML Security for Java to 3.0.5

The XML Signature implementation has been updated to Santuario 3.0.5. Support for four new SHA-3 based ECDSA SignatureMethod algorithms have been added: SignatureMethod.ECDSA_SHA3_224, SignatureMethod.ECDSA_SHA3_256, SignatureMethod.ECDSA_SHA3_384, and SignatureMethod.ECDSA_SHA3_512.

Introduce LDAP and RMI Protocol Specific Object Factory Filters to JNDI Implementation

In this release, new system and security properties are introduced to allow more granular control over the set of JNDI object factories allowed to reconstruct Java objects from JNDI/LDAP and JNDI/RMI contexts:

• The new jdk.jndi.ldap.object.factoriesFilter property specifies which object factory classes are allowed to instantiate Java objects from object references returned by JNDI/LDAP contexts. Its default value only allows object factories defined in the java.naming module.

• The new jdk.jndi.rmi.object.factoriesFilter property specifies which object factory classes are allowed to instantiate Java objects from object references returned by JNDI/RMI contexts. Its default value only allows object factories defined in the jdk.rmi module.

These new factory filter properties complement the jdk.jndi.object.factoriesFilter global factories filter property by determining if a specific object factory is permitted to instantiate objects for the LDAP or RMI protocols used in JNDI.

An application depending on custom object factories to recreate Java objects from JNDI/LDAP or JNDI/RMI contexts will need to supply a security or system property with an updated value to allow such third-party object factories to reconstruct LDAP or RMI objects. If usage of a factory is denied, the lookup operation may result in a plain instance of javax.naming.Reference instance returned, which may lead to a ClassCastException being thrown in the application.

For more information, see the java.naming and jdk.naming.rmi module-info documentation.

Introduce LDAP and RMI Protocol Specific Object Factory Filters to JNDI Implementation

In this release, new system and security properties are introduced to allow more granular control over the set of JNDI object factories allowed to reconstruct Java objects from JNDI/LDAP and JNDI/RMI contexts:

• The new jdk.jndi.ldap.object.factoriesFilter property specifies which object factory classes are allowed to instantiate Java objects from object references returned by JNDI/LDAP contexts. Its default value only allows object factories defined in the java.naming module.

• The new jdk.jndi.rmi.object.factoriesFilter property specifies which object factory classes are allowed to instantiate Java objects from object references returned by JNDI/RMI contexts. Its default value only allows object factories defined in the jdk.naming.rmi module.

These new factory filter properties complement the jdk.jndi.object.factoriesFilter global factories filter property by determining if a specific object factory is permitted to instantiate objects for the LDAP or RMI protocols used in JNDI.

An application depending on custom object factories to recreate Java objects from JNDI/LDAP or JNDI/RMI contexts will need to supply a security or system property with an updated value to allow such third-party object factories to reconstruct LDAP or RMI objects. If usage of a factory is denied, the lookup operation may result in a plain instance of javax.naming.Reference instance returned, which may lead to a ClassCastException being thrown in the application.

Introduce LDAP and RMI Protocol Specific Object Factory Filters to JNDI Implementation

In this release, new system and security properties are introduced to allow more granular control over the set of JNDI object factories allowed to reconstruct Java objects from JNDI/LDAP and JNDI/RMI contexts:

• The new jdk.jndi.ldap.object.factoriesFilter property specifies which object factory classes are allowed to instantiate Java objects from object references returned by JNDI/LDAP contexts. By default, only object factories defined with the setting of the property 'jdk.jndi.ldap.object.factoriesFilter=com.sun.jndi.ldap.*;!' are allowed.

• The new jdk.jndi.rmi.object.factoriesFilter property specifies which object factory classes are allowed to instantiate Java objects from object references returned by JNDI/RMI contexts. By default, only object factories defined with the setting of the property jdk.jndi.rmi.object.factoriesFilter=com.sun.jndi.rmi.**;!* are allowed.

These new factory filter properties complement the jdk.jndi.object.factoriesFilter global factories filter property by determining if a specific object factory is permitted to instantiate objects for the LDAP or RMI protocols used in JNDI.

An application depending on custom object factories to recreate Java objects from JNDI/LDAP or JNDI/RMI contexts will need to supply a security or system property with an updated value to allow such third-party object factories to reconstruct LDAP or RMI objects. If usage of a factory is denied, the lookup operation may result in a plain instance of javax.naming.Reference instance returned, which may lead to a ClassCastException being thrown in the application.

Mechanism to Disable Signature Schemes Based on Their TLS Scope

TLS protocol specific usage constraints are now supported by the jdk.tls.disabledAlgorithms property in the java.security configuration file, as follows: ``` UsageConstraint: usage UsageType { UsageType }

UsageType: HandshakeSignature | CertificateSignature `` HandshakeSignaturerestricts the use of the algorithm in TLS handshake signatures.CertificateSignaturerestricts the use of the algorithm in certificate signatures. An algorithm with this constraint cannot include other usage types defined in thejdk.certpath.disabledAlgorithms` property. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter.

Mechanism to Disable TLS Cipher Suites by Pattern Matching

TLS cipher suites can be disabled with the jdk.tls.disabledAlgorithms security property in the java.security configuration file using one or more * wildcard characters. For example, "TLSRSA*" disables all cipher suites that start with "TLSRSA". Only cipher suites starting with "TLS_" are allowed to have wildcard characters.

Disable "best-fit" Mapping on Windows Command Line

Command line arguments to the Java launcher are no longer converted with Windows' "best-fit" mapping when the arguments include unmappable characters for the ANSI code page. This mapping has been intervening in the Java launcher's argument parsing. Unmappable characters are now replaced with the default replacement character, such as '?' in some cases. For rare cases, where applications need those unmappable characters on the command line, select UTF-8 in Windows Regional Settings.

Removed Four AffirmTrust Root Certificates

The following root certificates, which are deactivated and no longer in use, have been removed from the cacerts keystore:

``` + alias name "affirmtrustcommercialca [jdk]" Distinguished Name: CN=AffirmTrust Commercial, O=AffirmTrust, C=US

• alias name "affirmtrustnetworkingca [jdk]" Distinguished Name: CN=AffirmTrust Networking, O=AffirmTrust, C=US

• alias name "affirmtrustpremiumca [jdk]" Distinguished Name: CN=AffirmTrust Premium, O=AffirmTrust, C=US

• alias name "affirmtrustpremiumeccca [jdk]" Distinguished Name: CN=AffirmTrust Premium ECC, O=AffirmTrust, C=US ```

SunMSCAPI Provider Opens the Windows Local Computer Key Store in Read-Only Mode in Non-Elevated Processes

The Local Computer key store is accessed using the CERT_STORE_MAXIMUM_ALLOWED_FLAG. Since this store is typically managed by administrators for security reasons, processes are only given read-only access to specific private keys. By opening the store in read-only mode, non-elevated processes can now securely use these keys without requiring elevated permissions.