JDK-7093640 : Enable client-side TLS 1.2 by default
  • Type: Enhancement
  • Component: security-libs
  • Sub-Component: javax.net.ssl
  • Affected Version: 7,8
  • Priority: P1
  • Status: Closed
  • Resolution: Fixed
  • OS: generic
  • CPU: generic
  • Submitted: 2011-09-22
  • Updated: 2017-10-03
  • Resolved: 2013-12-19
The Version table provides details related to the release that this issue/RFE will be addressed.

Unresolved : Release in which this issue/RFE will be addressed.
Resolved: Release in which this issue/RFE has been resolved.
Fixed : Release in which this issue/RFE has been fixed. The release containing this fix may be available for download as an Early Access Release or a General Availability Release.

To download the current JDK release, click here.
JDK 6 JDK 7 JDK 8 JDK 9 Other
6u121Fixed 7u111Fixed 8 b122Fixed 9Fixed openjdk7uFixed
Related Reports
Relates :  
Sub Tasks
JDK-8169773 :  
Transport Layer Security (TLS) is a network protocol that provides confidentiality, authentication, and integrity protection.  There are currently 4 variants in use:  SSL v3 [1], TLS v1.0 [2], TLS v1.1[3], TLS v1.2[4] (protocol will be used to refer to the variant in this context). SunJSSE provider in JDK 7/8 support all 4 protocols.
Default enabled TLS protocols refer to the potential usable protocols in a TLS connection if application does not explicitly specify the enabled protocol suite. For example, SSLContext.getInstance(), SSLContext.getInstance("TLS") and SSLContext.getInstance("SSL") use the default enabled TLS protocols. SSLContext.getInstance("TLSv1"), SSLContext.getInstance("TLSv1.2") and SSLSocket.setEnabledProtocols(new String[] {"TLSv1.1"}) do not use the default enabled TLS protocols as the usable protocols have been explicit specified by the caller.
In SunJSSE provider, all versions are enabled by default for servers, but for clients, only SSLv3 and TLS v1.0 are enabled by default because of the TLS version intolerance issue with some older TLS server implementations described below.
The TLS specifications state that during handshaking, a TLS server implementation must accept a client's TLS protocol version number even if the requested TLS version number is higher than what the server implementation has enabled.  The server replies by choosing the highest version number that it has enabled, and as long as the client also has this version enabled, the handshaking will continue.  For example:
    client (enabled: 1.2/1.1/1.0/SSLv3)    server (enabled: 1.0/SSLv3)
    client sends 1.2   ->
                       <-  server responds with 1.0
    1.0 is acceptable to the client, so handshaking continues.
However, there remain a few older TLS server deployments that do not accept higher TLS version numbers, which is generally version TLS v1.0.  This condition is called version intolerance, and is why we did not enable TLS 1.1/1.2 in the  SunJSSE by default at JDK 7 GA.  According to a 2011 survey by Opera, 1.145% of servers were version intolerant. This was a low but non-zero percentage, and is likely to drop as the industry moves towards newer TLS versions.
Since we began shipping TLS 1.1/1.2, new developments in TLS security have occurred, and the days of using TLS 1.0/SSLv3 are numbered: it uses weaker hash algorithms (SHA1 and MD5), it is subject to BEAST[5] and LuckyThirteen[6] attacks, and many of the older cipher suites are no longer safe to use. As a result, the industry is moving toward TLS 1.1/1.2 and the use of GCM-based cipher suites[7]. Enabling TLS 1.2 by default is an important step -- we need to follow the industry deployment of TLS protocols and provide a safe default JDK to our customers.
As of December 2013, the following modern browsers all have TLS 1.2 enabled by default:
    Firefox: Next 6 months (either version 27 or 28)
    IE version 11
    Google Chrome 31
    Opera 18 on Windows
    Safari 7.0 on Mac
In the November 2013 web server statistics from Qualsys, 18.2% of the web sites support TLS 1.1, and 20.7% support TLS 1.2, which is a big improvement from a similar survey conducted 18 months earlier.  The improvement is likely due to the recent attacks against older versions.
For SunJSSE provider, we would like to enable TLS 1.1/1.2 by default for JDK 8 JSSE clients, and introduce a new system property in JDK 8 that will allow users to revert this change if needed.  The impact of enabling TLS 1.1/1.2 may be significant for some, so we will be leveraging the CAP program, plus active blogging and OpenJDK mailing list communication to alert developers of this upcoming change.
We may backport this update partially to JDK 7 in a conservative approach.  In the backport to JDK 7, TLS 1.2 should not be enabled in client side by default, but applications do have a handy approach to enable TLS 1.2 by changing this system property.
[1] http://tools.ietf.org/html/rfc6101
[2] http://tools.ietf.org/html/rfc2246
[3] http://tools.ietf.org/html/rfc4346
[4] http://tools.ietf.org/html/rfc5246
[5] http://en.wikipedia.org/wiki/Transport_Layer_Security#BEAST_attack
[6] http://en.wikipedia.org/wiki/Lucky_Thirteen_attack
[7] http://tools.ietf.org/html/rfc5288
UR SQE OK to take the enhancement to CPU17_01.

