RELEASE NOTES: JDK openjdk7u

Modified HttpURLConnection behavior when no suitable proxy is found

The behavior of HttpURLConnection when using a ProxySelector has been modified with this JDK release. HttpURLConnection used to fall back to a DIRECT connection attempt if the configured proxy(s) failed to make a connection. This release introduces a change whereby no DIRECT connection will be attempted in such a scenario. Instead, the HttpURLConnection.connect() method will fail and throw an IOException which occurred from the last proxy tested.

Modified HttpURLConnection Behavior When a Suitable Proxy Is Not Found

The behavior of HttpURLConnection when using ProxySelector has been modified in this JDK release. HttpURLConnection used to fall back to a direct connection attempt if the configured proxy(s) failed to make a connection. Beginning with this release, the default behavior has been changed to no longer use a direct connection when the first proxy connection attempt fails.

A new system property, sun.net.http.fallbackToDirect, can be set to a value of "true" should an application need to fall back to the old behavior (fall back to a direct connection when the first proxy connection attempt fails).

Running jps as root does not show all information

After the fix of [https://bugs.openjdk.java.net/browse/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.

Allow SASL Mechanisms to Be Restricted

A security property named jdk.sasl.disabledMechanisms has been added that can be used to disable SASL mechanisms. Any disabled mechanism will be ignored if it is specified in the mechanisms argument of Sasl.createSaslClient or the mechanism argument of Sasl.createSaslServer. The default value for this security property is empty, which means that no mechanisms are disabled out-of-the-box.

IANA Data 2016a

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

New Japanese Era Name: Reiwa

An instance representing the new Reiwa era has been added to this update. Unlike other eras, there is no public field for this era. It can be obtained by calling JapaneseEra.of(3) or JapaneseEra.valueOf("Reiwa"). JDK 13 and later will have a new public field to represent this era.

The placeholder name, "NewEra", for the Japanese era that started from May 1st, 2019 has been replaced with the new official name. Applications that relied on the placeholder name (see JDK-8202088) to obtain the new era singleton (JapaneseEra.valueOf("NewEra")) will no longer work.

New system property for the remote JMX connector

New JMX agent property - jmxremote.host

A new property, com.sun.management.jmxremote.host, is introduced that specifies the bind address for the default JMX agent. If the latter is not specified, the default JMX agent will listen on all interfaces (0.0.0.0) and the host value placed in the agent service URL (JMXServiceURL) is the IP address returned from invocation of InetAddress.getLocalHost() method.

• Name: com.sun.management.jmxremote.host
• Definition : Specifies the bind address for the default JMX agent. It can be specified via the command line while starting the JVM or as part of the agent config file (management.properties).
• Value: IP address of any network interface of the machine

A new configurable property in logging.properties: java.util.logging.FileHandler.maxLocks

A new "java.util.logging.FileHandler.maxLocks" configurable property is added to java.util.logging.FileHandler.

This new logging property can be defined in the logging configuration file and makes it possible to configure the maximum number of concurrent log file locks a FileHandler can handle. The default value is 100.

In a highly concurrent environment where multiple (more than 101) standalone client applications are using the JDK Logging API with FileHandler simultaneously, it may happen that the default limit of 100 is reached, resulting in a failure to acquire FileHandler file locks and causing an IO Exception to be thrown. In such a case, the new logging property can be used to increase the maximum number of locks before deploying the application.

If not overridden, the default value of maxLocks (100) remains unchanged. See java.util.logging.LogManager and java.util.logging.FileHandler API documentation for more details.

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 MAXLOCKS limit. The default value of the current MAXLOCKS (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.

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-sigalgoption and use the stronger SHA256withDSA default or, at your own risk, use the-keysizeoption ofkeytool` 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=jarto thejarsignercommand 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-sigalgoption ofjarsigner` 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-sigalgoption ofkeytool` and specify SHA1withDSA.

keytool now prints warnings when reading or generating certificates/certificate requests/CRLs using weak algorithms

With one exception, keytool will always print a warning if the certificate, certificate request, or CRL it is parsing, verifying, or generating is using a weak algorithm or key. When a certificate is from an existing TrustedCertificateEntry, either in the keystore directly operated on or in the cacerts keystore when the -trustcacerts option is specified for the -importcert command, keytool will not print a warning if it is signed with a weak signature algorithm. For example, suppose the file cert contains a CA certificate signed with a weak signature algorithm, keytool -printcert -file cert and keytool -importcert -file cert -alias ca -keystore ks will print out a warning, but after the last command imports it into the keystore, keytool -list -alias ca -keystore ks will not show a warning anymore.

An algorithm or a key is weak if it matches the value of the jdk.certpath.disabledAlgorithms security property defined in the conf/security/java.security file.

keytool now prints out information of a certificate's public key

Keytool now prints out the key algorithm and key size of a certificate's public key, in the form of "Subject Public Key Algorithm: `<size>-bit RSA key", where <size>` is the key size in bits (ex: 2048).

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 and has caused some WebStart applications to fail to load. See JDK-8184993 for more information.

Support keystore type detection for JKS and PKCS12 keystores

To aid interoperability, the Java keystore type JKS now supports keystore compatibility mode by default. This mode enables JKS keystores to access both JKS and PKCS12 file formats. To disable keystore compatibility mode set the Security property 'keystore.type.compat' to the string value 'false'.

Weak Named Curves in TLS, CertPath, and Signed JAR Disabled by Default

Weak named curves are disabled by default by adding them to the following disabledAlgorithms security properties: jdk.tls.disabledAlgorithms, jdk.certpath.disabledAlgorithms, and jdk.jar.disabledAlgorithms. The named curves are listed below.

With 47 weak named curves to be disabled, adding individual named curves to each disabledAlgorithms property would be overwhelming. To relieve this, a new security property, jdk.disabled.namedCurves, is implemented that can list the named curves common to all of the disabledAlgorithms properties. To use the new property in the disabledAlgorithms properties, precede the full property name with the keyword include. Users can still add individual named curves to disabledAlgorithms properties separate from this new property. No other properties can be included in the disabledAlgorithms properties.

To restore the named curves, remove the include jdk.disabled.namedCurves either from specific or from all disabledAlgorithms security properties. To restore one or more curves, remove the specific named curve(s) from the jdk.disabled.namedCurves property.

Curves that are disabled through jdk.disabled.namedCurves include the following: secp112r1, secp112r2, secp128r1, secp128r2, secp160k1, secp160r1, secp160r2, secp192k1, secp192r1, secp224k1, secp224r1, secp256k1, sect113r1, sect113r2, sect131r1, sect131r2, sect163k1, sect163r1, sect163r2, sect193r1, sect193r2, sect233k1, sect233r1, sect239k1, sect283k1, sect283r1, sect409k1, sect409r1, sect571k1, sect571r1, X9.62 c2tnb191v1, X9.62 c2tnb191v2, X9.62 c2tnb191v3, X9.62 c2tnb239v1, X9.62 c2tnb239v2, X9.62 c2tnb239v3, X9.62 c2tnb359v1, X9.62 c2tnb431r1, X9.62 prime192v2, X9.62 prime192v3, X9.62 prime239v1, X9.62 prime239v2, X9.62 prime239v3, brainpoolP256r1, brainpoolP320r1, brainpoolP384r1, brainpoolP512r1

Curves that remain enabled are: secp256r1, secp384r1, secp521r1, X25519, X448

jarsigner Prints When a timestamp Will Expire

The jarsigner tool now shows more information about the lifetime of a timestamped JAR. New warning and error messages are displayed when a timestamp has expired or is expiring within one year.

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.

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.

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.

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 `

jarsigner treats timestamped signed jar invalid after the signer cert expires

If a jar file was signed with a timestamp when the signer certificate was still valid, it should be valid even after the signer certificate expires. However, jarsigner will incorrectly show a warning that that signer's certificate chain is not validated. This will be fixed in a future release.

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`

IANA Data 2016f

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

IANA Data 2016d

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

US/Pacific-New Zone Name Removed as Part of tzdata2020b

Following the JDK's update to tzdata2020b, the long-obsolete files named pacificnew and systemv have been removed. As a result, the "US/Pacific-New" Zone name declared in the pacificnew data file is no longer available for use.

Information regarding this update can be viewed at https://mm.icann.org/pipermail/tz-announce/2020-October/000059.html

IANA Data 2016i

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

Update Timezone Data to 2021c

The IANA Time Zone Database, on which the JDK's Date/Time libraries are based, has made a tweak to some of the time zone rules in 2021c.

Note that in 2021b, which is cumulatively included in this change, some of the time zone rules prior to the year 1970 have been modified according to changes introduced with 2021b. For more details, refer to the announcement of 2021b.

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.

Weak Encryption Disabled by Default

The DES-related Kerberos 5 encryption types are not supported by default. These encryption types can be enabled by adding allow_weak_crypto=true in the krb5.conf file, but DES-related encryption types are considered highly insecure and should be avoided.

Kerberos Sequence Number Issues

Previously, when mutual authentication was not requested by the Kerberos 5 initiator, there was no mechanism to negotiate the acceptor's initial sequence number. With this release, if the system property sun.security.krb5.acceptor.sequence.number.nonmutual is set to initiator, the SunJGSS provider will use the initiator's initial sequence number as the acceptor's initial sequence number. If set to zero or 0, 0 is used. The default value is initiator. All other values are illegal and will throw an Error when the system property is read.

Support the "s" (second) unit for kdc_timeout in krb5.conf

An interoperability issue is found between Java and the native Kerberos implementation on BSD (including macOS) on the kdc_timeout setting in krb5.conf, where Java interpreted it as milliseconds and BSD as seconds when no unit is specified. This code change adds support for the "s" (second) unit. Therefore if the timeout is 5 seconds, Java accepts both "5000" and "5s". Customers concerned about interoperability between Java and BSD should use "5s".

Add 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 thejava.security` file for more information.

IANA Data 2015g

JDK contains IANA time zone data version 2015g. For more information, refer to [Timezone Data Versions in the JRE Software|http://www.oracle.com/technetwork/java/javase/tzdata-versions-138805.html].

Unable to use the JDWP API in JDK 8 to debug JDK >=9

The implementation of VirtualMachineImpl.canGetInstanceInfo() has been corrected, so it is now able to see JDK JVMs >= JDK 9.

This correction allows certain debugger agents to operate correctly without any action required from a user (developer).

Improved exception handling for bad LDAP referral replies

The JDK was throwing a NullPointerException when a non-compliant REFERRAL status result was sent but no referral values were included. With this change, a NamingException with message value of "Illegal encoding: referral is empty" will be thrown in such circumstances. See JDK-8149450 and JDK-8154304 for more details

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)<br /> at com.sun.jndi.ldap.LdapClient.ldapBind(Unknown Source) ... `

Decode error with Tomcat version 7.x

The zlib version shipped in the 8u151, 7u161 JDK releases was updated to zlib v1.2.11. The deflate functionality in this version causes a compatibility issue with Tomcat v7.x. Server responses can appear as corrupt or can fail to be decoded. The issue is seen if Tomcat is using compression (e.g. compression="on" in server.xml). This issue is being fixed via JDK-8189789 [https://bugs.openjdk.java.net/browse/JDK-8189789].

Users could disable the compression mode on their Tomcat servers as a workaround. Tomcat versions 8.x and later don't appear to be affected.

Nondeterministic wrong answer on arithmetic corrected

When performing OSR on loops with huge stride and/or initial values, in very rare cases, the tiered/server compilers could produce non-canonical loop shapes that produce nondeterministic answers when the answers should be deterministic. This issue has now been fixed.

Disable TLS 1.0 and 1.1

TLS 1.0 and 1.1 are versions of the TLS protocol that are no longer considered secure and have been superseded by more secure and modern versions (TLS 1.2 and 1.3).

These versions have now been disabled by default. If you encounter issues, you can, at your own risk, re-enable the versions by removing "TLSv1" and/or "TLSv1.1" from the jdk.tls.disabledAlgorithms security property in the java.security configuration file.

jdk.tls.client.protocols system property added

The jdk.tls.client.protocols system property is now available with the release of JDK . This property was originally introduced in JDK 8 and behaves in the same way. See [JSSE User Guide|http://docs.oracle.com/javase/8/docs/technotes/guides/security/jsse/JSSERefGuide.html#jdktlsclient_protocols]

Support for Customization of Default Enabled Cipher Suites via System Properties

The system property jdk.tls.client.cipherSuites can be used to customize the default enabled cipher suites for the client side of SSL/TLS connections. In a similar way, the system property jdk.tls.server.cipherSuites can be used for customization on the server side.

The system properties contain a comma-separated list of supported cipher suite names that specify the default enabled cipher suites. All other supported cipher suites are disabled for this default setting. Unrecognized or unsupported cipher suite names specified in properties are ignored. Explicitly setting enabled cipher suites will override the system properties.

Refer to the Java Cryptography Architecture Standard Algorithm Name Documentation for the standard JSSE cipher suite names, and the Java Cryptography Architecture Oracle Providers Documentation for the cipher suite names supported by the SunJSSE provider.

Note that the actual use of enabled cipher suites is restricted by algorithm constraints.

Note also that these system properties are currently supported by the JDK Reference Implementation. They are not guaranteed to be supported by other implementations.

Warning: These system properties can be used to configure weak cipher suites, or the configured cipher suites may become more weak over time. We do not recommend using the system properties unless you understand the security implications. Use them at your own risk.

Updated the Default Enabled Cipher Suites Preference

The preference of the default enabled cipher suites has been changed. The compatibility impact should be minimal. If needed, applications can customize the enabled cipher suites and the preference. For more details, refer to the SunJSSE provider documentation and the JSSE Reference Guide documentation.

Disabled TLS anon and NULL Cipher Suites

The TLS anon (anonymous) and NULL cipher suites have been added to the jdk.tls.disabledAlgorithms security property and are now disabled by default.

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.

Distrust TLS Server Certificates Anchored by Symantec Root CAs

The JDK will stop trusting TLS Server certificates issued by Symantec, in line with similar plans recently announced by Google, Mozilla, Apple, and Microsoft. The list of affected certificates includes certificates branded as GeoTrust, Thawte, and VeriSign, which were managed by Symantec.

TLS Server certificates issued on or before April 16, 2019 will continue to be trusted until they expire. Certificates issued after that date will be rejected. See the DigiCert support page for information on how to replace your Symantec certificates with a DigiCert certificate (DigiCert took over validation and issuance for all Symantec Website Security SSL/TLS certificates on December 1, 2017).

An exception to this policy is that TLS Server certificates issued through two subordinate Certificate Authorities managed by Apple, and identified below, will continue to be trusted as long as they are issued on or before December 31, 2019.

The restrictions are enforced in the JDK implementation (the SunJSSE Provider) of the Java Secure Socket Extension (JSSE) API. A TLS session will not be negotiated if the server's certificate chain is anchored by any of the Certificate Authorities in the table below.

An application will receive an Exception with a message indicating the trust anchor is not trusted, ex:

"TLS Server certificate issued after 2019-04-16 and anchored by a distrusted legacy Symantec root CA: CN=GeoTrust Global CA, O=GeoTrust Inc., C=US"

If necessary, and at your own risk, you can work around the restrictions by removing "SYMANTEC_TLS" from the jdk.security.caDistrustPolicies security property in the java.security configuration file.

The restrictions are imposed on the following Symantec Root certificates included in the JDK:

If you have a TLS Server certificate issued by one of the CAs above, you should have received a message from DigiCert with information about replacing that certificate, free of charge.

You can also use the keytool utility from the JDK to print out details of the certificate chain, as follows:

keytool -v -list -alias <your_server_alias> -keystore <your_keystore_filename>

If any of the certificates in the chain are issued by one of the root CAs in the table above are listed in the output you will need to update the certificate or contact the organization that manages the server if not yours.

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/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").

EC 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, 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.

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

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.

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.

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.

Correction of 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.

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.

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) `

MSCAPI KeyStore can handle same named certificates

Java SE KeyStore does not allow certificates that have the same aliases. http://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html

However, on Windows, multiple certificates stored in one keystore are allowed to have non-unique friendly names.

The fix for JDK-6483657 makes it possible to operate on such non-uniquely named certificates through the Java API by artificially making the visible aliases unique.

Please note, this fix does not enable creating same-named certificates with the Java API. It only allows you to deal with same-named certificates that were added to the keystore by 3rd party tools.

It is still recommended that your design not use multiple certificates with the same name. In particular, the following sentence will not be removed from the Java documentation: "In order to avoid problems, it is recommended not to use aliases in a KeyStore that only differ in case." http://docs.oracle.com/javase/8/docs/api/java/security/KeyStore.html

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.

Introduced a new window ordering model

On the OS X platform, the AWT framework used native services to implement a parent-child relationship for windows. That caused some negative visual effects especially in multi-monitor environments. To get rid of disadvantages of such an approach, the new window ordering model, which is fully implemented at JDK layer, was introduced. Its main principles are listed below: - A window should be placed above its nearest parent window. - If a window has several child windows, all child windows should be located at the same layer and the window from the active window chain should be ordered above its siblings. - Ordering should not be performed for a window that is in an iconified state or when the transition to iconified state is in progress.

These rules are applied to every frame or dialog from the window hierarchy which contains the currently focused window.

Trackpad scrolling of text on OS X 10.12 Sierra is very fast

The MouseWheelEvent.getWheelRotation() method returned rounded native NSEvent deltaX/Y events on Mac OS X. The latest macOS Sierra 10.12 produces very small NSEvent deltaX/Y values so rounding and summing them leads to the huge value returned from the MouseWheelEvent.getWheelRotation(). The JDK-8166591 fix accumulates NSEvent deltaX/Y and the MouseWheelEvent.getWheelRotation() method returns non-zero values only when the accumulated value exceeds a threshold and zero value. This is compliant with the MouseWheelEvent.getWheelRotation() specification:

https://docs.oracle.com/javase/8/docs/api/java/awt/event/MouseWheelEvent.html#getWheelRotation--

Returns the number of "clicks" the mouse wheel was rotated, as an integer. A partial rotation may occur if the mouse supports a high-resolution wheel. In this case, the method returns zero until a full "click" has been accumulated.

For the precise wheel rotation values, use the MouseWheelEvent.getPreciseWheelRotation() method instead.