Transport Layer Security (TLS) is one of the most important and widely used security protocols. It protects a significant proportion of the data that gets transmitted online. It is most prominently used to secure data traveling between a web browser and a website via HTTPS, but it can also secure email and many other protocols.
TLS is valuable because it ensures that the other party in the connection is who they say they are, shows whether data retains its initial integrity, and provides confidentiality through encryption.
TLS uses a range of different algorithms and schemes to accomplish these objectives. It may sound not very easy, but this article will cover one aspect at a time to give you an in-depth look at how TLS works to secure connections.
What does TLS do?
When sending information online, we face three major security issues:
How can we know that the person we are communicating with is really who they say they are?
How can we know that the data has not been tampered with since it was sent?
How can we prevent other people from seeing and accessing the data?
These issues are important, especially when we are sending sensitive or valuable information. TLS uses several cryptographic techniques to address each of these three problems. Together, they allow the protocol to authenticate the other party in a connection, check the integrity of the data, and provide encrypted security.
Let's simplify things and pretend you're trying to transfer information back and forth with a friend who lives across the country. If the information is sensitive, you will be very concerned about the three major problems mentioned above.
Way. You can't just send a letter and hope for the best, especially if you suspect your communications will be targeted by attackers. Instead, you need a system that allows you to verify that your recipient is legitimate, a way you can check if messages have been altered, and a way to protect them from prying eyes.
TLS meets these requirements by using several different processes. This is known as the TLS handshake, where authentication occurs and keys are established.
To return to our letter analogy, the authentication part of TLS would be like sending a letter via a courier that requires identification. When the courier delivers the letter, they compare the person's ID with their face and verify whether the recipient is correct.
The major installation step will be like your letter containing half of the PIN you want to use in future communications. You will ask your recipient to come up with another part of the number and send it to you in your return letter.
Once the courier has verified identity and the PIN has been established, you will have everything you need to send the information securely. In fact, these steps are much more complicated, but we'll get to that later.
TLS securely exchanges information with application protocols. To further our analogy, transmitting data securely over TLS would be like writing a message and putting it in an envelope. You would write your signature on the seal so that if the letter were tampered with, your recipient would be able to tell by the ripped signature (this is actually done with math, but again, we'll cover this in-depth later).
You would then put the letter into a small metal box that had the combination lock, setting the combination as the PIN that you jointly established with your recipient. You will send the box via courier, who checks the identity when the package is delivered. Your recipient will reply in the same way, and any future communication will follow the same steps.
TLS solves all three of our problems in a relatively similar way. The courier performs the task of authenticating the recipient and ensuring that the box is delivered to its intended person. The locked box serves as a form of encryption, preventing anyone except your partner from accessing the letters. The signed envelope tells you whether the message has been tampered with.
This is a very rough approximation of what TLS does. In fact, TLS is between the client and the server, not between two people sending mail to each other. The analogy is to give you a view of what is happening and the logic behind it. In the following sections, we'll elaborate on what exactly happens.
TLS vs. SSL
Secure Sockets Layer (SSL) is an older version of TLS, but many people in the industry still refer to TLS under the old moniker. When reading about TLS, you will often see mention of SSL or even TLS/SSL. This article will use the term TLS throughout, but it is important to note that the names are often used interchangeably. You can read more about SSL in our guide.
TLS. History of
It all started with the need to secure the transport layer. As we mentioned above, the precursor to TLS was SSL. The first version of SSL was developed in the nineties by Netscape, a company that manufactured one of the early web browsers.
SSL 1.0 was never released because it had serious vulnerabilities. Version 2.0 came out with Netscape Navigator 1.1 in 1995, although it still had several serious flaws. SSL 3.0 was a heavily redesigned version and came out in 1996, resolving several security issues.
In 1996, the IETF released a draft of SSL 3.0 in RFC 6101. The IETF formed a working group to standardize SSL, publishing the results as TLS 1.0 in 1999. This was documented in RFC 2246, and standardization included some changes to the original protocol and a name change. These amendments resulted from negotiations between Netscape, Microsoft, and the IETF Working Group.
In 2006, the IETF released RFC 4346, which documents TLS 1.1. This version included new security provisions and many other updates. Version 1.2 was released two years later, in 2008. This included support for authenticated encryption ciphers, several changes to how hash functions were used, and many other improvements.
The next version didn't arrive until 2018 when TLS 1.3 was defined. This includes several changes, including implemented forward secrecy, support for vulnerable algorithms, and more.
According to a survey by Qualys, as of February 2021, TLS 1.3 is supported by about 43 percent of Alexa's top websites. The same source showed that more than 99 percent of websites support TLS 1.2. Major browsers such as Safari, Chrome, and Edge have already stopped supporting TLS 1.0 and 1.1 by default. Microsoft Edge and Mozilla Firefox will do the same at some stage shortly.
TLS: Technical Details
TLS consists of many different elements. The fundamental part is the record protocol, the underlying protocol being responsible for the broad structure of everything else.
TLS-3
TLS Protocol Stack by JeffreetedJosukamono. Diagram showing TLS stack. Licensed under CC0.
The record protocol consists of five different subprotocols, each of which is formatted as a record:
Handshake - This protocol is used to set parameters for a secure connection.
Application - The application protocol starts after the handshake process and is where data is transmitted securely between two parties.
WARNING - The warning protocol is used by either party to notify the other of any errors, stability issues, or potential compromise.
Change Cipher Spec - This protocol is used by the client or server to modify encryption parameters. It's pretty straightforward, so we won't cover it in-depth in this article.
Heartbeat - This TLS extension lets one party of a connection know whether its peer is still alive and prevents firewalls from closing idle connections. This is not a core part of TLS, so we'll leave it in this guide.
Each of these subprotocols is used at different stages to communicate different information. The most important to understand are the handshake and application protocols, which are responsible for establishing a connection and then securely transmitting data.
TLS 1.2 Handshake Protocol
This is where the connection is established securely. This may sound complicated if you are new to some concepts, but each of them is covered later in the article if you need to refer to them.
There are three basic types of TLS handshakes: the basic TLS handshake, the client-authenticated TLS handshake, and the abbreviated handshake.
Basic TLS 1.2 Handshake
Diagram showing the TLS handshake process. Full TLS 1.2 handshake by FleshGrinder. Licensed under CC0.
It starts with the negotiation phase, where the client sends the client a hello message. In this type of handshake, only the server is authenticated, not the client. It contains the highest version of TLS the client supports, the possible cipher suite, an indication of whether it supports compression, a random number, and some other information.
The client hello message is received from the server hello message. This response contains the session ID, protocol version, cipher suite, and compression (if any are being used) that the server selected from a list of clients. It also includes a different random number.
It depends on the cipher suite that has been chosen, but the server will usually follow it up by sending a certificate message for authentication. It validates its identity and contains its public key.
If ephemeral Diffie–Hellman or anonymous Diffie–Hellman key exchanges are being used, this is followed by a server key exchange message. Other major exchange methods omit this part. When the server is finished with its side of the conversation, it sends a Server Hello Done message.
Now it's the customer's turn again. Depending on the cipher suite chosen, this client will send key exchange messages. It may contain a public key or a permissive secret encrypted with the server's public key.
Both sides then use random numbers and the premade secret to come up with a master secret. The keys are derived from the master secret, which is then used to authenticate and encrypt the communication.
The client then sends a change cipher spec message. This tells the server that the following messages will now be authenticated and encrypted (although sometimes encryption may not be used).
The client then follows it up with an expired message, which is encrypted and contains a Message Authentication Code (MAC) for authentication. The server decrypts this message and verifies the MAC. If any of these processes fail, the connection should be refused.
Now it's the server's turn to send a Change Cipher spec message, as well as an expired message with the same content as above. The client then also tries to decrypt and verify the content. If all of this is completed successfully, the handshake is over. At this point, the application protocol is established. The data can then be exchanged securely as the above-terminated messages, with authentication and optional encryption.
client-authenticated TLS handshake
This handshake is like the basic TLS handshake, but the client is also authenticated. After the server sends its certificate message, the main difference is that it also sends a certificate request message, asking for the client's certificate. After the server terminates, the client sends its certificate in a certificate message.
The client then sends its client key exchange message, as in the original TLS handshake. This is followed by the certificate verification message, which contains the digital signature of the client. Since it is computed from the client's private key, the server can verify the signature using the public key sent as part of the client's digital certificate. The rest of the client-authenticated TLS handshake is the same as the original TLS handshake.
You must be logged in to post a comment.