For information about bug fixes and changes in Java SE 6 Updates, see the release notes for JDK at:
http://www.oracle.com/technetwork/java/javase/overview-156328.html
Note:
JRockit R28.3.20 is the last Critical Patch Update for JRockit and as noted in Oracle Fusion Middleware Lifetime Support Policy will reach End of Extended Support Life in December 2018. All customers are strongly encouraged to migrate to a later release before that date.It contains the following topics:
This section describes the changes in Oracle JRockit JDK R28.3.20:
Note:
JRockit R28.3.20 is the last Critical Patch Update for JRockit and as noted in Oracle Fusion Middleware Lifetime Support Policy will reach End of Extended Support Life in December 2018. All customers are strongly encouraged to migrate to a later release before that date.JRockit R28.3.20 is upgraded to JDK 6u211. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.
security-libs/javax.net.ssl
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
The following Symantec root certificates are no longer in use and have been removed:
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
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
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
core-libs
The JAR file specification states that URLs in the Class-Path manifest attribute must be relative, though this has not been enforced. To better conform to the JAR specification, absolute URLs (those that include a scheme) are now ignored. For JAR files not loaded from the file system, Class-Path entries navigating to a parent directory (using "../") are also ignored.
Applications depending on a JAR file loaded from an absolute URL element specified in Class-Path attribute may encounter a ClassNotFoundException. The historical behavior can be restored by setting a new system property, jdk.net.URLClassPath.disableClassPathURLCheck to true. Debugging info for Class-Path entries that are ignored can be printed to stderr by setting -Djdk.net.URLClassPath.disableClassPathURLCheck=debug.
security-libs/javax.crypto
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.
This section describes the changes in Oracle JRockit JDK R28.3.19:
JRockit R28.3.19 is upgraded to JDK 6u201. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.
This section describes the changes in Oracle JRockit JDK R28.3.18:
JRockit R28.3.18 is upgraded to JDK 6u191. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.
security-libs/javax.net.ssl
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
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.
security-libs/javax.net.ssl
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.
core-libs/java.rmi
Server side HTTP-tunneled RMI connections have been disabled by default in this release. This behavior can be reverted by setting the runtime property sun.rmi.server.disableIncomingHttp property to false. Note, 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.
security-libs/javax.crypto
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.
core-libs/java.util.logging
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
This section describes the changes in Oracle JRockit JDK R28.3.17:
JRockit R28.3.17 is upgraded to JDK 6u181. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.
security-libs/javax.crypto
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
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
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.
security-libs/javax.crypto
In R28.3.17, 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.
security-libs/javax.net.ssl
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).
security-libs/javax.crypto
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.
security-libs/javax.crypto
The generateSecret(String) method has been mostly disabled in the javax.crypto.KeyAgreement services of the SUN 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.
security-libs/javax.crypto
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
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
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:
Applets or Web Start Applications.
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
- 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.
xml/jax-ws
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
core-svc/javax.management
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.
This section describes the changes in Oracle JRockit JDK R28.3.16:
JRockit R28.3.16 is upgraded to JDK 6u171. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.
security-libs/javax.crypto
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/java.security
Two important changes have been made for this issue:
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 does not have a value, and JDK providers 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.
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. The 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. The 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 DSAKeyPairGenerator object which does not implement the aforementioned 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.
core-libs/java.util:collections
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 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 returns 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.
core-libs/java.net
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
security-libs/java.security
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 who want 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:
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.
For example:
keytool -genkeypair -keyalg DSA -keystore keystore -alias mykey ... keytool -certreq -sigalg SHA1withDSA -keystore keystore -alias mykey ...
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).
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.
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. For example:
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
This section describes the changes in Oracle JRockit JDK R28.3.15:
JRockit R28.3.15 is upgraded to JDK 6u161. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.
security-libs/java.security
With the need to restrict weak algorithms usage in situations where they are most vulnerable, additional features have been added when configuring the jdk.certpath.disabledAlgorithms and jdk.jar.disabledAlgorithms security properties in the java.security file.
jdk.certpath.disabledAlgorithms
certpath property has seen the most change. Previously it was limited to two constraint types – either a full disabling of an algorithm by name or a full disabling of an algorithm by the key size when checking certificates, certificate chains, and certificate signatures. This creates configurations that are absolute and lack flexibility in their usage. Three new constraints were added to give more flexibility in allowing and rejecting certificates.
jdkCA examines the certificate chain termination with regard to the cacerts file. In the case of SHA1 jdkCA. SHA1's usage is checked through the certificate chain, but the chain must terminate at a marked trust anchor in the cacerts keystore to be rejected. This is useful for organizations that have their own private CA that trust using SHA1 with their trust anchor, but want to block certificate chains anchored by a public CA from using SHA1.
denyAfter checks if the given date is before the current date or the PKIXParameter date. In the case of SHA1 denyAfter 2018-01-01, before 2018 a certificate with SHA1 can be used, but after that date, the certificate is rejected. This can be used for a policy across an organization that is phasing out an algorithm with a drop-dead date. For signed JAR files, the date is compared against the TSA timestamp. The date is specified in GMT.
usage examines the specified algorithm for a specified usage. This can be used when disabling an algorithm for all usages is not practical. There are three usages that can be specified:
TLSServer restricts the algorithm in TLS server certificate chains when server authentication is performed as a client.
TLSClient restricts the algorithm in TLS client certificate chains when client authentication is performed as a server.
SignedJAR restricts the algorithms in certificates in signed JAR files. The usage type follows the keyword and more than one usage type can be specified with a whitespace delimiter. For example, SHA1 usage TLSServer TLSClient would disallow SHA1 certificates for TLSServer and TLSClient operations, but SignedJars would be allowed.
All of these constraints can be combined to constrain an algorithm when delimited by &. For example, to disable SHA1 certificate chains that terminate at marked trust anchors only for TLSServer operations, the constraint would be SHA1 jdkCA & usage TLSServer.
jdk.jar.disabledAlgorithms
One additional constraint was added to this .jar property to restrict JAR manifest algorithms.
denyAfter checks algorithm constraints on manifest digest algorithms inside a signed JAR file. The date given in the constraint is compared against the TSA timestamp on the signed JAR file. If there is no timestamp or the timestamp is on or after the specified date, the signed JAR file is treated as unsigned. If the timestamp is before the specified date, the .jar operates as a signed JAR file. The syntax for restricting SHA1 in JAR files signed after January 1st 2018 is: SHA1 denyAfter 2018-01-01. The syntax is the same as that for the certpath property, however certificate checking will not be performed by this property.
See JDK-8176536
core-svc/java.lang.management
The 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 behavior by setting system property jdk.management.heapdump.allowAnyFileSuffix to true.
security-libs/java.security
If not specified, the message digest algorithm for the -tsadigestalg option of jarsigner defaults 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
This section describes the changes in Oracle JRockit JDK R28.3.14:
JRockit R28.3.14 is upgraded to JDK 6u151. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.
JDK R28.3.14 contains IANA time zone data version 2016j. For more information, refer to Timezone Data Versions in the JRE Software.
See JDK-8170316
security-libs/java.security
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 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 Security Manager enabled and are configured with a policy file that grants permissions based on the code signer of the JAR.
The list of disabled algorithms is controlled using the security property, jdk.jar.disabled Algorithms, 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 prints 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, this output would be displayed:
"The jar is 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 seen with 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 must 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.disabled Algorithms security property. However, this option is not recommended. Before re-signing affected JARs, the existing signature must 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'
Oracle recommends that you 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
core-libs/java.net
A new JDK implementation-specific system property to control caching for HTTP SPNEGO (Negotiate/Kerberos) connections is introduced. Caching for HTTP SPNEGO connections is enabled by default. There is no behavior change if the property is not explicitly specified.
When connecting to an HTTP server which 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 is recommended to disable all caching for the HTTP SPNEGO (Negotiate/Kerberos) protocol to force requesting new authentication with each new requests to the server.
With this fix, a new system property that allows control of the caching policy for HTTP SPNEGO connections is now provided. If jdk.spnego.cache is defined and evaluates to false, then all caching is 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 must be re-authenticated with each new request, requiring several communication exchanges with the server.
Credentials will need to be obtained again for each new requests, 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
core-libs/java.net
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 is 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 the 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 is 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 is essential to disable all caching for the HTTP NTLM protocol to force requesting new authentication with each new request to the server.
With this fix, a new system property that allows control of the caching policy for HTTP NTLM connections is provided. If jdk.ntlm.cache is defined and evaluates to false, then all caching is disabled for HTTP NTLM connections. Setting this system property to false, however, results in undesirable side effects:
Performance of HTTP NTLM connections is severely impacted as the connection is re-authenticated with each new request, requiring several communication exchanges with the server.
Credentials must be obtained again for each new request, which, depending on whether transparent authentication is available or not, and depending on the global Authenticator implementation, results in a popup asking for credentials for every new request.
JDK-8163520
This section describes the changes in Oracle JRockit JDK R28.3.13:
jarsigner -verbose -verify should print the algorithms used to sign the jar
Added security property to configure XML Signature secure validation mode
Add mechanism to allow non default root CAs to not be subject to algorithm restrictions
Improve the default strength of elliptic curve cryptography in JDK
Add TLS v1.1 and v1.2 to the client list of default-enabled protocols
Additional access restrictions for URLClassLoader.newInstance
JRockit R28.3.13 is upgraded to JDK 6u141. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.
JDK R28.3.13 contains IANA time zone data version 2016i. For more information, refer to Timezone Data Versions in the JRE Software
core-libs/javax.naming
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
security-libs/java.security
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.disabled algorithms, 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
security-libs/javax.xml.crypto
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
Refer to the definition of the property in the java.security file for more information.
core-libs/java.io:serialization
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.
core-libs/java.rmi
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.
security-libs
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.
SHA1 jdkCA
tools/javadoc(tool)
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.
security-libs/javax.xml.crypto
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"
security-libs/javax.net.ssl
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.
security-libs/javax.net.ssl
To improve the default strength of elliptic curve cryptography, elliptic curve keys less than 224 bits have been deactivated in certification path processing (via the jdk.certpath.disabledAlgorithms, Security Property) and SSL/TLS/DTLS 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).
Elliptic curves less than 256 bits are removed from the SSL/TLS/DTLS 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, 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
security-libs/java.security
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")
security-libs/javax.net.ssl
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.
security-libs
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.
core-libs/java.net
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.
This section describes the changes in Oracle JRockit JDK R28.3.12:
JRockit R28.3.12 is upgraded to JDK 6u131. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.
This section describes the changes in Oracle JRockit JDK R28.3.11:
JRockit R28.3.11 is upgraded to JDK 6u121. For more information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.
TLS v1.2 is now a TLS protocol option available with the release of JDK 6u121 and JRockit R28.3.11. By default, TLS v1.0 will remain as the default enabled protocol on both client and server sides. For more information about enabling TLS v1.2, see the release notes for JDK 6u121 at:
http://www.oracle.com/technetwork/java/javase/overview-156328.html
This section describes the changes in Oracle JRockit JDK R28.3.10:
JRockit R28.3.10 is upgraded to JDK 6u115. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.
This section describes the changes in Oracle JRockit JDK R28.3.9:
JRockit R28.3.9 is upgraded to JDK 6u111. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.
TLS v1.1 is now a TLS protocol option available with the release of JDK 6u111 and JRockit R28.3.9. By default, TLS v1.0 will remain as the default enabled protocol on both client and server sides. For more information about enabling TLS v1.1, see the release notes for JDK 6u111 at:
http://www.oracle.com/technetwork/java/javase/overview-156328.html.
A new diagnostic command, fork_and_abort, has been added to generate core files from a JRockit process in environments where external tools such as gdb and gcore cannot be used.
For more information about the fork_and_abort command, see "Diagnostics Commands" in JRockit Command-Line Reference.
This section describes the changes in Oracle JRockit JDK R28.3.8:
JRockit R28.3.8 is upgraded to JDK 6u105. For information about bug fixes and other changes in this JDK version, see the JDK 6 Release Notes.
In this release, two new command-line options have been added for JVM diagnostics, -XX:AbortVMOnException and -XX:AbortVMOnExceptionMessage. These options are used to dump the JRockit text dump and a core file when an exception specified by -XX:AbortVMOnException and having an exception message specified by -XX:AbortVMOnExceptionMessage occurs.
Example:
java -XX:+UnlockDiagnosticVMOptions -XX:AbortVMOnException=InvalidClassException -XX:AbortVMOnExceptionMessage="class invalid for deserialization" -Xverbose:exceptions DeserializeTest
The above command dumps JRockit text dump and a core file when the specified InvalidClassException exception having the message "class invalid for deserialization" occurs. The -Xverbose output will be as follows:
[INFO ][excepti][00004] java/io/InvalidClassException: A; class invalid for deserialization [ERROR] JRockit Fatal Error: Non-continuable exception (60) [ERROR] Saw java/io/InvalidClassException, aborting [JRockit] JVM State dumped to /export/test/jrockit.2091.dump. Aborted (core dumped)
This section describes the changes in Oracle JRockit JDK R28.3.2:
In JRockit versions prior to R28.3.2, the -XX:+|-CheckStacks option was disabled by default, meaning that JRockit did not explicitly check for stack overflows on a JNI method entry.
The -XX:+|-CheckStacks option in JRockit R28.3.2 and later versions will be enabled by default. In very rare cases, the additional overhead of stack overflow detection may result in low performance. This overhead can be avoided by explicitly disabling the stack checking by using the -XX:-CheckStacks option.
It is also possible, in very rare cases, that the system starts throwing StackOverflowErrors after enabling -XX:+|-CheckStacks. This happens only if the thread was within one page of memory from overflowing the stack. In this case, the recommended resolution is to increase the stack size by a small amount using the -Xss option, not by disabling -XX:+|-CheckStacks. For more information about the -Xss option, see JRockit Command-Line Reference.
Applications that use a lot of reflection or serialization would suffer from the performance overhead of garbage collection activity that is required to help prune the runtime shared constant pool. This overhead can be eliminated with the new command line option -XX:-UseCPoolGC. Use of this option may result in native memory leaks.
For more information about this option, see -XX:-UseCPoolGC in JRockit Command-Line Reference.
A new parameter shutdown has been added to the -Xverbose option. When you set this parameter, JRockit provides information about any event that has triggered a normal shutdown of the JVM.
For more information, see the description of -Xverbose in JRockit Command-Line Reference.
This section describes the changes in Oracle JRockit JDK R28.2.3.
In earlier versions of JRockit R28, the default value of the -XX:MaxLargePageSize option was zero, which means there was no limit for the maximum size for the large pages and the value was specified by the operating system.
The default value for this option in JRockit R28.2.3 and later versions will be 256 MB.
This section describes the changes in Oracle JRockit JDK R28.2.2.
Earlier versions of JRockit R28 suffered from an issue where some finalizers may never be executed. This issue was resolved in JRockit R28.2.2. Because JRockit uses finalizers internally to manage class constant pool data, a side effect of fixing this issue is that applications that continuously load and access the constant pool data of classes using sun.reflect.ConstantPool, may experience an increase in the number of finalizable objects stored on the Java heap after upgrading to R28.2.2 or later. In very rare cases, this additional pressure on the memory subsystem may result in performance issues (such as higher heap consumption or more GC activity) or even OutOfMemoryErrors. It is almost always possible to resolve such performance issues by modifying the application to eliminate redundant class loading.
This section describes the changes in Oracle JRockit JDK R28.2. These changes are:
In earlier versions of JRockit R28, long garbage collections resulted in application pauses during profiling recording.
To avoid the long application pauses, the JRockit Flight Recorder Heap Statistics events have been improved.
The new command-line option -XX:ExceptionTraceFilter and the new diagnostic command exception_trace_filter filter JVM exception logging and JRockit Flight Recorder exception events based on the exception type specified.
For more information about these commands, see Oracle JRockit Command-Line Reference.
This section lists the changes in Oracle JRockit JDK R28.1.5.
The installer for Oracle JRockit JDK R28.1.5 with Oracle JRockit Mission Control 4.0.1 will not install JRockit Mission Control samples by default. You must select the optional component Demos and Samples to install JRockit Mission Control samples.
For more information about installing the product, see JRockit Installation and Upgrade Guide.
This section lists the changes in JRockit JDK R28.1.0. These changes are:
In the genpar garbage collection mode, when the nursery runs out of memory in the old generation, objects that are identified for promotion to the old space are promoted within the nursery and this resulted in fragmentation of the nursery. This situation is known as promotion failure.
In R28.1, the JRockit JVM prevents promotion failure by triggering an early old collection for those young collections that are running out of memory.
When reading from network sockets, the size of the receive buffer can be limited by using the new command-line option, -XX:MaxRecvBufferSize.
For more information about this option, see -XX:MaxRecvBufferSize in the JRockit Command-Line Reference.
Oracle JRockit R28.1 introduces the command-line option -XX:[+|-]CrashOnOutOfMemoryError. If this option is enabled, when an out-of-memory error occurs, the JRockit JVM crashes and produces crash files. The state of the JVM before a crash is saved to a core dump file for off-line analysis.
For more information about this option, see -XX:+|-CrashOnOutOfMemoryError in the JRockit Command-Line Reference.
This release of Oracle JRockit introduces the command-line tool oracle.jrockit.jfr.tools.ConCatRepository, that allows you to extract JRockit Flight Recorder data that has been written to disk, but not handled and packaged as a flight recording, and then create a flight recording from it. This feature is useful when you have flight recording buffers on disk and the JVM terminates in such a way that .jfr files are not assembled to a complete flight recording file.
For more information, see the JRockit Flight Recorder Run Time Guide.
This section lists the changes in JRockit JDK R28.0.1.
The default maximum code memory on Linux IA32 with large pages was 32 MB in R28.0.0.
In R28.0.1, the default value has been changed to 64 MB.
For more information, see -XX:MaxCodeMemory in the JRockit Command-Line Reference.
The following are the new features and changes in JRockit JDK R28.0.0. These changes are:
The mechanism to stop threads in the JVM has been changed. In previous releases of the JRockit JVM, threads were suspended (for performing garbage collection, for example) by sending signals. In JRockit JVM R28.0, the threads check periodically whether they should self-suspend.
This change does not result in visible behavioral changes, but it makes the JRockit JVM easier to maintain and less error-prone.
Heap dumps can now be generated in the HPROF binary format, which can be parsed using heap analysis tools. You can use the -XX:+HeapDumpOnOutOfMemoryError or -XX:+HeapDumpOnCtrlBreak command-line options to generate Java heap dumps in HPROF binary format on OutOfMemory errors. You can also generate heap dumps in HPROF format by using the hprof diagnostic command and through JRockit Mission Control.
For more information, see "Generating Java Heap Dumps in the HPROF Binary Format" in the JRockit Diagnostics and Troubleshooting Guide.
The granularity of logging for code generation and optimization has been increased, to enable faster diagnostics and troubleshooting. The information in the outputs of the -Xverbose:opt and -Xverbose:codegen options is now more detailed. For more information, see the JRockit Command-Line Reference.
In previous releases of the JRockit JVM, you could control code optimization by specifying directives in an optfile and then using the -Djrockit.optfile property to indicate the name and location of the optfile.
In JRockit JVM R28.0, the format for specifying compiler-control directives in the optfile has been extended and improved to enable control over code optimization at a more detailed level. A new diagnostic command-line option, -XX:OptFile, is available for specifying the name and path of the optfile.
For more information, see "Specifying Optimization Directives" in the JRockit Diagnostics and Troubleshooting Guide.
In JRockit JVM R28.0, when you specify the throughput or pausetime garbage collection mode by using the -Xgc command-line option, the strategy associated with the specified mode— by default, genpar and gencon respectively—is used throughout the run time. The garbage collector does not change between generational and nongenerational garbage collectors during the run time.
This change has been made to reduce the extent of underterministic garbage collection behavior due to strategy changes during run time.
Note that the -XgcPrio option continues to work in R28.0. Oracle recommends that you use the -Xgc option instead of using the -XgcPrio option.
For more information about -Xgc, see the JRockit Command-Line Reference.
Oracle JRockit JVM R28.0 allocates large objects in the nursery if the size of the object is within the limit specified by the -XXtlaSize:wasteLimit command-line option.
This change improves the utilization of the nursery and reduces the frequency of old-space garbage collections.
For more information about -XXtlaSize:wasteLimit, see the JRockit Command-Line Reference.
Oracle JRockit R28.0 supports a new command-line option that enables you to specify compaction-related behavior: -XXcompaction. This option accepts all the parameters for compaction: compaction percentage, maximum number of references, and so on.
All the other compaction-related options are deprecated in R28.0.
For more information about -XXcompaction, see the JRockit Command-Line Reference.
In JRockit JVM R28.0, after the local management service starts, it remains active until the JVM is terminated.
In previous releases, the performance counter memory used to leak, and new addresses of the JMX connector were written during a memory leakage. Therefore, the JMX client was reading the wrong address of the JMX connector. This issue has been fixed in R28.0.
To allow RMI communication between the JRockit JVM server and a client through a firewall, two ports (RMI Registry and RMI Server) are required to configure the firewall. In previous releases, the RMI Server port number was generated randomly on the JRockit JVM server; so it was not possible to configure the firewall in advance. In JRockit JVM R28.0, the JMX agent enables you to select the same port number for the RMI Registry and the RMI Server. Therefore, you can use the default JMX agent for RMI communication through a firewall.
You can set the JMX agent properties by using the system properties or by using the -Xmanagement command-line option. For more information about the JMX agent system properties, see Appendix B "JMX Agent-Related –D Options" in the JRockit Command-Line Reference.
Oracle JRockit JVM R28.0 supports up to 64 GB compressed references for various heap sizes. You can define the compressed reference size during the JVM startup by using the -XXcompressedRefs command-line option.
For more information about -XXcompressedRefs, see the JRockit Command-Line Reference.
In JRockit JVM R28.0, the heap grows faster than before. The JVM also ensures that the heap size grows up to the maximum Java heap size (-Xmx) before an OutofMemory error is thrown. In addition, the default value of the -Xmx option is changed from 1 GB to 3 GB on 64-bit platforms.
The JRockit JVM shrinks the heap if it is unused or if other applications require more physical memory.
In the previous releases, the JVM used to crash when the heap size reduced from a very large size to a small size. This issue has been fixed in R28.0.
The pause time during the old collection of code and class garbage collections has been removed in Oracle JRockit JVM R28.0. With this change, the code and class garbage collections are mostly concurrent in R28.0.
The Oracle JRockit JVM R28.0 supports several new command-line options.
For more information, see Appendix A, "Changes in Command-Line Options" in the JRockit Command-Line Reference.
Some command-line options have been deprecated in Oracle JRockit JVM R28.0.
For more information, see Appendix A, "Changes in Command-Line Options" in the JRockit Command-Line Reference.
In Oracle JRockit JVM R28.0, the format of several command-line options has been changed to the HotSpot format: -XX:+|-option (for example, -XX:+UseClassGC).
For a list of the command-line options that have been changed to the HotSpot format, see Appendix A, "Changes in Command-Line Options" in the JRockit Command-Line Reference.