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