only needed for JDK7 BPR

Marking this as verified based on manual verification of regression test on b129 on solaris sparc machine

Changeset: http://closedjdk.us.oracle.com/jdk8/build/pubs/rev/b76aa6527363 With changes to the Security JDK 8 enhancements page: TLS 1.2 Enabled by Default: The SunJSSE provider enables the protocol TLS 1.2 on the client by default. See Protocols. Configure which SunJSSE protocols are enabled with the new system property jdk.tls.client.protocols. See Customizing JSSE. Protocols: http://download.java.net/jdk8/docs/technotes/guides/security/SunProviders.html#SunJSSE_Protocols Customizing JSSE: http://download.java.net/jdk8/docs/technotes/guides/security/jsse/JSSERefGuide.html#InstallationAndCustomization

suggested release note: ================= In client side of SunJSSE, TLS 1.2 is enabled by default, and a new a system property, "jdk.tls.client.protocols", is defined to configure the default enabled protocol suite. Also need to update the 'Protocols" section in SunJSSE provider of "Oracle Providers Documentation", and mark TLSv1.1 and TLSv1.2 "Enabled by Default for Client".

webrev: http://cr.openjdk.java.net/~xuelei/7093640/webrev.01/

SQE approves this critical request.

Solution ------------ Define a system property, "jdk.tls.client.protocols", to configure the default enabled protocol suite [1] in client side of SunJSSE provider. By default, TLS 1.1 and TLS 1.2 (plus other supported and safe protocols) are enabled unless the system property is explicit configured and does not contain "TLSv1.1" or "TLSv1.2". The property string is a list of comma separated standard SSL protocol names. The syntax of the property string can be described as this Java BNF-style: ClientProtocols: ('"' SSLProtocolNames '"') | SSLProtocolNames SSLProtocolNames: SSLProtocolName { , SSLProtocolName } SSLProtocolName: (see below) The "SSLProtocolName" is the standard SSL protocol name as described in the "Java Cryptography Architecture Standard Algorithm Name Documentation"[2]. If the property value does not comply to the above syntax, or the specified value of SSLProtocolName is not a supported SSL protocol name, the instantiation of the SSLContext provider service (via SSLContext.getInstance() methods) may generate a java.security.NoSuchAlgorithmException. Please note that the protocol name is case-sensitive. If the system property is not set or is empty, the default enabled protocol setting in both client and server looks like: Protocol Enabled Enabled for Client for Server -------- ---------- ---------- SSLv3 Yes Yes TLSv1 Yes Yes TLSv1.1 Yes Yes TLSv1.2 Yes Yes SSLv2Hello No Yes If the system property is set to "TLSv1,TLSv1.1", the default enabled protocol setting in both client and server looks like: Protocol Enabled Enabled for Client for Server -------- ---------- ---------- SSLv3 No Yes TLSv1 Yes Yes TLSv1.1 Yes Yes TLSv1.2 No Yes SSLv2Hello No Yes This update does not impact the API specification of JSSE, JSSE server side and third party's provider. [1] The default protocol suite can be overridden by: https.protocols system property SSLEngine.setEnabledProtocols() SSLSocket.setEnabledProtocols() SSLParameters.setProtocols() and SSLEngine.setSSLParameters() SSLParameters.setProtocols() and SSLSocket.setSSLParameters() or other approaches that customize the enabled protocols. [2] http://docs.oracle.com/javase/7/docs/technotes/guides/security/StandardNames.html#jssenames

Xuelei, Is there a webrev for this fix? Also how did you test the implementation for the various methods of setting the system property? I am asking this to assess the extent to which we will need to write test in order to cover any gaps.

A conservative approach may be that in JDK 8, adding a new system property which will be configured to disable TLS 1.2 by default but applications have a handy approach to enable TLS 1.2 by changing this property. In JDK 9 (or earlier if necessary), we can update the system property value to enable TLS 1.2 by default.