6u121 Update Release Notes

Update Release Notes Index

Java™ SE Development Kit 6, Update 121 (JDK 6u121)

July 19, 2016

The full version string for this update release is 1.6.0_121-b09 (where "b" means "build"). The version number is 6u121.

IANA Data 2016d

JDK 6u121 contains IANA time zone data version 2016d. For more information, refer to Timezone Data Versions in the JRE Software.

See JDK-8151876

Security Baselines

The security baselines for the Java Runtime Environment (JRE) at the time of the release of JDK 6u121 are specified in the following table:

JRE Family Version JRE Security Baseline (Full Version String)
6 1.6.0_121-b09

Certificate Changes

Comodo Root CA removed

The Comodo "UTN - DATACorp SGC" root CA certificate has been removed from the cacerts file.

See JDK-8141540

Sonera Class1 CA removed

The "Sonera Class1 CA" root CA certificate has been removed from the cacerts file.

See JDK-8141276

Enhancements

security-libs/javax.net.ssl

TLS v1.2 support now available

TLS v1.2 is now a TLS protocol option with the release of JDK 6u121. By default, TLSv1.0 will remain the default enabled protocol on client sockets.

As an example, both the TLSv1.1 and TLSv1.2 protocols can be enabled for use on SSL/TLS connections via SSLSocket/SSLEngine/SSLServerSocket APIs:

e.g.

sslSocket.setEnabledProtocols(new String[] { "TLSv1.1", "TLSv1.2"});

or by setting up and using a TLSv1.2 based SSLContext :

e.g.

SSLContext ctx = SSLContext.getInstance("TLSv1.2");

or by using the SSLParameters API:

e.g.

sslParameters.setProtocols(new String[] {"TLSv1.1", "TLSv1.2"});

The new jdk.tls.client.protocols System Property may also be used to control the protocols in use for a TLS connection (JDK-8151183).

One may launch their application with this property. E.g. java -Djdk.tls.client.protocols="TLSv1.2" will enable only TLSv1.2 on client SSLSockets.

Note that protocol versions specified via the new jdk.tls.client.protocols property will suppress any value set via the jdk.tls.client.enableSSLv2Hello property. SSLv2Hello can be passed to the jdk.tls.client.protocols value if necessary.
See JDK-8133817

security-libs/javax.net.ssl

Addition of the SNI extension to ClientHello

This extension is described in RFC 6066 section 3. This extension may be disabled by setting the jsse.enableSNIExtension system property to false.

security-libs/javax.net.ssl

jdk.tls.client.protocols system property added to JDK 6u

The jdk.tls.client.protocols system property is now available with the release of JDK 6u121. This property was originally introduced in JDK 8 and behaves in the same way. See JSSE UserGuide

JDK-8151159 (not public)

Changes

other-libs/corba

Improve access control to javax.rmi.CORBA.ValueHandler

The javax.rmi.CORBA.Util class provides methods that can be used by stubs and ties to perform common operations. It also acts as a factory for ValueHandlers. The javax.rmi.CORBA.ValueHandler interface provides services to support the reading and writing of value types to GIOP streams. The security awareness of these utilities has been enhanced with the introduction of a permission java.io.SerializablePermission("enableCustomValueHanlder"). This is used to establish a trust relationship between the users of the javax.rmi.CORBA.Util and javax.rmi.CORBA.ValueHandler APIs.

The required permission is "enableCustomValueHanlder" SerializablePermission. Third party code running with a SecurityManager installed, but not having the new permission while invoking Util.createValueHandler(), will fail with an AccessControlException.

This permission check behaviour can be overridden, in JDK8u and previous releases, by defining a system property, "jdk.rmi.CORBA.allowCustomValueHandler".

As such, external applications that explicitly call javax.rmi.CORBA.Util.createValueHandler require a configuration change to function when a SecurityManager is installed and neither of the following two requirements is met:

  1. The java.io.SerializablePermission("enableCustomValueHanlder") is not granted by SecurityManager.
  2. In the case of applications running on JDK8u and before, the system property "jdk.rmi.CORBA.allowCustomValueHandler" is either not defined or is defined equal to "false" (case insensitive).

Please note that the "enableCustomValueHanlder" typo will be corrected in the October 2016 releases. In those and future JDK releases, "enableCustomValueHandler" will be the correct SerializationPermission to use.
JDK-8079718 (not public)

security-libs/javax.net.ssl

Disable MD5withRSA signature algorithm in the JSSE provider

The MD5withRSA signature algorithm is now considered insecure and should no longer be used. Accordingly, MD5withRSA has been deactivated by default in the Oracle JSSE implementation by adding "MD5withRSA" to the jdk.tls.disabledAlgorithms security property. Now, both TLS handshake messages and X.509 certificates signed with MD5withRSA algorithm are no longer acceptable by default. This change extends the previous MD5-based certificate restriction (jdk.certpath.disabledAlgorithms) to also include handshake messages in TLS version 1.2. If required, this algorithm can be reactivated by removing "MD5withRSA" from the jdk.tls.disabledAlgorithms security property.

JDK-8144773 (not public)

security-libs/java.security

Support added to jarsigner for specifying timestamp hash algorithm

A new -tsadigestalg option is added to jarsigner to specify the message digest algorithm that is used to generate the message imprint to be sent to the TSA server. In older JDK releases, the message digest algorithm used was SHA-1. If this new option is not specified, SHA-256 will be used on JDK 7 Updates and later JDK family versions. On JDK 6 Updates, SHA-1 will remain the default but a warning will be printed to the standard output stream.

See JDK-8038837

security-libs/java.security

DomainCombiner will no longer consult runtime policy for static ProtectionDomain objects when combining ProtectionDomain objects

Applications which use static ProtectionDomain objects (created using the 2-arg constructor) with an insufficient set of permissions may now get an AccessControlException with this fix. They should either replace the static ProtectionDomain objects with dynamic ones (using the 4-arg constructor) whose permission set will be expanded by the current Policy or construct the static ProtectionDomain object with all the necessary permissions.

JDK-8147771 (not public)

Bug Fixes

The following are some of the notable bug fixes included in this release:

security-libs/javax.net.ssl

Fix to resolve "Unable to process PreMasterSecret, may be too big" issue

Recent JDK updates introduced an issue for applications that depend on having a delayed provider selection mechanism. The issue was introduced in JDK 8u71, JDK 7u95, and JDK 6u111. The main error seen corresponded to an exception like the following:

handling exception: javax.net.ssl.SSLProtocolException: Unable to process PreMasterSecret, may be too big

See JDK-8149017

This release also contains fixes for security vulnerabilities described in the Oracle Java SE Critical Patch Update Advisory. For a more complete list of the bug fixes included in this release, see the JDK 6u121 Bug Fixes page.