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:
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:
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.
Adoption statistics from the Trustworthy Internet's SSL Pulse show a sufficient number of internet-facing systems using TLS 1.2 and compatible ciphers.
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.
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:
Will Java 7 also enable TLS 1.2 by Default with a future build ?
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.
Guest, you can always write a simple custom SSLSocketFactory which sets the appropriate defaults (protocols/suites/etc) on a SSLSocket before hand off.
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+">
<rule>
<id location="javatester.org" />
<action permission="run" version="1.6.0_35" />
</rule>
</ruleset>
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.
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/
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).
Gruss
Bernd