Contents:
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 (Open 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.
1.2. SSL to TSL timeline at a glance
Since TSL is a security & cryptographical protocol, it’s primary function remains to safeguard data integrity and privacy. To ensure that both conditions are met, any TLS forwarding has to meet several existential criteria. First, and foremost, there’s the privacy concern – data being transmitted to and fro the server to the client must be secured.
This is achieved through a method called symmetric encryption[2]. But even this method calls for cryptographical keys, which are generated at the beginning of each connection. Symmetric encryption key generation is done via the so-called shared secret[3]. This form of negotiation starts at the beginning of each secure communication session. The entire negotiation process between the client and the server also bears the name of the TSL handshake. I will provide you with more insight on TSL handshake in the section dedicated to TLS in network security.
Following this phase, the identity of both parties is being established. Although some cryptologists argue that this step’s more of a formality and should, therefore, be optional, practice dictates that at least one of the party’s identity (client or server, usually the latter) should be disclosed via a public-key exchange.
Finally, connection reliability remains to be established. To check the strength of the signal, both parties exchange a message authentication code (MAC).
The TLS protocol can be further broken down into two smaller protocol: the TLS handshake and the TLS record. Let’s take a closer look at both of them.
1.2.1 How the TLS Handshake works
As I’ve explained, the TLS handshake (as the name suggests) is how the client and server ‘talk turkey’. During this step – which happens in the blink of an eye – several things occur: the two entities kick it off by swapping messages. I’ll get to that later. This step is necessary to confirm that both parties say they are who they are.
Next comes the verification stage, followed closely by a little ‘chat’ about what type of encryption algorithms this type of secure communication will be using. The chat is concluded when both parties agree on session keys. This would be the TSL handshake at a glance. However, there are far more things happening behind the scenes. Let’s take a peek and see what we can learn.
a) ‘Hello, server!’
The client (i.e. user’s web browser) initiates the TLS handshake via a very friendly “hello” sent to the server. Type of info transmitted during the client “hello”: TLS version supported by the client, a list of ciphers that the clients support, and the so-called “client random”[4].
b) “Hello, client!”
The server relays a similar “hello” message to the user in order to establish its identity. Type of info transmitted during “server hello”: SSL certificate, the “server’s random” (similar to the “client random”), and its own list of supported ciphers.
c) Authentication
During this phase, after having received the SSL certificate from the server, the client cross-references with the official list issued by the certificate authority, in a bid to establish its authenticity.
d) Transmitting the premaster secret
To further strengthen privacy, the client sends a “premaster secret”. In cryptography, a premaster secret refers to a unique and random string of bytes transmitted to the server for decryption. This string is encrypted with a public key obtained from the SSL certificate which was previously transmitted by the server (see the “hello, client!” phase).
e) Private key decryption
Once the client transmits the premaster secret, the server will begin decrypting it.
f) Establishing session-specific keys
During this phase, another privacy layer is added. This is achieved by creating session-specific keys. Bear in mind that these keys are generated by both the client and the server. The process involves a ‘mix’ of cryptographical elements: server + client random and, of course, the premaster secret. As for the method of transmission, the session-specific keys are sent and received at the same time (client-server, server-client).
g) “Thank you, server!”
Once all of the above-mentioned conditions are met, the client pipes through a “finished/thank you” message to the server. The message itself is encrypted by a session key.
h) “Thank you, client!”
In a mirror darkly, as the saying goes – the server sends a “finished/thank you” message to the client, which is also encrypted by a session key.
i) Secure communication is established.
After completing the TLS handshake, the client and server can now proceed with communicating over a secure channel.
Note: the model I’ve described is using the asymmetric encryption model, supported by the RSA key exchange algorithm.
Unfortunately, further research has discovered that comms encrypted by the RSA algorithm are highly vulnerable to Man-in-the-Middle attacks.
This is the very reason why the asymmetric encryption method is far more leveraged compared to the symmetric ones. In asymmetrically-encrypted TLS communications, RSA is augmented by something called an ephemeral Diffie-Hellman key exchange.
Here’s how the TSL handshake looks like within the boundaries of the D-H model.
a) “Hello, server!”
The client ‘waves’ to the server. In this phase, the client sends the supported ciphers list, the client random, and, of course, protocol version.
b) “Hello, client!”
In addition to the client’s random, supported ciphers list, and SL certificate, the server will also send the confirmation for its digital signature. What that means is that the server encrypts its data functions with a unique digital signature. This will tell the client that the server holds the private key that matches the public key ‘stamped’ on the SSL certificate.
c) Establishing the server’s identity
Upon receiving the digital signature from the server, the client will begin decrypting it to validate the server’s identity. In return, the client will transmit its D-H parameters to the server.
d) Computing the premaster secret
Instead of generating the premaster secret based on the SSL certificate, in DH, the client and server calculate the premaster secret on their own, in a bid to find a common denominator.
e) Generating session keys
After the client and server agree on a premaster secret, they generate and exchange session keys.
Note: the steps that follow are identical to those described by the RSA model.
1.2.2. What is the TLS Record?
TLS’s second sub-protocol, which is called the TLS Record, is one gigantic (and very virtual) piece of carbon paper. Basically, every bite, every operation, connection attempt, approval, rejection, message, key exchange is recorded by this sub-protocol.
Similar to the TLS protocolary dichotomy (handshake and record), this second sub-protocol can also be broken down into several sub-sections, each governing a very specific area of the secure communication process.
I won’t go into too many details since I don’t want to drift too far from the main topic, but I will say this much – the TLS Record encloses hexadecimal info pertaining to cipher changes, alerts, handshake types, applications, MAC exchange and padding, type of messages displayed during the handshake, warning, errors, and the length of the application data.
To see The Transport Layer Security in action, check out the video below.
TLS in Network Security. Strengths and Vulnerabilities.
The Transport Layer Security protocol has a wide range of applications: from software that require data encryption, all the way to web browsers, with the emphasis being on the latter. As I’ve pointed out earlier in the article, the TLS protocol usually ‘piggybacks’ on a TCP (Transmission Control Protocol).
To further facilitate the implementation of TLS and, therefore, enhance the privacy of secure communications, TLS protocols are usually intermeshed with UDPs (User Datagram Protocols) and DCCPs (Datagram Congestion Control Protocols). Moreover, TLS protocols are usually employed to secure the data in the most used ‘over-the-air’ protocols such as FTP, HTTP, NNTP, and XMPP.
As far as TLS implementation is concerned, although TLS version 1.3 is considered, by far, the most secure encryption protocol, website adoption lags far behind.
According to SSL Pulse’s assessment, as of January 2020, only 22% of interviewed websites (around 30,000) support TLS 1.3.
On the other end of the spectrum, TLS 1.2 has been implemented across 96,6% of websites (around 135,000). One possible explanation would be that the 1.3 is relatively new compared to v.1.2 and 1.1, being somewhat more difficult to integrate into the existing network architecture. However, considering the decision to deprecate everything below the TLS version 1.0.
From a sysadmin standpoint, it stands to reason that all your communications should be secured by a strong encryption protocol.
In praxis, the best symmetric key encryption is without a doubt AES-256 and RSA – 4096 for public-key encryption. Other algorithms are available, but implementation is quite difficult.
Why should you use TLS for your secure communications? Here’s a short, yet very compressive list of advantages and disadvantages of employing TLS.
TLS advantages:
- Prevents tampering and eavesdropping. TLS encryption prevents malicious actors from interposing itself between the web browser and the client.
- Data integrity. Enforcing TLS ensures that all the data transmitted over a secure medium will reach its destination without any losses.
- Brand awareness and improving customers’ trust. Sites secured by TLS will instill a feeling of trust in your customers. A client is far more likely to conduct transactions over your website if the connection’s secured.
- MAC authentication in TLS is far more secure compared to SSL since the latter uses HMAC (Key-Mashing Authentication Code) a cryptographical method that prevents a potential malicious actor from tampering with TLS record while in transit.
- Granular control over what goes on during the session. TLS’s alert system is far more advanced and reactive compared to that employed by SSL. If something happens during transit, the user will immediately be alerted.
TLS disadvantages:
- Higher latency compared to other secure encryption protocols. A StackPath study revealed that connections encrypted by TSL have a 5ms latency compared to those that have not been encrypted. Furthermore, the machines on which the ‘stress tests’ were conducted on showed a 2% CPU spike on processing TLS-encrypted comms.
- Older TSL versions still vulnerable to MiM attacks. TLS versions 1.0 through 1.2 have still found to be susceptible to Man-in-the-Middle attacks, as well as other forms of cyber aggression: POODLE, DROWN, and SLOTH.
- Few platforms support TLS 1.3. There are a handful of platforms that support the latest TLS version: Chrome (version 67+), Firefox (version 61+), and Apple’s Mac OS 10.3 (iOS 11). Microsoft is still struggling with the implementation process.
Closing thoughts on network security
As always, the sysadmin is the one who has the final say in what goes on in the area of cybersecurity. Before we part ways, I would very much like to leave you with a couple of tips that may (or not) help you devise an effective cyber-defense strategy or, in the very least, convince your CEO why sometimes the best defense is a devastating offense.
#1. Find a suitable tool to automate the certificate deployment process
A CISCO study pointed out that although all companies are striving to implement a better and more secure protocol, a whopping 80% of them are still relying on manual input. Automating the certificate deployment process can save a lot of resources, freeing up the department for other tasks. It would be for the best to start implementing the TLS as soon as possible since DoH has started to gain even more ground in the area of privacy.
#2. Make sure to account for all attack vectors
By quickly implementing TLS version 1.3, you significantly reduce the risk associated with eavesdropping attacks. However, a DNS filtering solution is also warranted in this case to cover all foreseeable attack vectors. Heimdal™ Threat Prevention, Heimdal Security’s award-winning traffic-filtering solution actively scans the entire network for any signs associated with malware penetration from malicious infrastructure.
Heimdal® DNS Security Solution
- Machine learning powered scans for all incoming online traffic;
- Stops data breaches before sensitive info can be exposed to the outside;
- Advanced DNS, HTTP and HTTPS filtering for all your endpoints;
- Protection against data leakage, APTs, ransomware and exploits;
Wrap-up
TLS is by far, one of the most secure comm encryption methods. Version 1.3 brings many security-wise improvements but also makes implementation more difficult compared to other versions. We look forward to seeing more websites and sysadmins deploying TLS.
[1] Overview of the telecommunication hierarchy. OSI features two types of layers: media (physical, data link, network) and host (transport, session, presentation, and application).
[2] Practice involving the use of the same encryption key for both the plaintext and the cyphertext.
[3] Information known only to both parties, usually before the start of each secure communication.
[4] A random string of bytes used “client hello” in order to establish the client’s identity.
