Agencies must update to newer versions of Transport Layer Security
Connecting state and local government leaders
New guidance from NIST for using TLS in government applications requires later versions of the protocol because of vulnerabilities in version 1.0.
Agencies using Transport Layer Security (TLS) to protect sensitive but unclassified data must move to later versions of the protocol that correct vulnerabilities found in version 1.0.
The National Institute of Standards and Technology has revised its guidance for using TLS in Special Publication 800-52. Originally released in 2005, the publication was withdrawn in March 2013 while it was updated to include requirements for using versions 1.1 and 1.2 of TLS and to restrict the use of the vulnerable version.
TLS is a standard of the Internet Engineering Task Force for securing connections between clients and servers over untrusted networks. Although TLS is based on Secure Sockets Layer (SSL), it is separate from OpenSSL, a commonly used open source tool which was recently found to contain a serious vulnerability that has been named Heartbleed. The vulnerabilities found in TLS are not related to Heartbleed.
The new guidance requires that servers supporting government applications support TLS 1.1 at a minimum and that they should support version 1.2. Government clients are allowed to support the vulnerable TLS 1.0 in order to connect with non-government servers when necessary, but the later versions of the protocol must be used by the government client when they are supported by the server being contacted.
Agencies must develop migration plans to support TLS 1.2 by Jan. 1.
TLS uses public key cryptography to exchange keys used to encrypt and secure sensitive information being sent over the Internet. It is based on SSL version 3.0, and is sometimes referred to as SSL 3.1. Because of the improvements in TLS, it is specified for use in government systems, although SSL and OpenSSL also are commonly used in private sector applications. SP 800-52 Revision 1 provides guidance on using the later versions of TLS, with options for configuration, algorithms and length of encryption keys.
Government servers are not allowed to use TLS 1.0 or SSL 3.0. It is recommended that servers support multiple public key certificates in order to support multiple algorithms and key sizes, depending on the specified keys of the client. Six TLS server certificates are approved for use on government servers:
- RSA key encipherment certificate
- RSA signature certificate
- Elliptic Curve Digital Signature Algorithm (ECDSA) signature certificate
- Digital Signature Algorithm (DSA) signature certificate
- Diffie-Hellman certificate
- ECDH certificate
At a minimum, the server must be configured with the RSA key encipherment certificate and should also have either the RSA or ECDSA signature certificate. Certificates must be issued by a certificate authority, not self-signed.
The Heartbleed vulnerability discovered in OpenSSL and announced last month was the result of an “improvement” made in the open source tool, which disabled a memory management feature intended to prevent security leaks. This allowed data to leak in 64-kilobyte chunks that could be used to recover crypto keys or other sensitive information.
This “improvement” was fixed in version 1.0.1g of OpenSSL, but the process of updating installations of vulnerable versions, revoking and reissuing keys and resetting passwords and other credentials could take quite a while to complete.