Transport Layer Security Overview
Credits: Image by rawpixel.com on Freepik
I am getting security vibes today. So, we are going to explore a fundamental protocol that is widely used for secure information transfer: TLS. You have probably heard this name, but more certainly used it today (everyday) when you decided to open your browser and visit LinkedIn (or any website that uses HTTPS protocol).
Caution: a bit lengthy article ahead ??
What is TLS?
Before we explore further, let's understand what TLS actually is. As the article title suggests, it is short for Transport Layer Security. Remember that the TCP/IP model splits communication tasks into 4 layers:
Transport layer provides end-to-end communication services for the application layer. One of the protocols used in this layer is TCP (Transport Control Protocol), which establishes a reliable connection between the client and the server. TLS often runs over TCP (considered part of the Application layer, or sometimes, an additional layer between Transport and Application).
Note: There is also a variant of TLS called DTLS protocol (Datagram Transport Layer Security) which runs over UDP, but it is not discussed in this article.
Back to security perspective, TLS achieves 3 security goals: Authentication, Confidentiality, and Integrity. Authentication means you can verify the identity of the other communication party (e.g. your browser is sure that this is actually LinkedIn). Confidentiality means exchanged information is protected against unauthorized access (e.g. no third party can understand the information included in the ongoing packets). Integrity means the exchanged information is protected against manipulation.
How Does TLS Work?
TCP Connection
Now, how does TLS achieve these goals? To answer this, let us examine how TLS works in details. Establishing a TLS connection begins with establishing a TCP connection through the 3-way handshake.
We are going to use Wireshark to analyze the actual traffic between the browser on my laptop and LinkedIn. I have already set a display filter (ip.addr == 13.107.42.14) which is the address I got from pinging www.dhirubhai.net
192.168.1.112 is the client in this case (Me), whereas 13.107.42.14 is the server (LinkedIn). Notice here the destination port 443 is the global standard port number for HTTPS traffic. The 3-way handshake is established as above (Syn-SynAck-Ack).
TLS Architecture
Before explaining what happens next, let's first explore the main components of TLS. The unit of communication for TLS is called a Record. After establishing a secure connection, this "Record" should be confidential and protected.
In fact, to do this, we will see that TLS itself is not a single protocol. At the lowest part of it, we have the Record layer that is responsible for managing the mentioned records, above which resides one of the following protocols:
At early TLS phases, when the secure connection has not been established yet, the record layer will not use any cryptographic algorithms.
The Handshake Protocol is the first phase after establishing a TCP connection. This is responsible for selecting the TLS version, the algorithms (commonly called cipher suites), and achieving our first goal: Authentication through the usage of digital certificates and asymmetric encryption. Another important responsibility for this phase is to prepare the secret session key which will be used in later phases.
By the end of the handshake, The Change Cipher Spec Protocol signals the other party: From now on, we shall use confidential (encrypted) and protected (MACed?) records.
Later, an Application Protocol (In our case, HTTP) takes the wheel. However, the application data passes through The Record Layer which achieves the remaining 2 goals: Confidentiality & Integrity through the usage of symmetric encryption and message authentication codes (MAC). This can only be achieved after successful preparation of the secret session key during the handshake phase.
If an error occurs anytime, The Alert Protocol shall trigger the scary TLS alerts.
TLS Connection
Here is a diagram for the steps to establish the TLS connection:
Yeah, notice how huge the symbol "{" has become. Security tends to complicate matters ?? Anyway, some steps here are optional or depend on the situation. On the other hand, more optional steps that could be used are missing from the above diagram.
Following is an analysis for each step in the handshake.
Client Hello: This is an indication that the client wants to establish a secure connection using TLS. The client will hereby declare the highest TLS version it supports and the available cipher suites. The client may request additional data from the server by extensions. For example, the client asked the server to provide Certificate Status. Therefore, the server will send an additional message called Certificate Status ahead.
领英推荐
See the sweet cipher suites? There is an official registry for those guys. The name used to describe the cipher suite indicates all the algorithms to be expected. For example, TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256 means:
Server Hello: Here, the server responds with the TLS version (should be equal to or less than the client's version) & the selected cipher suite from the proposed list.
It seems that LinkedIn decided to use 0xC030 Cipher suite: TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384
Server Certificate: The server then proceeds to send its digital certificate to the client. The digital certificate holds the public key of the server and is signed by another trusted authority (Certificate Chain). This certificate chain may be additionally sent to the client (excluding the root).
Note that the server decided to accept our extension (status_request) and a Certificate Status message is sent after the certificate.
Server Key Exchange: This is an optional step (may not apply to other key exchange methods). But, since the server has chosen to use ECDHE, it needs to send some freshly generated parameters on the bus. To ensure no manipulation of the parameters happens here, the Server Key Exchange itself is signed with the private key of the server (In our case, signed using RSA). Since the client has the server public key from the previous step, it will use it to verify the data.
Server Hello Done: Just an indication for the client to proceed.
Client Key Exchange: The client now uses this message to respond with its ECDHE parameters. The content/meaning of this message (along with the Server Key Exchange) depends entirely on the key exchange algorithm. In our case, it is ECDHE. With this step, both the server and the client have enough information to derive the symmetric session key.
Change Cipher Spec: Reaching this step means we both have successfully obtained the secret key, so we need to switch to encrypted communication.
Finished: This message is actually encrypted (The first to be encrypted). In case the server has the correct secret key, it will understand this message and respond with Change Cipher Spec, then Finished too.
The bus is now encrypted, so without the appropriate key, we cannot decipher the content. On Wireshark, you will see the protocol as "Application Data" with no translation beyond TLS. However, with this tutorial, you will be able to observe the upcoming communication.
As expected, we have HTTP packets exchanged between both parties. Inspecting one of them, we can see TLS encrypted data:
The connection will remain ongoing until both parties send a TLS alert "Close Notify" and close the TCP connection afterwards (Fin-FinAck-Ack).
Client Authentication
The client authentication using TLS is optional (because commonly, the client is authenticated using other ways: passwords and such). However, TLS provides a step for the server to request the client certificate before ending its long Server Hello.
Phew! congratulations for reaching the end ?? A lot of details regarding TLS protocol & the underlying security algorithms have been omitted in this article. However, you can check the references (or the scattered links across the article) to cover the missing information.
Thank you for reading. Don't forget: any contribution is appreciated!
References:
Principal Embedded Software Engineer - AUTOSAR
2 年Wooow ya Mariam ????????