Java™ SE Development Kit 6, Update 211 (JDK 6u211)

October 16, 2018

The full version string for this update release is 1.6.0_211-b11 (where "b" means "build"). The version number is 6u211.

Please be aware that this is the final update release scheduled for JDK 6 (October of 2018):

Note:

JDK 6u211 is the last Critical Patch Update for JDK 6, which will reach the end of extended support in December 2018.  Applications running on JDK 6 that will remain in operation after December 2018 should be migrated to a newer JDK version as soon as possible. Please see the Oracle Java SE Support Roadmap for details.

IANA Data 2018e

JDK 6u211 contains IANA time zone data version 2018e. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

Changes

security-libs/javax.net.ssl

Disabled All DES TLS Cipher Suites

DES-based TLS cipher suites are considered obsolete and should no longer be used. DES-based cipher suites have been deactivated by default in the SunJSSE implementation by adding the "DES" identifier to the jdk.tls.disabledAlgorithms security property. These cipher suites can be reactivated by removing "DES" from the jdk.tls.disabledAlgorithms security property in the java.security file or by dynamically calling the Security.setProperty() method. In both cases re-enabling DES must be followed by adding DES-based cipher suites to the enabled cipher suite list using the SSLSocket.setEnabledCipherSuites() or SSLEngine.setEnabledCipherSuites() methods.

Note that prior to this change, DES40_CBC (but not all DES) suites were disabled via the jdk.tls.disabledAlgorithms security property.

See JDK-8208350

security-libs/java.security

Removal of Several Symantec Root CAs

The following Symantec root certificates are no longer in use and have been removed:

• Symantec

  • equifaxsecureca

    DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US

  • equifaxsecureglobalebusinessca1

    DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US

  • equifaxsecureebusinessca1

    DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US

  • verisignclass1g3ca

    DN: CN=VeriSign Class 1 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

  • verisignclass2g3ca

    DN: CN=VeriSign Class 2 Public Primary Certification Authority - G3, OU="(c) 1999 VeriSign, Inc. - For authorized use only", OU=VeriSign Trust Network, O="VeriSign, Inc.", C=US

  • verisignclass1g2ca

    DN: OU=VeriSign Trust Network, OU="(c) 1998 VeriSign, Inc. - For authorized use only", OU=Class 1 Public Primary Certification Authority - G2, O="VeriSign, Inc.", C=US

  • verisignclass1ca

    DN: OU=Class 1 Public Primary Certification Authority, O="VeriSign, Inc.", C=US

See JDK-8191031

security-libs/java.security

Removal of Baltimore Cybertrust Code Signing CA

The following Baltimore CyberTrust Code Signing root certificate is no longer in use and has been removed:

• baltimorecodesigningca

  DN: CN=Baltimore CyberTrust Code Signing Root, OU=CyberTrust, O=Baltimore, C=IE

See JDK-8189949

security-libs/java.security

Removal of SECOM Root Certificate

The following SECOM root certificate is no longer in use and has been removed:

• secomevrootca1

  DN: OU=Security Communication EV RootCA1, O="SECOM Trust Systems CO.,LTD.", C=JP

See JDK-8191844

security-libs/javax.crypto

Improved Cipher Inputs

The specification of javax.crypto.CipherInputStream has been clarified to indicate that this class may catch BadPaddingException and other exceptions thrown by failed integrity checks during decryption. These exceptions are not re-thrown, so the client may not be informed that integrity checks failed. Because of this behavior, this class may not be suitable for use with decryption in an authenticated mode of operation (e.g. GCM). Applications that require authenticated encryption can use the Cipher API directly as an alternative to using this class.

JDK-8201756 (not public)

Bug Fixes

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

core-libs/javax.naming

LDAPS Communication Failure

Application code using LDAPS with a socket connect timeout that is <= 0 (the default value) may encounter an exception when establishing the connection.

The top most frames from Exception stack traces of applications encountering such issues might resemble the following:

javax.naming.ServiceUnavailableException: <server:port>; socket closed
at   com.sun.jndi.ldap.Connection.readReply(Unknown Source)
at   com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source)   
...

See JDK-8211107

core-libs/java.net

Better HTTP Redirection Support

In this release, the behavior of methods which application code uses to set request properties in java.net.HttpURLConnection has changed. When a redirect occurs automatically from the original destination server to a resource on a different server, then all such properties are cleared for the redirect and any subsequent redirects. If these properties are required to be set on the redirected requests, then the redirect responses should be handled by the application by calling HttpURLConnection.setInstanceFollowRedirects(false) for the original request.

JDK-8196902 (not public)

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

Java™ SE Development Kit 6, Update 201 (JDK 6u201)

April 17, 2018

The full version string for this update release is 1.6.0_201-b07 (where "b" means "build"). The version number is 6u201.

Please be aware that there is only one more update release scheduled for JDK 6 (October of 2018):

JDK 6 will reach the end of extended support in December 2018.  Applications running on JDK 6 that will remain in operation after December 2018 should be migrated to a newer JDK version as soon as possible. Please see the Oracle Java SE Support Roadmap for details.

IANA Data 2018e

JDK 6u201 contains IANA time zone data version 2018e. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

Removed Features and Options

other-libs/javadb

Removal of Java DB

Java DB, also known as Apache Derby, has been removed in this release.

We recommend that you obtain the latest Apache Derby directly from the Apache project at: https://db.apache.org/derby

JDK-8197871 (not public)

Changes

core-libs/javax.naming

Improve LDAP support

Endpoint identification has been enabled on LDAPS connections.

To improve the robustness of LDAPS (secure LDAP over TLS) connections, endpoint identification algorithms have been enabled by default.

Note that there may be situations where some applications that were previously able to successfully connect to an LDAPS server may no longer be able to do so. Such applications may, if they deem appropriate, disable endpoint identification using a new system property: com.sun.jndi.ldap.object.disableEndpointIdentification.

Define this system property (or set it to true) to disable endpoint identification algorithms.

JDK-8200666 (not public)

core-libs/java.io:serialization

Better stack walking

New access checks have been added during the object creation phase of deserialization. This should not affect ordinary uses of deserialization. However, reflective frameworks that make use of JDK-internal APIs may be impacted. The new checks can be disabled if necessary by setting the system property jdk.disableSerialConstructorChecks to the value "true". This must be done by adding the argument -Djdk.disableSerialConstructorChecks=true to the Java command line.

JDK-8197925 (not public)

Bug Fixes

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

Java™ SE Development Kit 6, Update 191 (JDK 6u191)

April 17, 2018

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

Please be aware that there are only 2 more update releases scheduled for JDK 6 (July and October of 2018):

JDK 6 will reach the end of extended support in December 2018.  Applications running on JDK 6 that will remain in operation after December 2018 should be migrated to a newer JDK version as soon as possible. Please see the Oracle Java SE Support Roadmap for details.

IANA Data 2018c

JDK 6u191 contains IANA time zone data version 2018c. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

Notes

security-libs/javax.crypto

CipherOutputStream Usage

The specification of javax.crypto.CipherOutputStream has been clarified to indicate that this class catches BadPaddingException and other exceptions thrown by failed integrity checks during decryption. These exceptions are not re-thrown, so the client is not informed that integrity checks have failed. Because of this behavior, this class may not be suitable for use with decryption in an authenticated mode of operation (for example, GCM) if the application requires explicit notification when authentication fails. These applications can use the Cipher API directly as an alternative to using this class.

JDK-8182362 (not public)

New Features

security-libs/javax.net.ssl

TLS Session Hash and Extended Master Secret Extension Support

Support has been added for the TLS session hash and extended master secret extension (RFC 7627) in JDK JSSE provider. Note that in general, a server certificate change is restricted if endpoint identification is not enabled and the previous handshake is a session-resumption abbreviated initial handshake, unless the identities represented by both certificates can be regarded as the same. However, if the extension is enabled or negotiated, the server certificate changing restriction is not necessary and will be discarded accordingly. In case of compatibility issues, an application may disable negotiation of this extension by setting the System Property jdk.tls.useExtendedMasterSecret to false in the JDK. By setting the System Property jdk.tls.allowLegacyResumption to false, an application can reject abbreviated handshaking when the session hash and extended master secret extension are not negotiated. By setting the System Property jdk.tls.allowLegacyMasterSecret to false, an application can reject connections that do not support the session hash and extended master secret extension.

See JDK-8148421

security-libs/javax.crypto

Enhanced KeyStore Mechanisms

A new security property named jceks.key.serialFilter has been introduced. If this filter is configured, the JCEKS KeyStore uses it during the deserialization of the encrypted Key object stored inside a SecretKeyEntry. If it is not configured or if the filter result is UNDECIDED (for example, none of the patterns match), then the filter configured by jdk.serialFilter is consulted.

If the system property jceks.key.serialFilter is also supplied, it supersedes the security property value defined here.

The filter pattern uses the same format as jdk.serialFilter. The default pattern allows java.lang.Enum, java.security.KeyRep, java.security.KeyRep$Type, and javax.crypto.spec.SecretKeySpec but rejects all the others.

Customers storing a SecretKey that does not serialize to the above types must modify the filter to make the key extractable.

JDK-8189997 (not public)

Changes

security-libs/javax.net.ssl

3DES Cipher Suites Disabled

To improve the strength of SSL/TLS connections, 3DES cipher suites have been disabled in SSL/TLS connections in the JDK via the jdk.tls.disabledAlgorithms Security Property.

JDK-8175075 (not public)

core-libs/java.util.logging

New system property to control java.util.logging.FileHandler's MAX_LOCKS limit

A new JDK implementation specific system property jdk.internal.FileHandlerLogging.maxLocks is introduced to control the java.util.logging.FileHandler MAX_LOCKS limit. The default value of the current MAX_LOCKS (100) will be retained if this new System property is not set or an invalid value is provided to this property. Valid values for this property are integers ranging from 1 to Integer.MAX_VALUE-1.

See JDK-8153955

core-libs/java.util.logging

System Property Controls the java.util.logging.FileHandler's MAX_LOCKS Limit

A new JDK implementation specific system property jdk.internal.FileHandlerLogging.maxLocks has been introduced to control the java.util.logging.FileHandler MAX_LOCKS limit. The default value of the current MAX_LOCKS (100) is retained if this new system property is not set or an invalid value is provided to the property. Valid values for this property are integers ranging from 1 to Integer.MAX_VALUE-1.

See JDK-8153955

Bug Fixes

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

core-libs/java.rmi

Server-side HTTP-tunneled RMI Connections Disabled

This release disables server side HTTP-tunneled RMI connections by default. The previous behavior can be re-enabled after due consideration of any impact by setting the runtime property sun.rmi.server.disableIncomingHttp to false. Note that this should not be confused with the sun.rmi.server.disableHttp property, which disables HTTP-tunneling on the client side and is false by default.

JDK-8193833 (not public)

security-libs/java.security

Reject Signatures with Incorrect Length

Verification of an RSA signature has been made more rigorous to comply with the requirement of RFC 2313. If the length of the verified signature is not equal to the modulus of the public key, then the verification fails.

In particular, it means that the leading zeroes of the signature must not be stripped or prepended. For example, this might have happened if BigInteger were used as an intermediate representation of a signature.

If a signature needs to be transmitted using an intermediate representation, you must make sure that all of the bytes of the signature are preserved (for example, you may use BASE64 encoding).

JDK-6896700 (not public)

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

Java™ SE Development Kit 6, Update 181 (JDK 6u181)

January 16, 2018

The full version string for this update release is 1.6.0_181-b10 (where "b" means "build"). The version number is 6u181.

Please be aware that there are only 3 more update releases scheduled for JDK 6 (Apr, Jul, and Oct of 2018):

JDK 6 will reach the end of extended support in December 2018.  Applications running on JDK 6 that will remain in operation after December 2018 should be migrated to a newer JDK version as soon as possible. Please see the Oracle Java SE Support Roadmap for details.

IANA Data 2017c

JDK 6u181 contains IANA time zone data version 2017c. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

New Features

security-libs/javax.crypto

Support DHE sizes up to 8192-bits and DSA sizes up to 3072-bits

Enhance the JDK security providers to support 3072-bit DiffieHellman and DSA parameters generation, pre-computed DiffieHellman parameters up to 8192 bits and pre-computed DSA parameters up to 3072 bits.

See JDK-8072452

security-libs/javax.net.ssl

Support SHA224withDSA and SHA256withDSA in the SunJSSE provider

The SHA224withDSA and SHA256withDSA algorithms are now supported in the TLS 1.2 "signature_algorithms" extension in the SunJSSE provider. Note that this extension does not apply to TLS 1.1 and previous versions.

See JDK-8049321

other-libs/corba

Add additional IDL stub type checks to org.omg.CORBA.ORBstring_to_object method

