Security is top-of-mind, especially right here where Juniper experts share their insights on the latest security trends and breakthroughs
Juniper Employee , Juniper Employee Juniper Employee
NIST Deprecates TLS 1.0 for Government Use

Network Security.jpg

A few weeks ago, the National Institutes of Science and Technology (NIST) quietly published Revision 1 to Special Publication 800-52, Guidelines for the Selection, Configuration, and Use of Transport Layer Security (TLS) Implementatio...

Transport Layer Security are cryptographic protocols which are designed to provide communication security over the internet and is used in Secure Socket Layer (SSL) based Virtual Private Networks.

Over the years SSL has morphed into TLS.  First there was SSL 2.0 (Version 1.0 was never publically released).  Shortly after SSL 2.0 was released, SSL 3.0 was released.  TLS 1.0 was first defined in RFC 2246, in 1999.  TLS 1.1 was defined in RFC 4356, published in 2006.  TLS 1.2 was defined in RFC 5256 in 2008.  Each subsequent version provided stronger and stronger security.

So what is significant about the recent NIST publication?

The original version of the NIST document mandated the use of at least TLS 1.0 and precluded the use of SSL 3.0 and below.  This new revision requires that TLS 1.1 configured with FIPS-based cipher suites as the minimum appropriate secure transport protocol and recommends that agencies develop migration plans to TLS 1.2 by January 1, 2015.  SP 800-52, revision 1 also mandates that TLS implementation use FIPS 140-2 validated cryptographic modules and random number generators.  So basically systems which may have been approved for operation in early April, are no longer approved and every government agency is tasked to be ready to transition to FIPS validated TLS 1.2 by the beginning of next year.

Many customers will be busy evaluating their webservers and their web browsers to insure that they are compliant.  Customers shouldn’t forget to look at their remote access VPN solutions.  If you have a SSL/TLS based VPN, and it is not using TLS 1.2, it needs to be upgraded.  If your SSL/TLS VPN doesn’t support TLS 1.1, it needs to be upgraded in a hurry.

NIST SP 800-52, Revision 1 also strongly recommends that TLS implementations use forward secrecy through the use of ephemeral keys.  I discussed ephemeral keys and forward secrecy several months ago.  Juniper Networks added support of ephemeral keys at the same time support for TLS 1.2 was added.

So what about the Juniper Networks Junos Pulse Secure Access Service SSL VPN?  The good news is the Secure Access solution was enhanced over a year ago to include support for TLS 1.2 with the SA 7.4 software release.  The SA solution is already FIPS validated.  If you are running 7.4r1 or later, you are in good shape.  If not, you should consider upgrading soon.

Kevin Gray

Thanks for your post.  I've forwarded on this information to my colleagues so that they can check all of our systems, including the SSL VPN appliances.


So part of that though is "Thou shall NOT support TLS 1.0" and FIPS compliant doesn't necessarily mean you comply with this as the current FIPS 140-2 validated suite has not kept pace with 800-52 nor FIPS 180-4.  So the question here is does the FIPS compliant SA series or FIPS compliant JUNOS provide a mechanism to disable (but not enable) individual ciphers which are part of the FIPS suite, i.e. so I can disable TLS 1.0 or MD5 (to support 180-4).

Juniper Employee

Hi Peter,

I may not be following your point about FIPS 180-4, but an SA4500FIPS or SA6500FIPS appliance or a MAG or Virtual Appliance configured for FIPS operation should address your concern regarding MD5.  The SA should not support non-FIPS 140-2 approved ciphers.  MD5 is a not a FIPS approved cipher.

The legacy FIPS appliances will only support SHA and do not support MD5.  The MAG Appliances provide software FIPS, which must be enabled.  The supported cipher suites when FIPS Level 1 Support is enabled and disabled are found in the SA 8.0 documentation here in tables 5 and 6.

You raise a good point that there is a difference between supporting TLS 1.1 and 1.2 and enforcing a policy that only TLS 1.1 or 1.2 be used.  My point was you have to support TLS 1.1/1.2 before you can enforce a policy of only TLS 1.1/1.2.

We do not have the type of granular controls today that would allow you to configure the system to only accept TLS 1.1 or 1.2 sessions.  We can enforce a policy that TLS 1.0 or greater be used. We are working on this and hopefully you will see this type of granular control in a future release.   This granular cipher control should also allow us to enforce other cipher option preferences such as Suite B or the use of ephemeral keys, which today are negotiated. 

The good news is TLS will negotiate the cipher used based on the capabilities of both the server and the browser.  This means that although Secure Access doesn’t currently enforce TLS 1.2, it will negotiate it with browsers that are configured to support it. 

We can also enforce a policy that restricts access to only those browsers that are capable of supporting TLS 1.2, but that still leaves open the case of TLS 1.2 capable browsers that are not configured for TLS 1.2.

It might be possible to use host checker and registry policies on Windows machines to enforce a registry policy that TLS 1.2 be enabled on the browser, but this would take more investigation.