Transport Layer Security (TLS)

Transport Layer Security (TLS) is a protocol that provides privacy and data integrity between two communicating applications. It’s the most widely deployed security protocol used today, and is used for Web browsers and other applications that require data to be securely exchanged over a network, such as file transfers, VPN connections, instant messaging and voice over IP.

TLS evolved from Netscape’s Secure Sockets Layer (SSL) protocol and has largely superseded it, although the terms SSL or SSL/TLS are still sometimes used. Key differences between SSL and TLS that make TLS a more secure and efficient protocol are message authentication, key material generation and the supported cipher suites, with TLS supporting newer and more secure algorithms. TLS and SSL are not interoperable, though TLS currently provides some backward compatibility in order to work with legacy systems.

According to the protocol specification, TLS is composed of two layers: the TLS Record Protocol and the TLS Handshake Protocol. The Record Protocol provides connection security, while the Handshake Protocol allows the server and client to authenticate each other and to negotiate encryption algorithms and cryptographic keys before any data is exchanged.


Implementation flaws have always been a big problem with any encryption technology, and TLS is no exception. The infamous Heartbleed bug was the result of a surprisingly small bug in a piece of logic that relates to OpenSSL’s implementation of the TLS heartbeat mechanism, which is designed to keep connections alive even when no data is being transmitted

Although TLS is not vulnerable to the POODLE attack, because it specifies that all padding bytes must have the same value and be verified, a variant of the attack has exploited certain implementations of the TLS protocol that don’t correctly validate encryption padding. This makes some systems vulnerable to POODLE, even if they disable SSL — one of the recommended techniques for countering a POODLE attack.


The IETF officially took over the SSL protocol to standardize it with an open process and released version 3.1 of SSL in 1999 as TLS 1.0. The protocol was renamed TLS to avoid legal issues with Netscape, which developed the SSL protocol as a key feature part of its original Web browser.

TLS 1.2 is the current version of the protocol, and as of this writing, the Transport Layer Security Working Group of the IETF is working on TLS 1.3 to address the vulnerabilities that have been exposed over the past few years, reduce the chance of implementation errors and remove features no longer needed.


TLS 1.3 is expected to be based on the earlier TLS 1.1 and 1.2 specifications, but without unnecessary options and functions, such as support for compression and non-AEAD (Authenticated Encryption with Associated Data) ciphers. It may not support SSL 3.0, either.


The IETF has also decided to move away from RSA-based key transport in favor of protocols that support perfect forward secrecy and are easier to analyze. RSA certificates will still be allowed, but key establishment will use standard Diffie-Hellman or elliptical curve Diffie-Hellman key exchange. Support for HMAC-SHA256 cipher suites has been added, while the IDEA and Data Encryption Standard (DES) cipher suites have been deprecated.


The IETF’s Using TLS in Applications (UTA) working group plans to offer common guidelines and best practices for using TLS in applications, such as the use of the latest cryptographic algorithms and eliminating the use of older TLS/SSL versions, as well as guidance on how certain applications should use the encryption protocol. TLS 1.3 is still a draft and has not been finalized yet, but having an updated protocol that’s faster, more secure and easier to implement is essential to ensure the privacy and security of information exchange and maintain trust in the Internet as a whole.

Leave a Reply

Your email address will not be published. Required fields are marked *