Transport Layer Security

Overview #

Transport Layer Security is the degree of resistance to encountering an unfortunate event at the Transport Layer

Transport Layer Security (TLS) is also, and most often, a protocol for creating secure connection between clients and servers at the Transport Layer

Transport Layer Security is an improved and standardized form of the Secure Socket Layer (SSL).

Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS)#

Transport Layer Security (Transport Layer Security) and Datagram Transport Layer Security (DTLS) are widely used to protect data exchanged over application protocols such as HTTP, SMTP, IMAP, POP, SIP, and XMPP. Over the last few years, several serious attacks on TLS have emerged, including attacks on its most commonly used cipher suites and their modes of operation. This document provides recommendations for improving the security of deployed services that use TLS and DTLS. The Recommendations for Secure Use of Transport Layer Security (TLS) and Datagram Transport Layer Security (DTLS) are applicable to the majority of use cases.


SSL-TLS is a protocol with a long history and several versions. First prototypes came from Netscape, when they were developing the first versions of their flagship browser, Netscape Navigator (this browser killed off Mosaic in the early times of the Browser Wars, which are still raging, albeit with new competitors).

SSL Version 1 has never been made public so we do not know how it looked like. SSL version 2 (SSLv2), is described in a draft, had a number of weaknesses, some of them rather serious, so it is deprecated (RFC 6176) and newer SSL-TLS implementations do not support it (while older deactivated by default).

SSLv3 version 3 was an enhanced protocol which still works today and is widely supported. Although still a property of Netscape Communications (or whoever owns that nowadays), the protocol has been published as an "historical RFC" RFC 6101. Meanwhile, the protocol was standardized, with a new name in order to avoid legal issues, the new name is TLS.

Three versions of TLS have been produced to far, each with its dedicated RFC:

They are internally very similar with each other, and with SSLv3, to the point that an implementation can easily support SSLv3 and all three TLS versions with at least 95% of the code being common.

Still internally, all versions are designated by a version number with the major.minor format; SSLv3 is then 3.0, while the TLS versions are, respectively, 3.1, 3.2 and 3.3.

Thus, it is no wonder that TLS 1.0 is sometimes called SSL 3.1 (and it is not incorrect either). SSL 3.0 and TLS 1.0 differ by only some minute details. TLS 1.2 is not yet widely supported, although there is impetus for that, because of possible weaknesses (see below, for the "BEAST attack"). SSLv3 and TLS 1.0 are supported nearly "everywhere".


SSL-TLS aims at providing a secure bidirectional tunnel for arbitrary data. Consider TCP, the well known protocol for sending data over the Internet. TCP works over the IP "packets" and provides a bidirectional tunnel for bytes; TCP works for every byte values and send them into two streams which can operate simultaneously. TCP handles the hard work of splitting the data into packets, acknowledging them, reassembling them back into their right order, while removing duplicates and re-emitting lost packets. From the point of view of the application which uses TCP, there are just two streams, and the packets are invisible; in particular, the streams are not split into "messages" (it is up to the application to take its own encoding rules if it wishes to have messages, and that's precisely what HTTP does).

TCP is reliable in the presence of "accidents", i.e. transmission errors due to flaky hardware, network congestion, people with smartphones who walk out range of a given base station, and other non-malicious events. However, an ill-intentioned individual (the "attacker") with some access to the transport medium could read all the transmitted data and/or alter it intentionally, and TCP does not protect against that. Hence SSL.

SSL-TLS assumes that it works over a TCP-like protocol, which provides a reliable stream; SSL-TLS does not implement remission of lost packets and things like that. The attacker is supposed to be in power to disrupt communication completely in an unavoidable way (for instance, he can cut the cables) so SSL's job is to:

  • detect alterations (the attacker must not be able to alter the data silently);
  • ensure data confidentiality (the attacker must not gain knowledge of the exchanged data).
SSL-TLS fulfills these goals to a large (but not absolute) extent.

TLS Protocol Limitations#

In addition to Exploits against Transport Layer Security, there are also some fundamental TLS Protocol Limitations.

How SSL-TLS Works#

In LDAP TLS is implemented by the usage of the StartTLS.

TLS Maturity Model#

More Information#

There might be more information for this subject on one of the following: