Americas

  • United States

What is Transport Layer Security (TLS)?

News
Nov 09, 20185 mins
Data CenterNetworkingSecurity

Transport-layer security is more effective than its predecessor SSL, and its latest version - TLS 1.3 - improves both privacy and performance.

Tablet with lock showing secure encryption
Credit: Thinkstock

Despite the goal of keeping web communications private, flaws in the design and implementation of Transport Layer Security have led to breaches. But the latest version – TLS 1.3 – is an overhaul that strengthens and streamlines the crypto protocol.

What is TLS?

TLS is a cryptographic protocol that provides end-to-end communications security over networks and is widely used for internet communications and online transactions. It is an IETF standard intended to prevent eavesdropping, tampering and message forgery. Common applications that employ TLS include Web browsers, instant messaging, e-mail and voice over IP.

Many businesses use TLS to secure all communications between their Web servers and browsers regardless of whether sensitive data is being transmitted.

TLS’s predecessor, secure socket layer (SSL) was developed by Netscape in 1995. SSL version 1.0 and 2.0 contained many security flaws that prompted a complete redesign of the protocol. In 1996, Netscape released SSL version 3.0 which was the basis for TLS1.0.  In 1999, the PCI Council suggested the eventual deprecation of SSL as TLS 1.0 was a significant upgrade to SSL 3.0. 

TLS vs. SSL  

TLS is more efficient and secure than SSL as it has stronger message authentication, key-material generation and other encryption algorithms. For example, TLS supports pre-shared keys, secure remote passwords, elliptical-curve keys and Kerberos whereas SSL does not.  TLS and SSL are not interoperable, but TLS does offer backward compatibility for older devices still using SSL.

The TLS protocol specification defines two layers. The TLS record protocol provides connection security, and the TLS handshake protocol enables the client and server to authenticate each other and to negotiate security keys before any data is transmitted.

The TLS handshake is a multi-step process.  A basic TLS handshake involves the client and server sending “hello” messages, and the exchange of keys, cipher message and a finish message. The multi-step process is what makes TLS flexible enough to use in different applications because the format and order of exchange can be modified.

TLS flaws and breaches

Flaws in protocols and implementations constantly cause problems with security tools and technology, and TLS has certainly had its share of breaches.  Some of the more significant attacks on TLS/SSL:

  • BEAST (2011): The Browser Exploit Against SSL/TLS is a browser exploit that took advantage of a weakness in the cipher blocking chain (CBC) to extract the unencrypted plaintext in an encrypted session.
  • CRIME and BREACH (2012 and 2013): The creators of BEAST authored the security exploit Compression Ratio Info-link Made Easy, which enables a hacker to retrieve the content of Web cookies, even when compression and TLS are used. One nefarious use case for this is recovering the authentication cookies so attackers can hijack authenticated web sessions. Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext, or BREACH, is built on CRIME and extracts login tokens, e-mail addresses and other information.
  • Heartbleed (2014): Heartbleed allows hackers to steal private keys from what should be secure servers. Infected servers were left wide open to let anyone on the Internet read the memory in systems being protected by a vulnerable version of OpenSSL. The breach let threat actors steal data from servers or listen in on conversations or even spoof services and other users.

TLS 1.3 boosts security, performance, privacy

TLS 1.3 was the first major rewrite as the Internet Engineering Task Force (IETF) set out to modernize the protocol. Think of previous versions being band aids put on flawed code. These might hold for a while but eventually the bad guys figured out how to work around that. The work on TLS1.3 started in April 2014, and it took four years and 28 drafts before it was approved in March of 2018.

In addition to making a major revision, the IETF set out to make what it called “major improvements in the areas of security, performance and privacy”. The biggest change is that TLS 1.3 makes it significantly more difficult for attackers to decrypt HTTPS-encrypted traffic and therefore better protect privacy.

Version 1.3 also makes the handshake process faster by speeding up the encryption process. This has a security benefit, but it should also improve performance of secure web applications. With TLS 1.2, the handshake process involved several round trips. With 1.3 only one round is required, and all the information is passed at that time.

Implementing TLS 1.3 should be simple as it’s designed to seamlessly replace TLS 1.2 and uses the same certificates and keys. Also, clients and servers can automatically negotiate a connection if it’s supported on both sides.  

Early in its development cycle there were a few issues, the most notable of which came to light at a school system in Maryland where about 20,000 Chromebooks bricked when upgraded to TLS 1.3. Also, financial-services organizations were vehemently opposed because the encryption made them blind to what was happening on their own networks. The IETF made a few enhancements to allow the protocol to work with monitoring tools if implemented correctly.

In addition to security improvements, TLS 1.3 eliminated a number of older algorithms that did nothing other than create vulnerabilities. These include:

  • RC4 Steam cipher
  • DES
  • 3DES
  • RSA Key transport
  • SHA-1 hashing
  • CBC Mode ciphers
  • MD5
  • Diffie-Hellman groups
  • EXPORT ciphers

Also, the updated protocol added a function called “0-RTT resumption” that enables the client and server to remember if they have communicated before. If prior communications exist, the previous keys can be used, security checks skipped and the client and server can begin communicating immediately. It is believed that some of the bigger tech companies pushed for 0-RTT because they benefit from the faster connections, but there is some concern from security professionals.

The security benefits alone should justify TLS 1.3, but there are network reasons as well. In addition to the security improvements, TLS 1.3 is lighter weight than its predecessor and uses fewer resources. This means its more efficient, consumes fewer CPU cycles and reduces latency, which leads to better performance.