Applications that either explicitly or implicitly call org.omg.CORBA.ORB.string_to_object, and wish to ensure the integrity of the IDL stub type involved in the ORB::string_to_object call flow, should specify additional IDL stub type checking. This is an "opt in" feature and is not enabled by default.

To take advantage of the additional type checking, the list of valid IDL interface class names of IDL stub classes is configured by one of the following:

• Specifying the security property com.sun.CORBA.ORBIorTypeCheckRegistryFilter located in the file conf/security/java.security in Java SE 9 or in jre/lib/security/java.security in Java SE 8 and earlier.

• Specifying the system property com.sun.CORBA.ORBIorTypeCheckRegistryFilter with the list of classes. If the system property is set, its value overrides the corresponding property defined in the java.security configuration.

If the com.sun.CORBA.ORBIorTypeCheckRegistryFilter property is not set, the type checking is only performed against a set of class names of the IDL interface types corresponding to the built-in IDL stub classes.

JDK-8160104 (not public)

Changes

security-libs/java.security

Refactor existing providers to refer to the same constants for default values for key length

Two important changes have been made for this issue:

1. A new system property has been introduced that allows users to configure the default key size used by the JDK provider implementations of KeyPairGenerator and AlgorithmParameterGenerator. This property is named "jdk.security.defaultKeySize" and the value of this property is a list of comma-separated entries. Each entry consists of a case-insensitive algorithm name and the corresponding default key size (in decimal) separated by ":". In addition, white space is ignored.

By default, this property will not have a value, and JDK providers will use their own default values. Entries containing an unrecognized algorithm name will be ignored. If the specified default key size is not a parseable decimal integer, that entry will be ignored as well.

2. The DSA KeyPairGenerator implementation of the SUN provider no longer implements java.security.interfaces.DSAKeyPairGenerator. Applications which cast the SUN provider's DSA KeyPairGenerator object to a java.security.interfaces.DSAKeyPairGenerator can set the system property "jdk.security.legacyDSAKeyPairGenerator". If the value of this property is "true", the SUN provider will return a DSA KeyPairGenerator object which implements the java.security.interfaces.DSAKeyPairGenerator interface. This legacy implementation will use the same default value as specified by the javadoc in the interface.

By default, this property will not have a value, and the SUN provider will return a DSA KeyPairGenerator object which does not implement the forementioned interface and thus can determine its own provider-specific default value as stated in the java.security.KeyPairGenerator class or by the "jdk.security.defaultKeySize" system property if set.

JDK-8181048 (not public)

security-libs/javax.crypto

RSA public key validation

In 6u181, the RSA implementation in the SunRsaSign provider will reject any RSA public key that has an exponent that is not in the valid range as defined by PKCS#1 version 2.2. This change will affect JSSE connections as well as applications built on JCE.

JDK-8174756 (not public)

security-libs/javax.net.ssl

Restrict Diffie-Hellman keys less than 1024 bits

Diffie-Hellman keys less than 1024 bits are considered too weak to use in practice and should be restricted by default in SSL/TLS/DTLS connections. Accordingly, Diffie-Hellman keys less than 1024 bits have been disabled by default by adding DH keySize < 1024 to the jdk.tls.disabledAlgorithms security property in the java.security file. Although it is not recommended, administrators can update the security property (jdk.tls.disabledAlgorithms) and permit smaller key sizes (for example, by setting DH keySize < 768).

JDK-8148108 (not public)

security-libs/javax.crypto

Provider default key size is updated

This change updates the JDK providers to use 2048 bits as the default key size for DSA instead of 1024 bits when applications have not explicitly initialized the java.security.KeyPairGenerator and java.security.AlgorithmParameterGenerator objects with a key size.

If compatibility issues arise, existing applications can set the system property jdk.security.defaultKeySize introduced in JDK-8181048 with the algorithm and its desired default key size.

JDK-8178466 (not public)

security-libs/javax.crypto

Stricter key generation

The generateSecret(String) method has been mostly disabled in the javax.crypto.KeyAgreement services of the SunJCE and SunPKCS11 providers. Invoking this method for these providers will result in a NoSuchAlgorithmException for most algorithm string arguments. The previous behavior of this method can be re-enabled by setting the value of the jdk.crypto.KeyAgreement.legacyKDF system property to true (case insensitive). Re-enabling this method by setting this system property is not recommended.

Prior to this change, the following code could be used to produce secret keys for AES using Diffie-Hellman:

1. KeyAgreement ka = KeyAgreement.getInstance("DiffieHellman");
2. ka.init(...);
3. ka.doPhase(...);
4. SecretKey sk = ka.generateSecret("AES");

The issue with this code is that it is unspecified how the provider should derive a secret key from the output of the Diffie-Hellman operation. There are several options for how this key derivation function can work, and each of these options has different security properties. For example, the key derivation function may bind the secret key to some information about the context or the parties involved in the key agreement. Without a clear specification of the behavior of this method, there is a risk that the key derivation function will not have some security property that is expected by the client.

To address this risk, the generateSecret(String) method of KeyAgreement was mostly disabled in the DiffieHellman services, and code like the example above will now result in a java.security.NoSuchAlgorithmException. Clients still may use the no-argument generateSecret method to obtain the raw Diffie-Hellman output, which can be used with an appropriate key derivation function to produce a secret key.

Existing applications that use the generateSecret(String) method of this service will need to be modified. Here are a few options:

1. A) Implement the key derivation function from an appropriate standard. For example, NIST SP 800-56Ar2[1] section 5.8 describes how to derive keys from Diffie-Hellman output.
2. B) Implement the following simple key derivation function:
1. 1) Call KeyAgreement.generateSecret() to get the shared secret as a byte array
2. 2) Hash the byte array produced in step 1 using SHA-256

3. 3) Pass the byte array produced in step 2 into the constructor of SecretKeySpec. This constructor also requires the standard name of the secret-key algorithm (e.g. "AES")

This is a simple key derivation function that may provide adequate security in a typical application. Developers should note that this method provides no protection against the reuse of key agreement output in different contexts, so it is not appropriate for all applications. Also, some additional effort may be required to enforce key size restrictions like the ones in Table 2 of NIST SP 800-57pt1r4[2].

3. C) Set the jdk.crypto.KeyAgreement.legacyKDF system property to "true". This will restore the previous behavior of this KeyAgreement service. This solution should only be used as a last resort if the application code cannot be modified, or if the application must interoperate with a system that cannot be modified. The "legacy" key derivation function and its security are unspecified.

   1. [1] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-56Ar2.pdf
   2. [2] https://nvlpubs.nist.gov/nistpubs/SpecialPublications/NIST.SP.800-57pt1r4.pdf

JDK-8185292 (not public)

security-libs/javax.crypto

Unlimited cryptography enabled by default

The JDK uses the Java Cryptography Extension (JCE) Jurisdiction Policy files to configure cryptographic algorithm restrictions. Previously, the Policy files in the JDK placed limits on various algorithms. This release ships with both the limited and unlimited jurisdiction policy files, with unlimited being the default. The behavior can be controlled via the new crypto.policy Security property found in the <java-home>/lib/java.security file. Refer to that file for more information on this property.

See JDK-8170157

security-libs/javax.net.ssl

Disable exportable cipher suites

To improve the strength of SSL/TLS connections, exportable cipher suites have been disabled in SSL/TLS connections in the JDK by the jdk.tls.disabledAlgorithms Security Property.

See JDK-8163237

security-libs/java.security

Disable JARs signed with DSA keys less than 1024 bits

DSA keys less than 1024 bits have been added to the jdk.jar.disabledAlgorithms Security property in the java.security file. This property contains a list of disabled algorithms and key sizes for signed JAR files. If a signed JAR file uses a disabled algorithm or key size less than the minimum length, signature verification operations will ignore the signature and treat the JAR as if it were unsigned. This can potentially occur in the following types of applications that use signed JAR files:

1. Applets or Web Start Applications
2. Standalone or Server Applications run with a SecurityManager enabled and that are configured with a policy file that grants permissions based on the code signer(s) of the JAR file.

Running jarsigner -verify -verbose on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.

For example, to check a JAR file named test.jar, use this command : jarsigner -verify -verbose test.jar

If the file in this example was signed with a weak key such as 512 bit DSA, this output would be seen:

- Signed by "CN=weak_signer"
    Digest algorithm: SHA1
    Signature algorithm: SHA1withDSA, 512-bit key (weak)

To address the issue, the JAR file will need to be re-signed with a stronger key size. Alternatively, the restrictions can be reverted by removing the applicable weak algorithms or key sizes from the jdk.jar.disabledAlgorithms security property; however, this option is not recommended. Before re-signing affected JARs, the existing signature(s) should be removed from the JAR file. This can be done with the zip utility, as follows:

zip -d test.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*.DSA'

Periodically check the Oracle JRE and JDK Cryptographic Roadmap at http://java.com/cryptoroadmap for planned restrictions to signed JARs and other security components.

JDK-8185909 (not public)

xml/jax-ws

Added wsimport tool command line option -disableXmlSecurity

The wsimport tool has been changed to disallow DTDs in Web Service descriptions, specifically:

• DOCTYPE declaration is disallowed in documents
• External general entities are not included by default
• External parameter entities are not included by default
• External DTDs are completely ignored

To restore the previous behavior:

• Set the System property com.sun.xml.internal.ws.disableXmlSecurity to true
• Use the wsimport tool command line option ???disableXmlSecurity

JDK-8182873 (not public)

core-svc/javax.management

JMX Connections need deserialization filters

New public attributes, RMIConnectorServer.CREDENTIALS_FILTER_PATTERN and RMIConnectorServer.SERIAL_FILTER_PATTERN have been added to RMIConnectorServer.java. With these new attributes, users can specify the deserialization filter pattern strings to be used while making a RMIServer.newClient() remote call and while sending deserializing parameters over RMI to server respectively.

The user can also provide a filter pattern string to the default agent via management.properties. As a result, a new attribute is added to management.properties.

Existing attribute RMIConnectorServer.CREDENTIAL_TYPES is superseded by RMIConnectorServer.CREDENTIALS_FILTER_PATTERN and has been removed.

JDK-8159377 (not public)

xml/jaxp

JDK Transform, Validation and XPath use the system-default parser

Java SE 9 changes the JDK's Transform, Validation and XPath implementations to use the JDK's system-default parser even when a third party parser is on the classpath. In order to override the JDK system-default parser, applications need to explicitly set the new System property jdk.xml.overrideDefaultParser.

1. Support through the API

The overrideDefaultParser property is supported by the following APIs:

• TransformerFactory::setFeature
• SchemaFactory::setFeature
• Validator::setFeature
• XPathFactory::setFeature

2. Support as a System property

The overrideDefaultParser property can be set through the System.setProperty.

3. Support as a JAXP system property

The overrideDefaultParser property can be set in the JAXP configuration file jaxp.properties.

4. Scope and order

The overrideDefaultParser property follows the same rule as other JDK JAXP properties in that a setting of a narrower scope takes preference over that of a wider scope. A setting through the API overrides the System property which in turn overrides that in the jaxp.properties file.

JDK-8186080 (not public)

Bug Fixes

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

Changes in Java SE 6u171 b31

Please note that fixes from prior BPR (6u161 b32) are included in this version.

Java™ SE Development Kit 6, Update 171 (JDK 6u171)

October 17, 2017

The full version string for this update release is 1.6.0_171-b13 (where "b" means "build"). The version number is 6u171.

IANA Data 2017b

JDK 6u171 contains IANA time zone data version 2017b. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

Notes

security-libs/java.security

Better keystore handling

Due to the more rigorous procedure of reading a keystore content, some keystores (particularly, those created with old versions of the JDK or with a JDK from other vendors) might need to be regenerated.

The following procedure can be used to import the keystore:

1. Before you start, create a backup of your keystore. For example, if your keystore file is /DIR/KEYSTORE, make a copy of it:

   cp /DIR/KEYSTORE /DIR/KEYSTORE.BK

   Download an older release of the JDK, prior CPU17_04, and install it in a separate location. For example: 6u161, 7u151, or 8u141. Suppose, that older JDK is installed in the directory /JDK8U141

2. Make sure that the keystore can be successfully read with the keytool from that older directory. For example, if the keystore file is located in /DIR/KEYSTORE, the following command should successfully list its content:

   /JDK8U141/bin/keytool -list /DIR/KEYSTORE

3. Import the keystore. For example:
   Copy

   
   /JDK8U141/bin/keytool -importkeystore \
   -srckeystore /DIR/KEYSTORE \
   -srcstoretype JCEKS \
   -srcstorepass PASSWORD \
   -destkeystore /DIR/KEYSTORE.NEW \
   -deststoretype JCEKS \
   -deststorepass PASSWORD

4. Verify that the newly created keystore is correct. At the very least, make sure that the keystore can be read with keytool from a newer JDK:

   /NEW_JDK/bin/keytool -list /DIR/KEYSTORE.NEW

   After successful verification, replace the old keystore with the new one:

   mv /DIR/KEYSTORE.NEW /DIR/KEYSTORE

   Keep the backup copy of the keystore at least until you are sure the imported keystore is correct.

