Transport Level Security (TLS) is designed to encrypt conversations between two parties and ensure that others can neither read nor modify the conversation. When combined with Certificate Authorities, a proper level of trust is established: we know who is on the other end of the conversation and that conversation is protected from eavesdropping/modification.

Support for TLS 1.2 first appeared in JDK 7 (2011). For compatibility reasons, it is enabled by default on server sockets but disabled on clients. Since that time, the industry has made considerable improvements to address interoperability and backwards compatibility.

We are setting JDK 8 to use TLS 1.2 as the default for two reasons:

1. TLS is backwards-compatible. After upgrading the default to 1.2, systems using 1.1 and 1.0 will continue to function*.
   
1. * Unless configured to use an algorithm that was removed for security reasons. Few systems are affected by this.
   
2. For a complete description of TLS 1.2, please see RFC 5246.
3. A quick summary of TLS/SSL differences is available from yaSSL.
2. It strengthens the protection of internet communications against eavesdropping.

For those testing JDK 8 early access, this first occurred in build 122.

TLS is transparent to most users and developers. For those that would like more details, we will cover:

• Threats and the role of encryption
• Compatibility with the JDK and other systems
• Understanding your TLS implementation
• Other considerations for TLS

Threats and the role of encryption

With a new well-motivated IETF working group for encryption as well as wide industry support for TLS 1.2, the time is right to update system defaults.

Qualys SSL Labs has done great research in depicting a threat model for TLS. Their best practices in dealing with the TLS threat model (specifically "2.2 use secure protocols") support this move.

Compatibility with the JDK and other systems

TLS 1.2 is designed to be backwards-compatible as described in the RFC Appendix E (above). If a 1.2 client connects to a server running a lower version, the client will adjust. If a lower client connects to a server running 1.2, the server will adjust. Because of backwards-compatibility, clients supporting TLS 1.2 will receive improved communications and older clients will continue to function.

• We added support for TLS 1.2 in JDK 7 (July 2011) although it was not the default. JDK 8 (March 2014) will use TLS 1.2 as the default.
• OpenSSL added support for TLS 1.2 in version 1.0.1 (March 2012). Most Linux distributions and scripting languages use OpenSSL.
• Microsoft supported TLS 1.2 in Windows 7. Internet Explorer and .NET follow accordingly. TLS 1.2 was first enabled by default in Internet Explorer 11 (October 2013).
• Firefox turned TLS 1.2 on by default in version 27 (February 2014).
• Chrome supported TLS 1.2 in version 29 (August 2013).
• Etc.

Adoption statistics from the Trustworthy Internet's SSL Pulse show a sufficient number of internet-facing systems using TLS 1.2 and compatible ciphers.

Understanding your TLS implementation

Developers or System Administrators can test servers and clients through the Qualys SSL Labs (server or client) or a different How’s My SSL website.

System Administrators can view their system’s TLS implementation to monitor clients or disable specific TLS versions. For example some system administrators in highly sensitive businesses may want to disable older TLS versions from ever being used.

View your client’s version through a GUI

1. Open the Java Control Panel
2. Navigate to the Advanced tab.
3. At the bottom, there is an “Advanced Security Settings.”
4. Check or uncheck the "Use TLS X.Y" box.

On a server or without a GUI

1. To set this for everything:
1. Open the deployment.properties file, either user-level or system-level.
2. Set the appropriate property
   deployment.security.TLSvX.Y=false
2. To set for a specific application or script:
1. Use the startup flag -Ddeployment.security.TLSvX.Y=false

Other Considerations for TLS

The InfoQ article, Keeping Your Secrets, covers additional information for developers looking to understand more about transport security and encryption. Outside the role of TLS protocol version, that article covers good techniques to safeguard information:

For System Administrators (or some Developers): Perfect Forward Secrecy can be used in Java TLS connections. Using Perfect Forward Secrecy protects past conversations: in the event that if keys are lost in the future, someone cannot decrypt past conversations. As is common with TLS implementations, Perfect Forward Secrecy is not enabled by default. Those that do want to use it can update their https.cipherSuites property. Common values for this property are:

• TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA
• TLS_DHE_RSA_WITH_AES_128_CBC_SHA
• Anything on the Algorithm Standard Name list that start with TLS (Transport Level Security) followed by a type of DHE (Diffie-Hellman Exchange).