Insights and updates on Java SE and OpenJDK from the Java Platform Group Product Management Team

  • January 28, 2014

JDK 8 will use TLS 1.2 as default

Guest Author

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
  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:

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

Join the discussion

Comments ( 6 )
  • guest Wednesday, January 29, 2014

    Will Java 7 also enable TLS 1.2 by Default with a future build ?

  • costlow Wednesday, January 29, 2014

    We only change default options like this in major versions, so that won't happen in a JDK 7 build. Patches still go in though, so the implementation will be improved as needed.

  • Brad Thursday, January 30, 2014

    Guest, you can always write a simple custom SSLSocketFactory which sets the appropriate defaults (protocols/suites/etc) on a SSLSocket before hand off.

  • rclayton Friday, February 7, 2014

    Hope I'm not breaking any rules posting here. I'm stuck on Deployment Rule Sets and comments are closed at https://blogs.oracle.com/java-platform-group/entry/introducing_deployment_rule_sets

    Trying to get a simple ruleset working:

    <ruleset version="1.0+">


    <id location="javatester.org" />

    <action permission="run" version="1.6.0_35" />



    I have the java console set to "show console", and I can see it popping up both with first the 1.7.0_51 console, then the 1.6.0_35 console, but then all I get on javatester.org is "Error, click for details". When I click, a blank popup appears briefly before disappearing titled "Application Error".

    I have successfully deployed this same ruleset using 1.7.0_45, 1.7.0_35, and 1.7.0_9, but can't get 1.6.0_35 or 1.6.0_27 working.

    If there is a better forum to post this question, please let me know.

  • costlow Tuesday, February 11, 2014

    That's ok. For anyone reading the comments, the Deployment Rule Sets (old post) are unrelated to the TLS standard (this post).

    The blog system closes old comment sections after a number of days.

    For Deployment Rule Set, what you posted should be ok. That's what others are doing. Take a look at the Facebook post https://www.facebook.com/notes/protect-the-graph/protecting-the-java-browser-plugin/1405538516352962 or someone's write-up about a Citrix client at http://www.ingmarverheij.com/citrix-netscaler-hangs-downloading-applet/

    For a longer discussion, that's probably better suited at the discussion boards (https://community.oracle.com/community/developer/english/java) or system administrator areas like http://serverfault.com/

  • Bernd Eckenfels Tuesday, February 11, 2014

    Does the mean the deployment configuration file also influences jvm installs which are not started as JNLP or Applet?

    Why is it "common with TLS implementations" to not enable the forward secrecy? In fact it is more and more common to enable those cipers.

    I think the "E" in DHE stands for Ephermal not Exchange (because there are also DH exchange ciphers using the fixed mode).

    What about the new GCM modes. They are part of TLS 1.2 and greatly improves the security of 1.2 with new ciphers. They are the new "stars" on the sky as they allow more efficient native implementations (as they cover the integrity protection part as well). However recent measurements show, that in Java they cannot use the hardware support and are therefore much slower than AES. Are those enabled by default as they are required by RFC6460 (Suite-B) and do you expect performance regressions by that? Are you planning to provide a native speedup or will customers have to use PKCS11 native libraries (again).



Please enter your name.Please provide a valid email address.Please enter a comment.CAPTCHA challenge response provided was incorrect. Please try again.