JDK-8181370 (not public)

install

Demo references in Solaris install documentation

Demos were removed from package tar.Z bundle (JDK-7066713). There is a separate Demos&Samples bundle beginning with 7u2 b08 and 6u32 b04, but Solaris patches still contain SUNWj7dmo/SUNWj6dmo. The 64 bit packages are SUNWj7dmx/SUNWj6dmx

Demo packages should remain in the existing Solaris patches. Just because they are there doesn't mean they get installed. They will be patched only if the end user has them installed on the system.

http://docs.oracle.com/javase/7/docs/webnotes/install/solaris/solaris-jdk.html

The link above is to the Solaris OS Install Directions for the JDK. The SUNWj7dmx package is mentioned in the tar.Z portion of the directions. This is confusing to some as, according to the cited bug, the SUNWj7dmx package shouldn't be part of the tar.Z bundle.

See JDK-8175866

core-libs/java.net

Default timeouts have changed for FTP URL handler

Timeouts used by the FTP URL protocol handler have been changed from infinite to 5 minutes. This will result in an IOException from connect and read operations if the FTP server is unresponsive. For example, new URL("ftp://example.com").openStream().read(), will fail with java.net.SocketTimeoutException in case a connection or reading could not be completed within 5 minutes.

To revert this behaviour to that of previous releases, the following system properties may be used, sun.net.client.defaultReadTimeout=0, sun.net.client.defaultConnectTimeout=0

JDK-8181612 (not public)

New Features

security-libs/javax.crypto

New Security property to control crypto policy

This release introduces a new feature whereby the JCE jurisdiction policy files used by the JDK can be controlled via a new Security property. In older releases, JCE jurisdiction files had to be downloaded and installed separately to allow unlimited cryptography to be used by the JDK. The download and install steps are no longer necessary. To enable unlimited cryptography, one can use the new crypto.policy Security property. If the new Security property (crypto.policy) is set in the java.security file, or has been set dynamically using the Security.setProperty() call before the JCE framework has been initialized, that setting will be honored. By default, the property will be undefined. If the property is undefined and the legacy JCE jurisdiction files don't exist in the legacy lib/security directory, then the default cryptographic level will remain at 'limited'. To configure the JDK to use unlimited cryptography, set the crypto.policy to a value of 'unlimited'. See the notes in the java.security file shipping with this release for more information.

Note: On Solaris, it's recommended that you remove the old SVR4 packages before installing the new JDK updates. If an SVR4 based upgrade (without uninstalling the old packages) is being done on a JDK release earlier than 6u131, 7u121, 8u111, then you should set the new crypto.policy Security property in the java.security file.

Because the old JCE jurisdiction files are left in <java-home>/lib/security, they may not meet the latest security JAR signing standards, which were refreshed in 6u131, 7u121, 8u111, and later updates. An exception similar to the following might be seen if the old files are used:

Caused by: java.lang.SecurityException: Jurisdiction policy files are not signed by trusted signers!
    at javax.crypto.JceSecurity.loadPolicies(JceSecurity.java:593)
    at javax.crypto.JceSecurity.setupJurisdictionPolicies(JceSecurity.java:524)

See JDK-8157561

security-libs/java.security

Add support for the SHA224withDSA and SHA256withDSA signature algorithms and DSA keys with sizes up to 2048 bits

Support has been added for the SHA224withDSA and SHA256withDSA signature algorithms and for DSA keys with sizes up to 2048 bits. Previously, only DSA keys with sizes up to 1024 bits were supported.

See JDK-7044060

Changes

deploy

JRE 6 and JRE 7 update releases will no longer include deployment technologies

Starting with the Oct 2017 Critical Patch Update, updates for JRE 6 and JRE 7 will no longer include the Java Deployment Technologies required for launching Java applications.

If an application requires a Java SE 6 or 7 JRE, the Java Deployment technology in JRE 8 release can be used to run such applications.

If you need this functionality, please refer to the following deployment invocation methods:

• Deployment Rule Set to specify the JRE version to launch specific programs. See http://docs.oracle.com/javase/8/docs/technotes/guides/deploy/deployment_rules.html

• Java programs run from browser can explicitly ask to run with JRE 6 or 7. See JRE version selection in https://docs.oracle.com/javase/8/docs/technotes/guides/deploy/applet_dev_guide.html

• See also: Support Note: the Java SE Deployment Technology Support Lifetime (Doc ID 1640397.1)

core-libs/java.util:collections

Collections use serialization filter to limit array sizes

Deserialization of certain collection instances will cause arrays to be allocated. The ObjectInputFilter.checkInput() method is now called prior to allocation of these arrays. Deserializing instances of ArrayDeque, ArrayList, IdentityHashMap, PriorityQueue, java.util.concurrent.CopyOnWriteArrayList, and the immutable collections (as returned by List.of, Set.of, and Map.of) will call checkInput() with a FilterInfo instance whose style="font-family: Courier New;">serialClass() method returns Object[].class. Deserializing instances of HashMap, HashSet, Hashtable, and Properties will call checkInput() with a FilterInfo instance whose serialClass() method returns Map.Entry[].class. In both cases, the FilterInfo.arrayLength() method will return the actual length of the array to be allocated. The exact circumstances under which the serialization filter is called, and with what information, is subject to change in future releases.

JDK-8174109 (not public)

security-libs/java.security

New defaults for DSA keys in jarsigner and keytool

For DSA keys, the default signature algorithm for keytool and jarsigner has changed from SHA1withDSA to SHA256withDSA and the default key size for keytool has changed from 1024 bits to 2048 bits.

Users wishing to revert to the previous behavior can use the -sigalg option of keytool and jarsigner and specify SHA1withDSA and the -keysize option of keytool and specify 1024.

There are a few potential compatibility risks associated with this change:

1. If you have a script that uses the default key size of keytool to generate a DSA keypair but then subsequently specifies a specific signature algorithm, ex:

   
   keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ...
   keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ...
   
   

   it will fail with one of the following exceptions, because the new 2048-bit keysize default is too strong for SHA1withDSA:

   
   keytool error: java.security.InvalidKeyException: The security strength of SHA-1 digest algorithm is not sufficient for this key size
   keytool error: java.security.InvalidKeyException: DSA key must be at most 1024 bits
    
   

   The workaround is to remove the -sigalg option and use the stronger SHA256withDSA default or, at your own risk, use the -keysize option of keytool to specify a smaller key size (1024).

2. If you use jarsigner to sign JARs with the new defaults, previous versions (than this release) of JDK 6 and 7 do not support the stronger defaults and will not be able to verify the JAR. jarsigner -verify on an earlier release of JDK 6 or 7 will output the following error:

   
   jar is unsigned. (signatures missing or not parsable)

   If you add -J-Djava.security.debug=jar to the jarsigner command line, the cause will be output:

   
   jar: processEntry caught: java.security.NoSuchAlgorithmException: SHA256withDSA Signature not available

   If compatibility with earlier releases is important, you can, at your own risk, use the -sigalg option of jarsigner and specify the weaker SHA1withDSA algorithm.

3. If you use a PKCS11 keystore, the SunPKCS11 provider does not support the SHA256withDSA algorithm. jarsigner and some keytool commands may fail with the following exception if PKCS11 is specified with the -storetype option, ex:

   
   keytool  error: java.security.InvalidKeyException: No installed provider  supports this key: sun.security.pkcs11.P11Key$P11PrivateKey

   A similar error may occur if you are using NSS with the SunPKCS11 provider. The workaround is to use the -sigalg option of keytool and specify SHA1withDSA.

See JDK-8057810

tools

Improve javadoc generation

The Javadoc Standard Doclet documentation has been enhanced to specify that it doesn't validate the content of documentation comments for conformance, nor does it attempt to correct any errors in documentation comments. See the Conformance section in the Doclet documentation.

JDK-8179042 (not public)

Bug Fixes

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

Known Issues

deploy

Windows - There is a non-functional Java icon in control panel after installing 6u171 or 7u161

Deployment features in 6u171 and 7u161 have been removed. Installing a version of the JRE that has deployment technologies support AFTER having installed the current JRE will cause the Windows Control Panel to display a non-functional Java Control panel icon.

JDK-8185373 (not public)

Changes in Java SE 6u161 b32

Bug Fixes

Changes in Java SE 6u161 b31

Please note that fixes from prior BPR (6u151 b32) are included in this version.

Java™ SE Development Kit 6, Update 161 (JDK 6u161)

July 18, 2017

The full version string for this update release is 1.6.0_161-b13 (where "b" means "build"). The version number is 6u151.

IANA Data 2017b

JDK 6u161 contains IANA time zone data version 2017b. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

Known Issues

deploy/webstart

JAR file validation changes

After upgrading to the JDK July CPU release (8u141/7u151/6u161), when executing Java Webstart applications, customers may encounter an exception like “java.lang.SecurityException: digest missing for …” that prevents the application from loading.

The issue is observed in signed JAR files whose manifest contains package version information[1] and does not have a trailing "/" in the name of the package (e.g.: Name: org/apache/xml/resolver). While we work towards resolving this issue, in the interim, users can work-around the issue as follows:

NOTE: We recommend use of this workaround only if the distributor of the JAR files can "re-sign" the JAR files.

