What is Transport Layer Security (TLS)? Strengths and Vulnerabilities Explained

[harlan4096]

From SSL to TLS – A very brief history

Every online ‘novitiate’ begins with an exercise in security. By now, you must have stumbled upon alien-like concepts such as “SSL”, “TLS”, “handshake protocol”, “AES”, or “MD5-SHA-1”. To call them perplexing, would be a major understatement – unless you’ve majored in computer sciences or cryptography, of course. In seeing how many sysadmins or even simple users get bogged down by the intricacies of security protocols, in today’s article we will be tackling one of the gold standards of secure communication: The Transport Layer Security or TLS.

1.0. What is Transport Layer Security?

According to the RFC 5246 whitepaper, published on IETF’s (Internet Engineering Task Force) website, TLS is a cryptographic protocol, designed to safeguard the communication between a client and a server. Virtually everything we know about the Internet revolves around the concept of secure communications, regardless if it’s web surfing, sending an instant message over a dedicated platform (i.e. WhatsApp), emailing your manager, or communicating over a VoIP application.

TLS gets its name from the rather peculiar way it differentiates itself from the single-layer model, ascribed to the OSI (Operation System Interconnection)[1] and the TCP/IP models. Given the fact that TSL is security and not a transport protocol, it’s designed to run on top of some type of transport protocol; TCP is an as good example as any. However, in practice, there are some types of applications that ‘override’ TLS’ security functions, employing it as a transport medium.

The Transport Layer Security protocol has a long-winded history, but everyone agrees (to disagree!) that it was a ‘necessary evil’, in the sense that its creators wanted to find a way to overcome the shortcomings of SSL (Secure Sockets Layers), TLS’s predecessor. To fully understand why the adoption of TSL was imperative, let’s take a closer look at the chronology.

1.1. SSL to TSL Shift – Highlights

Here are the events that led to the adoption of TSL and the deprecation of SSL.

1986 – Project Secure Data Network System (SDNS) is set in motion. Several governmental and non-governmental agencies participate. Among them are NSA, National Bureau of Standards, and the Defense Communication Agency. The purpose of Project SDNS was to revamp the existing approach to secure the computer comm over the network.

1987 – Project SNDS’ highlights and innovations are presented during the 10th National Computer Science Security Conference. Both TLS and SSL are being pushed as standards for secure network communication.

1993 – Research into the transport layer security variant begins. The SNP (Secure Network Programming) API is created. Scientists believe that APIs could facilitate the effort to secure existing network applications.

1994 – Taher Elgamal, Netscape’s chief scientist, comes up with the version 1.0 of the Secure Socket Layer protocol. The first version would go unpublicized, due to various security flaws.

1995 – SSL version 2.0 is released. Poised to die in harness, as early results indicated that SSL 2.0 is as flawed as its predecessor.

1996 – SSL version 3.0 is released. Undergoes complete retrofitting. The same year, SSL 3.0’s anointed the next cryptologic gold standard. Will eventually be published on IETF’s website, under the name of RFC 6176.

1999 – Dierks and Allen of the Consensus Development publish their joint paper on TLS version 1 (RFC 2246).

2006 – TLS version 1.0 receives its first update. TLS 1.1 to get its historical document (RFC 4346).

2008 – Overhaul of TLS 1.1. Version 1.2 to be published in IETF, under RFC 5246.

2011 – SSL 2.0 is deprecated.

2015 – SSL 3.0 is deprecated.

2018 – TSL 3.0 is released.

2020 – Major software market players, including Mozilla, Microsoft, Apple, and Google announced that TLS 1.0 and TLS 1.1 will be deprecated until the end of the year.

Every online ‘novitiate’ begins with an exercise in security. By now, you must have stumbled upon alien-like concepts such as “SSL”, “TLS”, “handshake protocol”, “AES”, or “MD5-SHA-1”. To call them perplexing, would be a major understatement – unless you’ve majored in computer sciences or cryptography, of course. In seeing how many sysadmins or even simple users get bogged down by the intricacies of security protocols, in today’s article we will be tackling one of the gold standards of secure communication: The Transport Layer Security or TLS.

1.0. What is Transport Layer Security?

According to the RFC 5246 whitepaper, published on IETF’s (Internet Engineering Task Force) website, TLS is a cryptographic protocol, designed to safeguard the communication between a client and a server. Virtually everything we know about the Internet revolves around the concept of secure communications, regardless if it’s web surfing, sending an instant message over a dedicated platform (i.e. WhatsApp), emailing your manager, or communicating over a VoIP application.

TLS gets its name from the rather peculiar way it differentiates itself from the single-layer model, ascribed to the OSI (Operation System Interconnection)[1] and the TCP/IP models. Given the fact that TSL is security and not a transport protocol, it’s designed to run on top of some type of transport protocol; TCP is an as good example as any. However, in practice, there are some types of applications that ‘override’ TLS’ security functions, employing it as a transport medium.

The Transport Layer Security protocol has a long-winded history, but everyone agrees (to disagree!) that it was a ‘necessary evil’, in the sense that its creators wanted to find a way to overcome the shortcomings of SSL (Secure Sockets Layers), TLS’s predecessor. To fully understand why the adoption of TSL was imperative, let’s take a closer look at the chronology.

1.1. SSL to TSL Shift – Highlights

Here are the events that led to the adoption of TSL and the deprecation of SSL.

1986 – Project Secure Data Network System (SDNS) is set in motion. Several governmental and non-governmental agencies participate. Among them are NSA, National Bureau of Standards, and the Defense Communication Agency. The purpose of Project SDNS was to revamp the existing approach to secure the computer comm over the network.

1987 – Project SNDS’ highlights and innovations are presented during the 10th National Computer Science Security Conference. Both TLS and SSL are being pushed as standards for secure network communication.

1993 – Research into the transport layer security variant begins. The SNP (Secure Network Programming) API is created. Scientists believe that APIs could facilitate the effort to secure existing network applications.

1994 – Taher Elgamal, Netscape’s chief scientist, comes up with the version 1.0 of the Secure Socket Layer protocol. The first version would go unpublicized, due to various security flaws.

1995 – SSL version 2.0 is released. Poised to die in harness, as early results indicated that SSL 2.0 is as flawed as its predecessor.

1996 – SSL version 3.0 is released. Undergoes complete retrofitting. The same year, SSL 3.0’s anointed the next cryptologic gold standard. Will eventually be published on IETF’s website, under the name of RFC 6176.

1999 – Dierks and Allen of the Consensus Development publish their joint paper on TLS version 1 (RFC 2246).

2006 – TLS version 1.0 receives its first update. TLS 1.1 to get its historical document (RFC 4346).

2008 – Overhaul of TLS 1.1. Version 1.2 to be published in IETF, under RFC 5246.

2011 – SSL 2.0 is deprecated.

2015 – SSL 3.0 is deprecated.

2018 – TSL 3.0 is released.

2020 – Major software market players, including Mozilla, Microsoft, Apple, and Google announced that TLS 1.0 and TLS 1.1 will be deprecated until the end of the year.
...

Continue Reading