1. Extract the contents of the signed JAR file (e.g.: jar xf jar-file ).
2. Modify META-INF/MANIFEST.MF file and add a trailing “/” to the name of the package ( e.g.: Name: org/apache/xml/resolver/).
3. Remove the current signature files ( e.g.: rm -f META-INF/*.SF META-INF/*.RSA META-INF/*.DSA ).
4. Recreate the JAR file ( e,g.: jar cfm jar-file META-INF/MANIFEST.MF input-file(s) ).

   NOTE: You must use the jar utility. Do not use other JAR creation tools.

5. Re-sign the JAR file.

   [1] https://docs.oracle.com/javase/8/docs/technotes/guides/versioning/spec/versioning2.html#wp91706

See JDK-8184993

New Features

security-libs/java.security

Disable SHA-1 TLS Server Certificates

Any TLS server certificate chain containing a SHA-1 certificate (end-entity or intermediate CA) and anchored by a root CA certificate included by default in Oracle's JDK is now blocked by default. TLS Server certificate chains that are anchored by enterprise or private CAs are not affected. Only X.509 certificate chains that are validated by the PKIX implementation of the CertPathValidator and CertPathBuilder APIs and the SunX509 and PKIX implementations of the TrustManagerFactory API are subject to the restrictions. Third-party implementations of these APIs are directly responsible for enforcing their own restrictions.

To implement this restriction and provide more flexibility for configuring your own restrictions, additional features have been added to the jdk.certpath.disabledAlgorithms and jdk.jar.disabledAlgorithms Security Properties in the java.security file, as follows:

• jdk.certpath.disabledAlgorithms:

  Three new constraints have been added to this Security Property:

  A new constraint named jdkCA, that when set, restricts the algorithm if it is used in a certificate chain that is anchored by a trust anchor that is pre-installed in the JDK cacerts keystore. This condition does not apply to certificate chains that are anchored by other certificates, including those that are subsequently added to the cacerts keystore. Also, note that the restriction does not apply to trust anchor certificates, since they are directly trusted.

  A new constraint named denyAfter, that when set, restricts the algorithm if it is used in a certificate chain after the specified date. The restriction does not apply to trust anchor certificates, since they are directly trusted. Also, code signing certificate chains as used in signed JARs are treated specially as follows:

  • if the certificate chain is used with a signed JAR that is not timestamped, it will be restricted after the specified date

  • if the certificate chain is used with a signed JAR that is timestamped, it will not be restricted if it is timestamped before the specified date. If the JAR is timestamped after the specified date, it will be restricted.

  A new constraint named usage, that when set, restricts the algorithm if it is used in a certificate chain for the specified use(s). Three usages are initially supported: TLSServer for TLS/SSL server certificate chains, TLSClient for TLS/SSL client certificate chains, and SignedJAR for certificate chains used with signed JARs.

Multiple constraints can be combined to constrain an algorithm when delimited by '&'. For example, to disable SHA-1 TLS Server certificate chains that are anchored by pre-installed root CAs, the constraint is "SHA1 jdkCA & usage TLSServer".

• jdk.jar.disabledAlgorithms:

  A new constraint has been added named denyAfter, that when set, restricts the algorithm if it is used in a signed JAR after the specified date, as follows:

  • if the JAR is not timestamped, it will be restricted (treated as unsigned) after the specified date

  • if the JAR is timestamped, it will not be restricted if it is timestamped before the specified date. If the JAR is timestamped after the specified date, it will be restricted.

  For example, to restrict SHA1 in JAR files signed after January 1st 2018, add the following to the property: "SHA1 denyAfter 2018-01-01". The syntax is the same as the certpath property, however certificate checking will not be performed by this property.

See JDK-8176536

Changes

core-libs/java.util.jar

java.util.zip.ZipFile.getEntry() now always returns the ZipEntry instance with a / ended entry name for directory entry

The java.util.zip.ZipEntry API doc specifies "A directory entry is defined to be one whose name ends with a /". However, in previous JDK releases, java.util.zip.ZipFile.getEntry(String entryName) may return a ZipEntry instance with an entry name that does not end with / for an existing zip directory entry when

• the passed in argument entryName does not end with a /, and
• there is a matching zip directory entry with name entryName + / in the zip file.

With this release, the name of the ZipEntry instance returned from java.util.zip.ZipFile.getEntry() always ends with / for any zip directory entry.

To revert to the previous behavior, set the system property jdk.util.zip.ensureTrailingSlash to "false".

This change was made in order to fix a regression introduced in JDK 8u141 when verifying signed JARs that has caused some WebStart applications to fail to load.

See JDK-8184993

core-svc/java.lang.management

JMX Diagnostic improvements

com.sun.management.HotSpotDiagnostic::dumpHeap API is modified to throw IllegalArgumentException if the supplied file name does not end with “.hprof” suffix. Existing applications which do not provide a file name ending with the “.hprof” extension will fail with IllegalArgumentException. In that case, applications can either choose to handle the exception or restore old behaviour by setting system property 'jdk.management.heapdump.allowAnyFileSuffix' to true.

JDK-8176055 (not public)

security-libs/java.security

Message digest algorithm for jarsigner -tsadigestalg option now defaults to SHA-256

If not specified, the message digest algorithm for the -tsadigestalg option of jarsigner will default to SHA-256 (previously it was SHA-1). The -tsadigestalg option specifies the message digest algorithm that is used to generate the message imprint to be sent to the TSA server.

See JDK-8177674

xml/jax-ws

Tighter secure checks on processing WSDL files by wsimport tool

The wsimport tool has been changed to disallow DTDs in Web Service descriptions, specifically:

• DOCTYPE declaration is disallowed in documents
• External general entities are not included by default
• External parameter entities are not included by default
• External DTDs are completely ignored

  To restore the previous behavior:

• Set the System property com.sun.xml.internal.ws.disableXmlSecurity to true
• Use the wsimport tool command line option –disableXmlSecurity

  NOTE: JDK 7 and JDK 6 support for this option in wsimport will be provided via a Patch release post July CPU

JDK-8182054 (not public)

Bug Fixes

This release 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 6u161 Bug Fixes page.

Changes in Java SE 6u151 b32

Bug Fixes

Changes in Java SE 6u151 b31

Please note that fixes from prior BPR (6u141 b32) are included in this version.

Java™ SE Development Kit 6, Update 151 (JDK 6u151)

The full version string for this update release is 1.6.0_151-b10 (where "b" means "build"). The version number is 6u151.

IANA Data 2017a

JDK 6u151 contains IANA time zone data version 2017a. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

Changes

security-libs/java.security

MD5 added to jdk.jar.disabledAlgorithms Security property

This JDK release introduces a new restriction on how MD5 signed JAR files are verified. If the signed JAR file uses MD5, signature verification operations will ignore the signature and treat the JAR as if it were unsigned. This can potentially occur in the following types of applications that use signed JAR files:

• Applets or Web Start Applications
• Standalone or Server Applications that are run with a SecurityManager enabled and are configured with a policy file that grants permissions based on the code signer(s) of the JAR file.

The list of disabled algorithms is controlled via the security property, jdk.jar.disabledAlgorithms, in the java.security file. This property contains a list of disabled algorithms and key sizes for cryptographically signed JAR files.

To check if a weak algorithm or key was used to sign a JAR file, one can use the jarsigner binary that ships with this JDK. Running "jarsigner -verify" on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.

For example, to check a JAR file named test.jar, use the following command:

jarsigner -verify test.jar

If the file in this example was signed with a weak signature algorithm like MD5withRSA, the following output would be displayed:

The jar will be treated as unsigned, because it is signed with a weak algorithm that is now disabled. Re-run jarsigner with the -verbose option for more details.

More details can be displayed by using the verbose option:

jarsigner -verify -verbose test.jar

The following output would be displayed:

- Signed by "CN=weak_signer" 
    Digest algorithm: MD5 (weak) 
    Signature algorithm: MD5withRSA (weak), 512-bit key (weak) 
  Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016 
    Timestamp digest algorithm: SHA-256 
    Timestamp signature algorithm: SHA256withRSA, 2048-bit key

To address the issue, the JAR file will need to be re-signed with a stronger algorithm or key size. Alternatively, the restrictions can be reverted by removing the applicable weak algorithms or key sizes from the jdk.jar.disabledAlgorithms security property; however, this option is not recommended. Before re-signing affected JARs, the existing signature(s) should be removed from the JAR file. This can be done with the .zip utility, as follows:

zip -d test.jar 'META-INF/.SF' 'META-INF/.RSA' 'META-INF/*.DSA'

Please periodically check the Oracle JRE and JDK Cryptographic Roadmap at http://java.com/cryptoroadmap for planned restrictions to signed JARs and other security components.

JDK-8171121 (not public)

core-libs/java.net

New system property to control caching for HTTP SPNEGO connection.

A new JDK implementation specific system property to control caching for HTTP SPNEGO (Negotiate/Kerberos) connections is introduced. Caching for HTTP SPNEGO connections remains enabled by default, so if the property is not explicitly specified, there will be no behavior change.

When connecting to an HTTP server that uses SPNEGO to negotiate authentication, and when connection and authentication with the server is successful, the authentication information will then be cached and reused for further connections to the same server. In addition, connecting to an HTTP server using SPNEGO usually involves keeping the underlying connection alive and reusing it for further requests to the same server. In some applications, it may be desirable to disable all caching for the HTTP SPNEGO (Negotiate/Kerberos) protocol in order to force requesting new authentication with each new request to the server.

With this change, we now provide a new system property that allows control of the caching policy for HTTP SPNEGO connections. If jdk.spnego.cache is defined and evaluates to false, then all caching will be disabled for HTTP SPNEGO connections. Setting this system property to false may, however, result in undesirable side effects:

• Performance of HTTP SPNEGO connections may be severely impacted as the connection will need to be re-authenticated with each new request, requiring several communication exchanges with the server.
• Credentials will need to be obtained again for each new request, which, depending on whether transparent authentication is available or not, and depending on the global Authenticator implementation, may result in a popup asking the user for credentials for every new request.

JDK-8170814 (not public)

core-libs/java.net

New system property to control caching for HTTP NTLM connection.

A new JDK implementation specific system property to control caching for HTTP NTLM connection is introduced. Caching for HTTP NTLM connection remains enabled by default, so if the property is not explicitly specified, there will be no behavior change.

On some platforms, the HTTP NTLM implementation in the JDK can support transparent authentication, where the system user credentials are used at system level. When transparent authentication is not available or unsuccessful, the JDK only supports getting credentials from a global authenticator. If connection to the server is successful, the authentication information will then be cached and reused for further connections to the same server. In addition, connecting to an HTTP NTLM server usually involves keeping the underlying connection alive and reusing it for further requests to the same server. In some applications, it may be desirable to disable all caching for the HTTP NTLM protocol in order to force requesting new authentication with each new requests to the server.

With this change, we now provide a new system property that allows control of the caching policy for HTTP NTLM connections. If jdk.ntlm.cache is defined and evaluates to false, then all caching will be disabled for HTTP NTLM connections. Setting this system property to false may, however, result in undesirable side effects:

• Performance of HTTP NTLM connections may be severely impacted as the connection will need to be re-authenticated with each new request, requiring several communication exchanges with the server.
• Credentials will need to be obtained again for each new request, which, depending on whether transparent authentication is available or not, and depending on the global Authenticator implementation, may result in a popup asking the user for credentials for every new request.

JDK-8163520 (not public)

Bug Fixes

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

security-libs/javax.net.ssl

Correction of IllegalArgumentException from TLS handshake

A recent issue from the JDK-8173783 fix can cause issue for some TLS servers. The problem originates from an IllegalArgumentException thrown by the TLS handshaker code:

java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves

The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified.

See JDK-8173783

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 6u151 Bug Fixes page.

Changes in Java SE 6u141 b32

Bug Fixes

Correction of IllegalArgumentException from TLS handshake

A recent issue from the JDK-8173783 fix can cause issue for some TLS servers. The problem originates from an IllegalArgumentException thrown by the TLS handshaker code:

java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves

The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified.

See JDK-8173783

Changes in Java SE 6u141 b31

Please note that fixes from prior BPR (6u131 b32) are included in this version.

Java™ SE Development Kit 6, Update 141 (JDK 6u141)

The full version string for this update release is 1.6.0_141-b12 (where "b" means "build"). The version number is 6u141.

IANA Data 2016i

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

Security Baselines

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

Notes

core-libs/javax.naming

Improved protection for JNDI remote class loading

Remote class loading via JNDI object factories stored in naming and directory services is disabled by default. To enable remote class loading by the RMI Registry or COS Naming service provider, set the following system property to the string "true", as appropriate:

com.sun.jndi.rmi.object.trustURLCodebase
    com.sun.jndi.cosnaming.object.trustURLCodebase

JDK-8158997 (not public)

security-libs/java.security

jarsigner -verbose -verify should print the algorithms used to sign the jar

The jarsigner tool has been enhanced to show details of the algorithms and keys used to generate a signed JAR file and will also provide an indication if any of them are considered weak.

Specifically, when jarsigner -verify -verbose filename.jar is called, a separate section is printed out showing information of the signature and timestamp (if it exists) inside the signed JAR file, even if it is treated as unsigned for various reasons. If any algorithm or key used is considered weak, as specified in the Security property jdk.jar.disabledAlgorithms, it will be labeled with "(weak)".

For example:

- Signed by "CN=weak_signer"
   Digest algorithm: MD2 (weak) 
   Signature algorithm: MD2withRSA (weak), 512-bit key (weak)
 Timestamped by "CN=strong_tsa" on Mon Sep 26 08:59:39 CST 2016
   Timestamp digest algorithm: SHA-256 
   Timestamp signature algorithm: SHA256withRSA, 2048-bit key 

See JDK-8163304

New Features

security-libs/javax.xml.crypto

Added security property to configure XML Signature secure validation mode

A new security property named jdk.xml.dsig.secureValidationPolicy has been added that allows you to configure the individual restrictions that are enforced when the secure validation mode of XML Signature is enabled. The default value for this property in the java.security configuration file is:

jdk.xml.dsig.secureValidationPolicy=\
    disallowAlg http://www.w3.org/TR/1999/REC-xslt-19991116,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#rsa-md5,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#hmac-md5,\
    disallowAlg http://www.w3.org/2001/04/xmldsig-more#md5,\
    maxTransforms 5,\
    maxReferences 30,\
    disallowReferenceUriSchemes file http https,\
    noDuplicateIds,\
    noRetrievalMethodLoops

Please refer to the definition of the property in the java.security file for more information.

See JDK-8151893

core-libs/java.io:serialization

Serialization Filter Configuration

Serialization Filtering introduces a new mechanism which allows incoming streams of object-serialization data to be filtered in order to improve both security and robustness. Every ObjectInputStream applies a filter, if configured, to the stream contents during deserialization. Filters are set using either a system property or a configured security property. The value of the jdk.serialFilter patterns are described in JEP 290 Serialization Filtering and in <JRE>/lib/security/java.security. Filter actions are logged to the java.io.serialization logger, if enabled.

See JDK-8155760

core-libs/java.rmi

RMI Better constraint checking

RMI Registry and Distributed Garbage Collection use the mechanisms of JEP 290 Serialization Filtering to improve service robustness. RMI Registry and DGC implement built-in white-list filters for the typical classes expected to be used with each service. Additional filter patterns can be configured using either a system property or a security property. The sun.rmi.registry.registryFilter and sun.rmi.transport.dgcFilter property pattern syntax is described in JEP 290 and in <JRE>/lib/security/java.security.

JDK-8156802 (not public)

security-libs

Add mechanism to allow non-default root CAs to not be subject to algorithm restrictions

*New certpath constraint: jdkCA*

In the java.security file, an additional constraint named jdkCA is added to the jdk.certpath.disabledAlgorithms property. This constraint prohibits the specified algorithm only if the algorithm is used in a certificate chain that terminates at a marked trust anchor in the lib/security/cacerts keystore. If the jdkCA constraint is not set, then all chains using the specified algorithm are restricted. jdkCA may only be used once in a DisabledAlgorithm expression.

Example: To apply this constraint to SHA-1 certificates, include the following:

SHA1 jdkCA

See See JDK-8140422

Changes

security-libs/javax.net.ssl

Make 3DES as a legacy algorithm in the JSSE provider

For SSL/TLS/DTLS protocols, the security strength of 3DES cipher suites is not sufficient for persistent connections. By adding 3DES_EDE_CBC to the jdk.tls.legacyAlgorithms security property by default in JDK, 3DES cipher suites will not be negotiated unless there are no other candidates during the establishing of SSL/TLS/DTLS connections.

At their own risk, applications can update this restriction in the security property (jdk.tls.legacyAlgorithms) if 3DES cipher suites are really preferred.

JDK-8165071 (not public)

security-libs/javax.net.ssl

Improve the default strength of EC in JDK

To improve the default strength of EC cryptography, EC keys less than 224 bits have been deactivated in certification path processing (via the jdk.certpath.disabledAlgorithms Security Property) and SSL/TLS connections (via the jdk.tls.disabledAlgorithms Security Property) in JDK. Applications can update this restriction in the Security Properties and permit smaller key sizes if really needed (for example, "EC keySize < 192"). EC curves less than 256 bits are removed from the SSL/TLS implementation in JDK. The new System Property, jdk.tls.namedGroups, defines a list of enabled named curves for EC cipher suites in order of preference. If an application needs to customize the default enabled EC curves or the curves preference, please update the System Property accordingly. For example:

    jdk.tls.namedGroups="secp256r1, secp384r1, secp521r1"

Note that the default enabled or customized EC curves follow the algorithm constraints. For example, the customized EC curves cannot re-activate the disabled EC keys defined by the Java Security Properties.

See JDK-8148516

tools/javadoc(tool)

New --allow-script-in-comments option for javadoc

The javadoc tool will now reject any occurrences of JavaScript code in the javadoc documentation comments and command-line options, unless the command-line option, --allow-script-in-comments is specified.

With the --allow-script-in-comments option, the javadoc tool will preserve JavaScript code in documentation comments and command-line options. An error will be given by the javadoc tool if JavaScript code is found and the command-line option is not set.

JDK-8138725 (not public)

security-libs/javax.xml.crypto

Increase the minimum key length to 1024 for XML Signatures

The secure validation mode of the XML Signature implementation has been enhanced to restrict RSA and DSA keys less than 1024 bits by default as they are no longer secure enough for digital signatures. Additionally, a new security property named jdk.xml.dsig.SecureValidationPolicy has been added to the java.security file and can be used to control the different restrictions enforced when the secure validation mode is enabled.

The secure validation mode is enabled either by setting the xml signature property org.jcp.xml.dsig.secureValidation to true with the javax.xml.crypto.XMLCryptoContext.setProperty method, or by running the code with a SecurityManager.

If an XML Signature is generated or validated with a weak RSA or DSA key, an XMLSignatureException will be thrown with the message, "RSA keys less than 1024 bits are forbidden when secure validation is enabled" or "DSA keys less than 1024 bits are forbidden when secure validation is enabled".

JDK-8140353 (not public)

docs/release_notes

Restrict certificates with DSA keys less than 1024 bits.

DSA keys less than 1024 bits are not strong enough and should be restricted in certification path building and validation. Accordingly, DSA keys less than 1024 bits have been deactivated by default by adding "DSA keySize < 1024" to the jdk.certpath.disabledAlgorithms security property. Applications can update this restriction in the security property (jdk.certpath.disabledAlgorithms) and permit smaller key sizes if really needed (for example, "DSA keySize < 768").

JDK-8139565 (not public)

core-libs/java.net

Additional access restrictions for URLClassLoader.newInstance

Class loaders created by the java.net.URLClassLoader.newInstance methods can be used to load classes from a list of given URLs. If the calling code does not have access to one or more of the URLs, and the URL artifacts that can be accessed do not contain the required class, then a ClassNotFoundException, or similar, will be thrown. Previously, a SecurityException would have been thrown when access to a URL was denied. If required to revert to the old behavior, this change can be disabled by setting the jdk.net.URLClassPath.disableRestrictedPermissions system property.

JDK-8151934 (not public)

security-libs/javax.net.ssl

Add TLS v1.1 and v1.2 to the client list of default-enabled protocols

TLSv1.2 and TLSv1.1 are now enabled by default on the TLS client end-points. This is similar behavior to what already happens in JDK 8 releases.

See details from crypto roadmap for more details.

See JDK-7093640

security-libs

More checks added to DER encoding parsing code

More checks are added to the DER encoding parsing code to catch various encoding errors. In addition, signatures which contain constructed indefinite length encoding will now lead to IOException during parsing. Note that signatures generated using JDK default providers are not affected by this change.

JDK-8168714 (not public)

Bug Fixes

This release 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 6u141 Bug Fixes page.

Known Issues

security-libs/javax.net.ssl

IllegalArgumentException from TLS handshake

A recent issue from the JDK-8148516 fix can cause issue for some TLS servers. The problem originates from an *IllegalArgumentException* thrown by the TLS handshaker code:

java.lang.IllegalArgumentException: System property jdk.tls.namedGroups(null) contains no supported elliptic curves

The issue can arise when the server doesn't have elliptic curve cryptography support to handle an elliptic curve name extension field (if present). Users are advised to upgrade to this release. By default, JDK 7 Updates and later JDK families ship with the SunEC security provider which provides elliptic curve cryptography support. Those releases should not be impacted unless security providers are modified.

See JDK-8173783

Changes in 6u131 b32

Bug Fixes

Changes in Java SE 6u131 b31

Please note that fixes from prior BPR (6u121 b31) are included in this version.

Bug Fixes

Java™ SE Development Kit 6, Update 131 (JDK 6u131)

October 18, 2016

The full version string for this update release is 1.6.0_131-b14 (where "b" means "build"). The version number is 6u131.

IANA Data 2016f

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

See JDK-8159684

Security Baselines

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

Certificate Changes

New JCE Code Signing Root CA

In order to support longer key lengths and stronger signature algorithms, a new JCE Provider Code Signing root certificate authority has been created and its certificate added to Oracle JDK. New JCE provider code signing certificates issued from this CA will be used to sign JCE providers at a date in the near future. By default, new requests for JCE provider code signing certificates will be issued from this CA.

Existing certificates from the current JCE provider code signing root will continue to validate. However, this root CA may be disabled at some point in the future. We recommend that new certificates be requested and existing provider JARs be re-signed.

For details on the JCE provider signing process, please refer to the How to Implement a Provider in the Java Cryptography Architecture documentation.

JDK-8141340 (not public)

Changes

client-libs/java.awt

Service Menu services

The lifecycle management of AWT menu components exposed problems on certain platforms. This fix improves state synchronization between menus and their containers.

JDK-8158993 (not public)

core-libs/java.net

Disable Basic authentication for HTTPS tunneling

In some environments certain authentication schemes may be undesirable when proxying HTTPS. Accordingly, the Basic authentication scheme has been deactivated, by default, in the Oracle Java Runtime, by adding Basic to the jdk.http.auth.tunneling.disabledSchemes networking property in the net.properties file. Now, proxies requiring Basic authentication when setting up a tunnel for HTTPS will no longer succeed by default. If required, this authentication scheme can be reactivated by removing Basic from the jdk.http.auth.tunneling.disabledSchemes networking property, or by setting a system property of the same name to "" ( empty ) on the command line.

Additionally, the jdk.http.auth.tunneling.disabledSchemes and jdk.http.auth.proxying.disabledSchemes networking properties, and system properties of the same name, can be used to disable other authentication schemes that may be active when setting up a tunnel for HTTPS, or proxying plain HTTP, respectively.

JDK-8160838 (not public)

security-libs/java.security

Restrict JARs signed with weak algorithms and keys

This JDK release introduces new restrictions on how signed JAR files are verified. If the signed JAR file uses a disabled algorithm or key size less than the minimum length, signature verification operations will ignore the signature and treat the JAR file as if it were unsigned. The list of disabled algorithms is controlled via a new security property, jdk.jar.disabledAlgorithms, in the java.security file. This property contains a list of disabled algorithms and key sizes for cryptographically signed JAR files.

The following algorithms and key sizes are restricted in this release:

1. MD2 (in either the digest or signature algorithm)
2. RSA keys less than 1024 bits 

NOTE: We are planning to restrict MD5-based signatures in signed JARs in the April 2017 CPU.

To check if a weak algorithm or key was used to sign a JAR file, you can use the jarsigner binary that ships with this JDK. Running jarsigner -verify -J-Djava.security.debug=jar on a JAR file signed with a weak algorithm or key will print more information about the disabled algorithm or key.

For example, to check a JAR file named test.jar, use the following command:

jarsigner -verify -J-Djava.security.debug=jar test.jar

If the file in this example was signed with a weak signature algorithm like MD2withRSA, the following output would be displayed:

jar: beginEntry META-INF/my_sig.RSA
jar: processEntry: processing block
jar: processEntry caught: java.security.SignatureException: Signature check failed. Disabled algorithm used: MD2withRSA
jar: done with meta!
 
 

The updated jarsigner command will exit with the following warning printed to standard output: "Signature not parsable or verifiable. The jar will be treated as unsigned. The jar may have been signed with a weak algorithm that is now disabled. For more information, rerun jarsigner with debug enabled (-J-Djava.security.debug=jar)"

To address the issue, the JAR file will need to be re-signed with a stronger algorithm or key size.

Alternatively, the restrictions can be reverted by removing the applicable weak algorithms or key sizes from the jdk.jar.disabledAlgorithms security property; however, this option is not recommended. Before re-signing affected JAR files, the existing signature(s) should be removed from the JAR. This can be done with the zip utility, as follows:

zip -d test.jar 'META-INF/*.SF' 'META-INF/*.RSA' 'META-INF/*.DSA'

Please periodically check the Oracle JRE and JDK Cryptographic Roadmap at http://java.com/cryptoroadmap for planned restrictions to signed JAR files and other security components. In particular, please note the current plan is to restrict MD5-based signatures in signed JAR files in the April 2017 CPU.

To test if your JARs have been signed with MD5, add MD5 to the jdk.jar.disabledAlgorithms security property, ex:

jdk.jar.disabledAlgorithms=MD2, MD5, RSA keySize < 1024<

and then run jarsigner -verify -J-Djava.security.debug=jar on your JAR files as described above.

JDK-8155973 (not public)

Bug Fixes

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 6u131 Bug Fixes page.

Changes in Java SE 6u121 b31

Please note that fixes from prior BPR (6u115 b32) are included in this version.

Bug Fixes

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:

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.

Java SE 6 Advanced - Bundled Patch Release (BPR) - Bug Fixes and Updates

The following tables summarize changes made in all Java SE 6 Advanced BPR. Bug fixes and any other changes are listed below in date order, most current BPR first. Note that bug fixes in previous BPR are also included in the current BPR.

To determine the version of your JDK software, use the following command:

java -version

• The OS, processor architecture, server, and other hardware in use must be supported by the virtualization product.

As of Java for Business 6u16, support is available for VirtualBox, Solaris Containers and Solaris LDOMs. 

Changes in 6u115 b32

TLS v1.2 support now available

TLS v1.2 is now a TLS protocol option with this release. 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.

Bug Fixes

Changes in 6u115 b31

Please note that fixes from prior BPR (6u105 b31) are included in this version.

Bug Fixes

Java™ SE Development Kit 6, Update 115 (JDK 6u115)

The full version string for this update release is 1.6.0_115-b12 (where "b" means "build"). The version number is 6u115.

This update release contains several enhancements and changes including the following: 

IANA Data 2016a

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

Security Baselines

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

Bug Fixes

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

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

DSA signature generation is now subject to a key strength check

For signature generation, if the security strength of the digest algorithm is weaker than the security strength of the key used to sign the signature (e.g. using (2048, 256)-bit DSA keys with SHA1withDSA signature), the operation will fail with the error message: "The security strength of SHA1 digest algorithm is not sufficient for this key size."

JDK-8138593 (not public)

New system property to control re-enabling of RC4-based ciphersuites in 7u101, 6u115 releases

Setting -Djdk.tls.enableRC4CipherSuites=true adds the following RC4 based ciphersuites back to the default enabled JSSE ciphersuite list:

• TLS_ECDHE_ECDSA_WITH_RC4_128_SHA
• TLS_ECDHE_RSA_WITH_RC4_128_SHA
• TLS_ECDH_ECDSA_WITH_RC4_128_SHA
• TLS_ECDH_RSA_WITH_RC4_128_SHA
• SSL_RSA_WITH_RC4_128_SHA
• SSL_RSA_WITH_RC4_128_MD5

This system property will only have impact from the JDK 7u101 and JDK 6u115 releases. By default, RC4-based ciphersuites are not in the default enabled list. They were removed in the JDK 6u101 and JDK 7u85 releases.

See JDK-8141050.

New attribute for JMX RMI JRMP servers specifies a list of class names to use when deserializing server credentials

A new java attribute has been defined for the environment to allow a JMX RMI JRMP server to specify a list of class names. These names correspond to the closure of class names that are expected by the server when deserializing credentials. For instance, if the expected credentials were a List<string>, then the closure would constitute all the concrete classes that should be expected in the serial form of a list of Strings.

By default, this attribute is used only by the default agent with the following:

 {   
   "[Ljava.lang.String;",   
   "java.lang.String" 
 } 

Only arrays of Strings and Strings will be accepted when deserializing the credentials.

The attribute name is:

"jmx.remote.rmi.server.credential.types"

The following is an example of a user starting a server with the specified credentials class names:

Map<String, Object> env = new HashMap<>(1);

 env.put ( 
 "jmx.remote.rmi.server.credential.types",
   new String[]{
   String[].class.getName(),
   String.class.getName()
   }
   );
   JMXConnectorServer server
   = JMXConnectorServerFactory.newJMXConnectorServer(url, env, mbeanServer);

The new feature should be used by directly specifying: "jmx.remote.rmi.server.credential.types" 

JDK-8144430 (not public)

Java™ SE Development Kit 6, Update 113 (JDK 6u113)

The full version string for this update release is 1.6.0_113-b02 (where "b" means "build"). The version number is 6u113.

This update release contains several enhancements and changes including the following: 

IANA Data 2015g

JDK 6u113 contains IANA time zone data version 2015g. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

Notes

Oracle strongly recommends that Java users who have downloaded affected versions and plan future installations with these downloaded versions discard these old downloads. Java users who have installed the January 2016 Critical Patch Update versions of Java SE 6, 7, or 8 need take no action. Java users who have not installed the January 2016 Critical Patch Update versions of Java SE 6, 7, or 8 should upgrade to the Java SE 6, 7, or 8 releases from the Security Alert for CVE-2016-0603.

The demos, samples, and Documentation bundles for 6u113 are not impacted by the Security Alert for CVE-2016-0603, so version 6u111 demos, samples, and Documentation bundles remain the most up to-date version until the April Critical Patch Update release.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see the Oracle Java SE Critical Patch Update Advisory.

Java™ SE Development Kit 6, Update 111 (JDK 6u111)

The full version string for this update release is 1.6.0_111-b12 (where "b" means "build"). The version number is 6u111.

This update release contains several enhancements and changes including the following: 

IANA Data 2015g

JDK 6u111 contains IANA time zone data version 2015g. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

New Features and Changes

The following are some of the notable new features and changes in this release:

*MD5 now disabled for X509 Certificate validating*

MD5 must not be used for digital signatures where collision resistance is required. To prevent the use of X.509 certificates that include an MD5-based digital signature algorithm, MD5 has been added to the jdk.certpath.disabledAlgorithms security property. Applications should upgrade or replace certificates that include an MD5-based digital signature.

Reversing this change is possible by removing MD5 from the jdk.certpath.disabledAlgorithms security property in the java.security file. This is not recommended.

JDK-8141287 (not public)

TLS v1.1 now available

TLS v1.1 is now a TLS protocol option with the release of JDK 6u111. By default, TLSv1.0 will remain the default enabled protocol on both Client and Server sides.

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

e.g.

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

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

e.g.

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

or by using the SSLParameters API

e.g.

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

JDK-8074115 (not public)

*Modifications to jarsigner and keytool*

Modifications to jarsigner for this release

The default jarsigner signature algorithm has changed from SHA1withRSA to SHA256withRSA for RSA based keys. The default jarsigner signature algorithm has changed from SHA1withECDSA to SHA256withECDSA for EC based keys. The jarsigner default digest algorithm has been changed to SHA-256 from SHA1.

Users wishing to revert to the old behavior can use the -sigalg  <algorithm> and -digestalg  <alg> jarsigner options.

Modifications to keytool for this release

The default keysize has been increased to 2048 bits for RSA based keys. Users wishing to revert to the old behavior can use the -keysize option with the -genkeypair keytool option.

The default cert fingerprint algorithm (emitted by keytool -list, -printcert, and other subcommands) now uses SHA-1 instead of MD5.

The default keytool signature algorithm has changed from SHA1withRSA to SHA256withRSA for RSA based certificates. The default keytool signature algorithm has changed from SHA1withECDSA to SHA256withECDSA for EC based certificates.

Users wishing to revert to the old behavior can use the -sigalg  <sigalg> option with the -certreq and -genkeypair keytool options.

JDK-8139084 (not public). See JDK-6709758.

Bug Fixes

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

Running jps as root does not show all information

After the fix of JDK-8050807 (fixed in 8u31, 7u75 and 6u91), running jps as root did not show all the information from Java processes started by other users on some systems. This has now been fixed.

See JDK-8075773.

Changes in 6u105 b31

Please note that fixes from prior BPR (6u101 b31) are included in this version.

Java™ SE Development Kit 6, Update 105 (JDK 6u105)

The full version string for this update release is 1.6.0_105-b15 (where "b" means "build"). The version number is 6u105.

This update release contains several enhancements and changes including the following:

IANA Data 2015f

JDK 6u105 contains IANA time zone data version 2015f. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

JRE Expiration Date

The JRE expires whenever a new release with security vulnerability fixes becomes available. Critical patch updates, which contain security vulnerability fixes, are announced one year in advance on Critical Patch Updates, Security Alerts and Third Party Bulletin. This JRE (version 6u105) will expire with the release of the next critical patch update scheduled for January 19, 2016.

For systems unable to reach the Oracle Servers, a secondary mechanism expires this JRE (version 6u105) on February 20, 2015. After either condition is met (new release becoming available or expiration date reached), the JRE will provide additional warnings and reminders to users to update to the newer version. For more information, see JRE Expiration Date.

New Features and Changes

The following are some of the notable new features and changes in this release:

xml/jaxp

A new property "maxXMLNameLimit" is added

A new property, maxXMLNameLimit, is added to limit the maximum size of XML names, including element name, attribute name and namespace prefix and URI. It is recommended that users set the limit to the smallest possible number so that malformed XML files can be caught quickly. For more about XML processing limits, please see The Java Tutorials, Processing Limits

JDK-8086733 (not public)

Support ISO 4217 "Current funds codes" table (A.2)

This enhancement adds support for ISO 4217 table A.2 fund codes. Previously the JDK only supported those currencies listed in table A.1.

See JDK-8074350.

DHKeyPairs with Bit Lengths Greater Than 1024

DHKeyPair generation now supports use of key sizes up to 2048 bits. Key size must be multiples of 64 if less than 1024 bits, or 2048 bits.

See JDK-8062834.

Weak DES based ciphersuites no longer enabled by default

Some weak DES based ciphersuites are known to be weak and were made obsolete in TLSv1.2. Beginning with the 6u105 update release, some DES based ciphersuites will no longer be enabled by default. Applications should avoid using these weak ciphersuites. The impacted ciphersuites are:

1. SSL_RSA_WITH_DES_CBC_SHA
2. SSL_DHE_RSA_WITH_DES_CBC_SHA
3. SSL_DHE_DSS_WITH_DES_CBC_SHA

Anyone wishing to use these DES based ciphersuites can re-enable them via the setEnabledCipherSuites(String[] suites) method call available in the SSLSocket, SSLServerSocket, and SSLEngine classes.

Alternatively, if an application is setting up a TLS connection using the HttpsURLConnection class, it can use the https.cipherSuites system property to re-enable such ciphersuites. See https://docs.oracle.com/javase/6/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallationAndCustomization.

JDK-8078361 (not public)

Bug Fixes

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

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

Use Safe Prime Diffie-Hellman Groups

In the JDK SSL/TLS implementation (SunJSSE provider), safe prime Diffie-Hellman groups are used by default. Users can customize Diffie-Hellman groups with the security property, "jdk.tls.server.defaultDHEParameters".

Kerberos changes for applications running with security manager

This JDK release introduces some changes to how Kerberos requests are handled when a security manager is present.

Note that if a security manager is installed while a KerberosPricipal is being created, a {@link ServicePermission} must be granted and the service principal of the permission must minimally be inside the {@code KerberosPrincipal}'s realm.

For example, if the result of {@code new KerberosPrincipal("user")} is {@code user@EXAMPLE.COM}, then a {@code ServicePermission} with service principal {@code host/www.example.com@EXAMPLE.COM} (and any action) must be granted.

Also note that if a single GSS-API principal entity that contains a Kerberos name element without providing its realm is being created via the org.ietf.jgss.GSSName interface and a security manager is installed, then this release introduces a new requirement. A {@link javax.security.auth.kerberos.ServicePermission ServicePermission} must be granted and the service principal of the permission must minimally be inside the Kerberos name element's realm.

For example, if the result of {@link GSSManager#createName(String, Oid) createName("user", NT_USER_NAME)} contains a Kerberos name element {@code user@EXAMPLE.COM}, then a {@code ServicePermission} with service principal {@code host/www.example.com@EXAMPLE.COM} (and any action) must be granted. Otherwise, the creation will throw a {@link GSSException} containing the {@code GSSException.FAILURE} error code.

JDK-8048030 (not public)

Changes in 6u101 b31

Please note that fixes from prior BPR (6u91 b31) are included in this version.

Bug Fixes

Java™ SE Development Kit 6, Update 101 (JDK 6u101)

The full version string for this update release is 1.6.0_101-b14 (where "b" means "build") and the version number is 6u101.

Highlights

This update release contains several enhancements and changes including the following:

• New Features and Changes

IANA Data 2015d

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

Security Baselines

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

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

New Features and Changes

Ephemeral DH keys less than 768 bits deactivated

Ephemeral DH keys less than 768 bits are deactivated in JDK. New algorithm restriction DH keySize < 768 is added to Security Property jdk.tls.disabledAlgorithms.

JDK-8076328 (not public)

IBM1166 character set now available

This release adds IBM1166 character set. It provides support for cyrillic multilingual with euro for Kazakhstan. Aliases for this new character set include cp1166,ibm1166, ibm-1166, and 1166.

See JDK-8071447.

Support stronger strength ephemeral DH keys in the SunJSSE provider

The ephemeral DH key size now defaults to 1024 bits during SSL/TLS handshaking in the SunJSSE provider. A new system property, "jdk.tls.ephemeralDHKeySize", is defined to customize the ephemeral DH key sizes. This can be set to "legacy" if the older JDK behavior (DH keysize of 768 bits) is desired. The DH key size for exportable ciphersuites remains at 512 bits.

JDK-8081079 (not public)

x.509 Certificates with Short Key Length are now Restricted

Starting from JDK 6u101, the use of x.509 certificates with RSA keys less than 1024 bits in length is restricted. This restriction is applied via the Java Security property, jdk.certpath.disabledAlgorithms. The default value of jdk.certpath.disabledAlgorithms is now as follows:

In order to avoid the compatibility issue, users who use X.509 certificates with RSA keys less than 1024 bits, are recommended to update their certificates with stronger keys. As a workaround, at their own risk, users can adjust the key size to permit smaller key sizes through the security property jdk.certpath.disabledAlgorithms. This change was earlier introduced in JDK 8 and JDK 7u40.

Issues with Third party's JCE Providers

The fix for JDK-8023069 updated both the SunJSSE and and SunJCE providers, including some internal interfaces.

Some third party JCE providers (such as RSA JSAFE) are using some sun.* internal interfaces, and therefore will not work with the updated SunJSSE provider. Such providers will need to be updated in order for them to work with the updated SunJSSE provider.

If you have been impacted by this issue, contact your JCE vendor for an update.

See 8133503.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory.

For a list of bugfixes included in this release, see 6u101 Bug Fixes page.

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

Area: security-libs/java.security

Synopsis: Remove old Valicert Class 1 and 2 Policy roots

Removed two root certificates with 1024-bit keys:

  1. ValiCert Class 1 Policy Validation Authority
      alias: secomvalicertclass1ca
      DN: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, 
      OU=ValiCert Class 1 Policy Validation Authority, O="ValiCert, Inc.", 
      L=ValiCert Validation Network

  2. ValiCert Class 2 Policy Validation Authority
      alias: valicertclass2ca
      DN: EMAILADDRESS=info@valicert.com, CN=http://www.valicert.com/, 
      OU=ValiCert Class 2 Policy Validation Authority, O="ValiCert, Inc.", 
      L=ValiCert Validation Network

See JDK-8077888 (not public)

Area: security-libs/java.security

Synopsis: Remove old Thawte roots

Removed two root certificates with 1024-bit keys:

1. Thawte Server CA
    alias: thawteserverca
    DN: EMAILADDRESS=server-certs@thawte.com, CN=Thawte Server CA, 
    OU=Certification Services Division, O=Thawte Consulting cc, 
    L=Cape Town, ST=Western Cape, C=ZA

2. Thawte Personal Freemail CA
    alias: thawtepersonalfreemailca
    DN: EMAILADDRESS=personal-freemail@thawte.com, 
    CN=Thawte Personal Freemail CA, OU=Certification Services Division, 
    O=Thawte Consulting, L=Cape Town, ST=Western Cape, C=ZA

See JDK-8074485 (not public)

Area: security-libs/java.security

Synopsis: Remove more old Verisign, Equifax, and Thawte roots

Removed five root certificates with 1024-bit keys:

1. Verisign Class 3 Public Primary Certification Authority - G2
    alias: verisignclass3g2ca
    DN: OU=VeriSign Trust Network, 
    OU="(c) 1998 VeriSign, Inc. - For authorized use only", 
    OU=Class 3 Public Primary Certification Authority - G2, 
    O="VeriSign, Inc.", C=US

2. Thawte Premium Server CA
    alias: thawtepremiumserverca
    DN: EMAILADDRESS=premium-server@thawte.com, CN=Thawte Premium Server CA, 
    OU=Certification Services Division, O=Thawte Consulting cc, L=Cape Town, 
    ST=Western Cape, C=ZA

3. Equifax Secure Certificate Authority
    alias: equifaxsecureca
    DN: OU=Equifax Secure Certificate Authority, O=Equifax, C=US

4. Equifax Secure eBusiness CA-1
    alias: equifaxsecureebusinessca1
    DN: CN=Equifax Secure eBusiness CA-1, O=Equifax Secure Inc., C=US

5. Equifax Secure Global eBusiness CA-1,
    alias: equifaxsecureglobalebusinessca1
    DN: CN=Equifax Secure Global eBusiness CA-1, O=Equifax Secure Inc., C=US

See JDK-8076204 (not public)

Area: security-libs/java.security

Synopsis: Remove TrustCenter CA roots from cacerts

Removed three root certificates:

1. TC TrustCenter Universal CA I
    alias: trustcenteruniversalcai
    DN: CN=TC TrustCenter Universal CA I, OU=TC TrustCenter Universal CA, 
    O=TC TrustCenter GmbH, C=DE

2. TC TrustCenter Class 2 CA II
    alias: trustcenterclass2caii
    DN: CN=TC TrustCenter Class 2 CA II, OU=TC TrustCenter Class 2 CA, 
    O=TC TrustCenter GmbH, C=DE

3. TC TrustCenter Class 4 CA II
    alias: trustcenterclass4caii
    DN: CN=TC TrustCenter Class 4 CA II, OU=TC TrustCenter Class 4 CA, 
    O=TC TrustCenter GmbH, C=DE

See JDK-8072960 (not public)

Area: security-libs/javax.net.ssl

Synopsis: Deprecate RC4 in SunJSSE provider

RC4 is now considered as a weak cipher. Server should not select RC4 unless there is no other stronger candidate in the client requested cipher suites. A new security property, jdk.tls.legacyAlgorithms, is added to define the legacy algorithms in Oracle JSSE implementation. RC4 related algorithms are added to the legacy algorithms list.

See JDK-8074008 (not public).

Area: security-libs/javax.net.ssl

Synopsis: Prohibit RC4 cipher suites

RC4 is now considered as a compromised cipher. RC4 cipher suites have been removed from both client and server default enabled cipher suite list in Oracle JSSE implementation. These cipher suites can still be enabled by SSLEngine.setEnabledCipherSuites() and SSLSocket.setEnabledCipherSuites() methods.

See JDK-8077111 (not public).

Area: security-libs/javax.net.ssl

Synopsis: Improved certification checking

With this fix, JSSE endpoint identification does not perform reverse name lookup for IP addresses by default in JDK.

If an application does need to perform reverse name lookup for raw IP addresses in SSL/TLS connections, and encounter endpoint identification compatibility issue, System property "jdk.tls.trustNameService" can be used to switch on reverse name lookup. Note that if the name service is not trustworthy, enabling reverse name lookup may be susceptible to MITM attacks.

See JDK-8067697 (not public).

Known Issues

Area: deploy

Synopsis: JNLP files won't launch from IE11 on Windows 10 Creators Update

Web-start applications cannot be launched when clicking JNLP link from IE 11 on Windows 10 Creators Update when 64-bit JRE is installed. Workaround is to uninstall 64-bit JRE and use only 32-bit JRE.

See JDK-8185661.

Changes in 6u95

The full version string for this update release is 1.6.0_95-b12 (where "b" means "build") and the version number is 6u95.

IANA Data 2015a

JDK 6u95 contains IANA time zone data version 2015a. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

Blacklist Entries

A new blacklist entry is included in this release.

For more details on the entry, see the related Cisco Security Advisory.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory.

For a list of bugfixes included in this release, see 6u95 Bug Fixes page.

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

Area: tools/jar

Synopsis: Improve jar file handling

Starting with JDK 6u95 release, the jar tool no longer allows the leading slash "/" and ".." (dot-dot) path component in zip entry file name when creating new and/or extracting from zip and jar file. If needed, the new command line option "-P" should be used explicitly to preserve the dot-dot and/or absolute path component.

See 8064601 (not public).

Area: security-libs/javax.net.ssl

Synopsis: The EXPORT suites have been removed from the default enabled ciphersuite list.

The EXPORT strength ciphersuites (such as SSL_RSA_EXPORT_WITH_DES40_CBC_SHA, SSL_RSA_EXPORT_WITH_RC4_40_MD5) were recently shown as too weak to be practically used in secure communications. They are no longer enabled by default.

See 8074458 (not public).

Changes in 6u91 b31

Please note that fixes from prior BPR (6u85 b31) are included in this version.

Bug Fixes

Changes in 6u91

The full version string for this update release is 1.6.0_91-b13 (where "b" means "build") and the version number is 6u91.

Highlights

This update release contains several enhancements and changes including the following:

• New Features and Changes

IANA Data 2014j

JDK 6u91 contains IANA time zone data version 2014j. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

New Features and Changes

SSLv3 is disabled by default

Starting with JDK 6u91 release, the SSLv3 protocol (Secure Socket Layer) has been deactivated and is not available by default. See the java.security.Security property jdk.tls.disabledAlgorithms in <JRE_HOME>/lib/security/java.security file.

If SSLv3 is absolutely required, the protocol can be reactivated by removing "SSLv3" from the jdk.tls.disabledAlgorithms property in the java.security file or by dynamically setting this Security property to "true" before JSSE is initialized.

It should be noted that SSLv3 is obsolete and should no longer be used.

Starting with JDK 6u91 release, SSLv3 protocol is removed from Java Control Panel Advanced options.

If the user needs to use SSLv3 for applications, re-enable it manually as follows:

• Enable SSLv3 protocol on JRE level: as described in the previous section.
• Enable SSLv3 protocol on deploy level: edit the deployment.properties file and add the following:

  deployment.security.SSLv3=true

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory.

For a list of bug fixes included in this release, see 6u91 Bug Fixes page.

Area: security-libs/javax.net.ssl

Synopsis: client side SSLv2Hello is deactivated.

As part of disabling SSLv3, some servers have also disabled SSLv2Hello, which means communications with SSLv2Hello-active clients (e.g. JDK 1.5/6) will fail. SSLv2Hello is now disabled by default.

If the pre-6u91 SSLv2Hello behavior is required, set the java.lang.System property jdk.tls.client.enableSSLv2Hello to "true" before JSSE is initialized.

See 8061765 (not public).

Changes in 6u85 b31

Please note that fixes from prior BPR (6u81 b32) are included in this version.

Bug Fixes

Changes in 6u85

The full version string for this update release is 1.6.0_85-b13 (where "b" means "build") and the version number is 6u85.

IANA Data 2014c

JDK 6u85 contains IANA time zone data version 2014c. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

Unsafe Server Certificate Change in SSL/TLS Renegotiations Not Allowed.

Starting with JDK 6u85, unsafe server certificate change in SSL/TLS renegotiations is not allowed by default. Server certificate change in an SSL/TLS renegotiation may be unsafe and should be restricted:

• if endpoint identification is not enabled in an SSL/TLS handshaking; and
• if the previous handshake is a session-resumption abbreviated initial handshake; and
• the identities represented by both certificates (in previous handshake and this handshake) cannot be regraded as the same.

If unsafe server certificate change is really required, please set the system property, jdk.tls.allowUnsafeServerCertChange, to "true" before JSSE is initialized. Note that this would re-establish the unsafe server certificate change issue.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory.

For a list of bugfixes included in this release, see 6u85 Bug Fixes page.

Area: security-libs/javax.net.ssl

Synopsis: Decrease the preference mode of RC4 in the enabled cipher suite list

This fix decreases the preference of RC4 based cipher suites in the default enabled cipher suite list of SunJSSE provider.

See 8043200 (not public).

Changes in 6u81 b32

Bug Fixes

Changes in 6u81 b31

Please note that fixes from prior BPR (6u75 b31) are included in this version.

Bug Fixes

Changes in 6u81

The full version string for this update release is 1.6.0_81-b08 (where "b" means "build") and the version number is 6u81.

IANA Data 2014c

JDK 6u81 contains IANA time zone data version 2014c. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Critical Patch Update Advisory.

For a list of bug fixes included in this release, see 6u81 Bug Fixes page.

Changes in 6u75 b31

Please note that fixes from prior BPR (6u71 b33) are included in this version.

Java™ SE Development Kit 6, Update 75 (JDK 6u75)

The full version string for this update release is 1.6.0_75-b13 (where "b" means "build") and the version number is 6u75.

Olson Data 2013i

JDK 6u75 contains Olson time zone data version 2013i. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Critical Patch Update Advisory.

For a list of bugfixes included in this release, see 6u75 Bug Fixes page.

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

Area: other-libs/corba

Synopsis: Enhanced CORBA initializations

The system property org.omg.CORBA.ORBSingletonClass is used to configure the system-wide/singleton ORB. The handling of this system property has changed to require that the system wide/singleton ORB be visible to the system class loader. This is a change from previous releases where the singleton ORB was located using the thread context class loader of the first thread to call the no-argument ORB.init method. The implication of this change is that the system-wide/singleton ORB needs to be deployed on the class path or in the extension directory.

Applications that bundle their own ORB and only configure the property org.omg.CORBA.ORBClass should not be impacted by this change. The per-application ORB will be located via the thread context class loader of the thread calling the 2-argument ORB.init method as before.

See 8025005 (not public).

Area: xml/jaxp

Synopsis: Custom entities mapping files are no longer loaded with full permission

Legacy code may use the JDK internal API SerializerFactory to create a Serializer. In the process, a custom entity mapping file may be specified through the format parameter. The custom file was then loaded with full permission. As of this release, files that complies with java.util.ResourceBundle format, that is, with a ".properties" extension, will continue to be loaded with full permission. However, any other custom mapping files will require specific file access permission when the program is running with a SecurityManager.

The workaround to any issues caused by lack of permission to using an arbitrary file as the entity mapping file is, either changing the file to a resource bundle, or granting file read permission.

See 8029282 (not public).

Changes in 6u71 b33

Bug Fixes

Changes in 6u71 b32

Bug Fixes

Changes in 6u71 b31

Please note that fixes from prior BPR (6u65 b34) are included in this version.

Java™ SE Development Kit 6, Update 71 (JDK 6u71)

The full version string for this update release is 1.6.0_71-b12 (where "b" means "build") and the version number is 6u71.

JDK 6u71 contains Olson time zone data version 2013h. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory.

For a list of bug fixes included in this release, see JDK 6u71 Bug Fixes page.

Known Issues

Area: corelibs/java.nio

Synopsis: (java.nio) NativeThreadSet.remove may throw ArrayIndexOutOfBoundsException (6uX only)

Simultaneous multiple thread operations on the same FileChannel can create a scenario where the NativeThreadSet buffer needs to grow and a subsequent removal operation can lead to negative array index reference. A stack similar to this would be seen:

java.lang.ArrayIndexOutOfBoundsException: -1
at sun.nio.ch.NativeThreadSet.remove(NativeThreadSet.java:54)
at sun.nio.ch.FileChannelImpl.position(FileChannelImpl.java:257)

A JDK 6u71 based fix is available. If you encounter such an issue, please contact Oracle Support.

Changes in 6u65 b34

Bug Fixes

Changes in 6u65 b33

Bug Fixes

Changes in 6u65 b32

Please note that fixes from prior BPR (6u60 b31) are included in this version.

Java™ SE Development Kit 6, Update 65 (JDK 6u65)

The full version string for this update release is 1.6.0_65-b14 (where "b" means "build") and the version number is 6u65.

JDK 6u65 contains Olson time zone data version 2013d. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

Blacklist Entries

This update release includes a blacklist entry for a standalone JavaFX installer.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory.

Changes in 6u60 b31

Bug Fixes

Changes in 6u60

The full version string for this update release is 1.6.0_60-b07 (where "b" means "build") and the version number is 6u60.

Olson Data 2013d

JDK 6u60 contains Olson time zone data version 2013d. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

Bug Fixes

For a list of bug fixes included in this release, see JDK 6u60 Bug Fixes page.

Known Issues

Area: Deployment/PlugIn

Synopsis: JavaScript-> Java (LiveConnect) call fails silently if JavaScript/HTML and unsigned JAR/class files comes from different codebase host

If the portion of the codebase that specifies the protocol, host, and port, are not the same for the unsigned JAR file (or class files) as for the JavaScript or HTML, the code will fail without a mixed code dialog warning.

You can work around this using one of the following approaches:

• Put the JAR files (or class files) and the HTML/JavaScript on the same host.
• Sign the JAR files. (Self signed can cause the LiveConnect dialog to show already; or add a manifest file that specifies the Caller-Allowable-Codebase attribute.)
• Use the Deployment Rule Set (DRS) to allow the app and HTML to run without a warning.

When specifying the codebase, using the Caller-Allowable-Codebase attribute or the Deployment Rule Set, make sure to list the domain where the JavaScreipt/HTML is hosted.

Changes in 6u51 b32

Bug Fixes

Changes in 6u51 b31

Bug Fixes

Changes in 6u51

The full version string for this update release is 1.6.0_51-b11 (where "b" means "build") and the version number is 6u51.

Olson Data 2013b

JDK 6u51 contains Olson time zone data version 2013b. For more information, refer to Timezone Data Versions in the JRE Software.

Security Baselines

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

For more information about security baselines, see Deploying Java Applets With Family JRE Versions in Java Plug-in for Internet Explorer.

Change in Networking API Implementation on Windows platforms

The implementation of the networking APIs has been changed on Windows to use the SO_EXCLUSIVEADDRUSE socket option by default. This change is necessary to address anomalies that arise when using both IPv4 and IPv6 applications that require to bind to the same port.

This change may cause issues for applications that rely on the ability to have multiple processes bound to the same address and port. When such issues occur,  use sun.net.useExclusiveBind system property as a temporary workaround to restore legacy behavior.

Bug Fixes

This release contains fixes for security vulnerabilities. For more information, see Oracle Java SE Critical Patch Update Advisory.

Changes in 6u45

For details, refer to the JDK 6u45 Update Release Notes.

Changes in 6u43 b31

Bug Fixes

Changes in 6u43

For details, refer to the JDK 6u43 Update Release Notes.

Changes in 6u41

For details, refer to the JDK 6u41 Update Release Notes.

Changes in 6u39

For details, refer to the JDK 6u39 Update Release Notes.

Changes in 6u38 b31

Please note that fixes from prior BPR (6u37 b32) are included in this version.

Changes in 6u38

For details, refer to the JDK 6u38 Update Release Notes.

Changes in 6u37 b32

Bug Fixes

Changes in 6u37 b31

Please note that fixes from prior BPR (6u35 b32) are included in this version.

Changes in 6u37

For details, refer to the JDK 6u37 Update Release Notes.

Changes in 6u35 b32

Bug Fixes

Changes in 6u35 b31

Bug Fixes

Changes in 6u35

Please note that fixes included in the immediately prior BPR are NOT included in 6u35. These fixes will be available in the first BPR based on 6u35.

For further details, refer to the JDK 6u35 Update Release Notes.

Changes in 6u34 b32

Bug Fixes

Changes in 6u34 b31

Please note that fixes from prior BPR (6u33 b33) are included in this version.

Bug Fixes

Changes in 6u34

Please note that fixes included in the immediately prior BPR are NOT included in 6u34. These fixes will be available in the first BPR based on 6u34.

For further details, refer to the JDK 6u34 Update Release Notes.

Changes in 6u33 b33

Bug Fixes

Changes in 6u33 b32

Bug Fixes

Changes in 6u33 b31

Please note that fixes from prior BPR (6u32 b32) are included in this version.

Bug Fixes

Changes in 6u33

Please note that fixes included in the immediately prior BPR are NOT included in 6u33. These fixes will be available in the first BPR based on 6u33.

For further details, refer to the JDK 6u33 Update Release Notes.

Changes in 6u32 b32

Bug Fixes

Changes in 6u32 b31

Please note that fixes from prior BPR (6u31-rev) are included in this version.

Version Name Changed

The following changes were made to the output of the command java -version to releases starting from 6u32 and BPR releases:

• The string "rev" was removed from the version name of the BPR (for example, 1.6.0_32-b31).
• The text "for Business" was removed from the output of the command.

In addition, the string "fb" was removed from the bundle name (the file name of the installer).

Changes in 6u32

Please note that fixes included in the immediately prior BPR are NOT included in 6u32. These fixes will be available in the first BPR based on 6u32.

For further details, refer to the JDK 6u32 Update Release Notes.

Changes in 6u31-rev-b25

Bug Fixes

Changes in 6u31-rev-b24

Bug Fixes

Changes in 6u31-rev-b23

Bug Fixes

Changes in 6u31-rev-b22

Bug Fixes

Changes in 6u31-rev-b21

Please note that fixes from prior BPR (6u30-rev) are included in this version.

Changes in 6u31-rev-b20

Please note that fixes included in the immediately prior BPR are NOT included in 6u31-rev-b20. These fixes will be available in the next BPR based on 6u31.

For further details, refer to the JDK 6u31 Update Release Notes.

Changes in 6u30-rev-b23

Bug Fixes

Changes in 6u30-rev-b22

Bug Fixes

Changes in 6u30-rev-b21

Please note that fixes from prior BPR (6u29-rev) are included in this version.

For further details, refer to the JDK 6u30 Update Release Notes.

Changes in 6u29-rev-b22

Bug Fixes

Changes in 6u29-rev-b21

Please note that fixes from prior BPR (6u27-rev) are included in this version.

For further details, refer to the JDK 6u29 Update Release Notes.

Changes in 6u27-rev-b23

Bug Fixes

Changes in 6u27-rev-b22

Bug Fixes

Changes in 6u27-rev-b21

Bug Fixes

Changes in 6u27-rev-b20

Please note that fixes from prior BPR (6u26-rev) are included in this version.

Changes in 6u27

Please note that fixes included in the immediately prior BPR are NOT included in 6u27. These fixes will be available in the first BPR based on 6u27.

For further details, refer to the JDK 6u27 Update Release Notes.

Changes in 6u26-rev-b25

Bug Fixes

Changes in 6u26-rev-b23

Bug Fixes

Changes in 6u26-rev-b22

Bug Fixes

Changes in 6u26-rev-b21

Please note that fixes from prior BPR (6u25-rev) are included in this version.

Changes in 6u26

Please note that fixes included in the immediately prior BPR are NOT included in 6u26. These fixes will be available in the first BPR based on 6u26.

For further details, refer to the JDK 6u26 Update Release Notes.

Changes in 6u25-rev-b21

OlsonData 2011e

Please note that fixes from prior BPR (6u24-rev) are included in this version.

Bug Fixes

Changes in 6u25

Please note that fixes included in the immediately prior BPR are NOT included in 6u25. These fixes will be available in the first BPR based on 6u25.

For further details, refer to the JDK 6u25 Update Release Notes.

Changes in 6u24-rev-b25

OlsonData 2011d

Bug Fixes

Changes in 6u24-rev-b24

Bug Fixes

Changes in 6u24-rev-b23

OlsonData 2011b

Bug Fixes

Changes in 6u24-rev-b22

Please note that fixes from prior BPR (6u22-rev) are included in this version.

Changes in 6u24

Please note that fixes included in the immediately prior BPR are NOT included in 6u24. These fixes will be available in the first BPR based on 6u24.

For further details, refer to the JDK 6u24 Update Release Notes.

Changes in 6u23

Please note that fixes included in the immediately prior BPR are NOT included in 6u23.

For further details, refer to the JDK 6u23 Update Release Notes.

Changes in 6u22-rev-b09

Bug Fixes

Changes in 6u22-rev-b08

Bug Fixes

Changes in 6u22-rev-b07

Bug Fixes

Changes in 6u22-rev-b06

Bug Fixes

Changes in 6u22-rev-b05

Please note that fixes from prior BPR (6u21-rev) are included in this version.

Changes in 6u22

For further details, refer to the JDK 6u22 Update Release Notes.

Changes in 6u21-rev-b11

Bug Fixes

Changes in 6u21-rev-b10

OlsonData 2010l

Bug Fixes

Changes in 6u21-rev-b09

OlsonData 2010k

Disabling mmap Usage (on Solaris or Linux)

Bug Fixes

Changes in 6u21-rev-b08

Please note that fixes from prior BPR (6u20-rev) are included in this version.

Bug Fixes

Changes in 6u21

For further details, refer to the JDK 6u21 Update Release Notes.

Changes in 6u20-rev-b09

Bug Fixes

Changes in 6u20-rev-b07

Bug Fixes

Changes in 6u20-rev-b05

OlsonData 2010i

Bug Fixes

Changes in 6u20-rev-b03

Please note that fixes from prior BPR (6u19-rev) are included in this version.

Bug Fixes

Changes in 6u20

For further details, refer to the JDK 6u20 Update Release Notes.

Changes in 6u19-rev-b07

Bug Fixes

Changes in 6u19-rev-b06

Bug Fixes

Changes in 6u19-rev-b05

Please note that fixes from prior BPR (6u18-rev) are included in this version.

Bug Fixes

Changes in 6u19

For further details, refer to the JDK 6u19 Update Release Notes.

Changes in 6u18-rev-b09

Bug Fixes

Changes in 6u18

For further details, refer to the JDK 6u18 Update Release Notes.

Changes in 6u17-rev-b12

Bug Fixes

Changes in 6u17-rev-b10

IETF TLS protocol

Bug Fixes

Changes in 6u17-rev-b09

Bug Fixes

Changes in 6u17-rev-b08

Bug Fixes

Changes in 6u17-rev-b07

Bug Fixes

Changes in 6u17-rev-b06

Bug Fixes

Changes in 6u17-rev-b05

Please note that fixes from prior BPR (6u16-rev) are included in this version.

Changes in 6u17

For further details, refer to the JDK 6u17 Update Release Notes.

Changes in 6u16-rev-b04

Bug Fixes

Changes in 6u16-rev-b03

Bug Fixes

Changes in 6u16-rev-b02

Bug Fixes

Please note that fixes from prior BPR (6u15-rev) are included in this version.

Changes in 6u16

For further details, refer to the JDK 6u16 Update Release Notes.

Changes in 6u15-rev-b04

Bug Fixes

Please note that fixes from prior BPR (6u14-rev) are included in this version.

Changes in 6u15

For details, refer to the JDK 6u15 Update Release Notes.

Changes in 6u14-rev-b09

Bug Fixes

Please note that fixes from prior BPR (6u13-rev) are included in this version.

Changes in 6u14

For details, refer to the JDK 6u14 Update Release Notes.

Changes in 6u13-rev-b08

Bug Fixes

Changes in 6u13-rev-b07

Bug Fixes

Changes in 6u13-rev-b06

Bug Fixes

Changes in 6u13-rev-b05

Bug Fixes

Changes in 6u13-rev-b04

Bug Fixes

Please note that fixes from prior BPR (6u12-rev) are included in this version.

Changes in 6u13

For details, refer to the JDK 6u13 Update Release Notes.

Changes in 6u12-rev-b06

Bug Fixes

Changes in 6u12-rev-b05

OlsonData 2009a

Bug Fixes

Please note that fixes from prior BPR (6u11-rev) are included in this version.

Changes in 6u12

For details, refer to the JDK 6u12 Update Release Notes.

Changes in 6u11-rev-b07

Bug Fixes

Changes in 6u11-rev-b06

Bug Fixes

Changes in 6u11-rev-b05

Bug Fixes

Changes in 6u11-rev-b04

Bug Fixes

Please note that fixes from prior BPR (6u7-rev) are included in this version.

Changes in 6u11

For details, refer to the JDK 6u11 Update Release Notes.

Changes in 6u7-rev-b15

Bug Fixes

Changes in 6u7-rev-b14

Bug Fixes

Changes in 6u10

For details, refer to the JDK 6u10 Update Release Notes.

Changes in 6u7-rev-b13

Bug Fixes

Changes in 6u7-rev-b12

Bug Fixes

Changes in 6u7-rev-b08

Bug Fixes

Changes in 6u7-rev-b07

Bug Fixes

Changes in 6u7

Bug Fixes

Changes in 6u6-rev-b03

Auto Update Off

Beginning with this BPR, the JRE auto update feature defaults to OFF.

Auto Update behavior may be unpredictable if this BPR is co-installed with any other Java SE implementation (Java for Business or Java SE) that does not have the auto update scheduler already turned off (AU-OFF). Results will also be unpredictable if this BPR for Java for Business is installed and then subsequently a Java SE Update is installed with auto update turned on (the default for Java SE).

To workaround this problem, ensure that any other Java SE implementation residing on a system has auto update turned off prior to installing this BPR or a subsequent BPR. Or else, remove any other Java SE implementation before installing this or a subsequent BPR.

Bug Fixes