SSL/TLS (Network Security)

SSL (Secure Socket Layer, [📖RFC6101]) is a communication protocol providing confidentiality, authenticity and integrity in network communications.

SSL 3.0 was deprecated by [📖RFC7568] and superseded by TLS (Transport Layer Security, [📖RFC8446], which is based on SSL 3.0 but introduces breaking changes, such as the mechanism for deriving the premaster secret and the use of nonces.

To ensure backward compatibility, many clients (such as web browsers) often support both protocols. Thus, the umbrella term SSL/TLS is used whenever it's unclear in advance which protocol will be negotiated ([📖TFW21, p. 841]).

While classified as application layer protocols, they are often described as intermediate layers between the application and transport layer, since they encapsulate cryptographic services, exposed by standardized interfaces for data-input and -output (see Figure 1).

^{Figure 1 SSL / TLS as a sublayer between transport and application layer in the 5-layer internet model. (Source: adapted from [KR20, Figure 8.24, 645])}

SSL/TLS Handshake

To establish secure communications, Client and Server initiate the protocol using a handshake , where certificates, keys and other various parameters for the session are defined.

The TLS-handshake can be divided roughly into the following steps, whereas the SSL 3.0 handshake follows a similar structure ([📖TFW21, p. 839 f.], [📖Eck23, p. 796 ff.]). For TLS 1.3, several changes have been made to the protocol, notably

"Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy." [📖RFC8446, Section 1.2 ]

Therefore, the description of the handshake protocol - which is illustrated in Figure 2 - follows TLS 1.2 ([📖RFC5246])

1. ClientHello: Communication begins with the client by sending a list of cipher suites ([📖RFC5246, A.5. The Cipher Suite ]), containing preferences regarding the encryption- and compression-algorithms to use for the following session¹. The client also sends a nonce $R_C$, used for deriving the master secret later on.
2. ServerHello: The server selects from this list based on its own implementation. The data is sent back to the client including the server-nonce $R_S$.
3. Following up on the previous message, the server then sends its certificate data in form of a x.509-certificate (unless otherwise negotiated) containing its public key. Various other messages from the server may follow, such as certificate chains if the server's certificate is not directly signed by a well-known CA. The root CA must be in the trust store of the client for the secure connection to be established:

[...] the self-signed certificate that specifies the root certificate authority MAY be omitted from the chain, under the assumption that the remote end must already possess it in order to validate it in any case.`` [📖RFC5246, Section 7.4.2 ]
Additionally, the server requests the client's certificate ([📖TFW21]). The server sends a ServerHelloDone once finished with this.

4. ClientKeyExchange: The client validates the server certificate and begins the key exchange procedure, which includes generating a seed, the premaster secret $K_{Pre}$: If RSA is used for key exchange, $K_{Pre}$ is generated by the client, encrypted with the public key of the server, then sent to the server ([📖Eck23, p. 798]). If Diffie-Hellman is used, $K_{Pre}$ is generated by both parties independently, resulting in the same value for $K_{Pre}$. The premaster secret is used in the next step for deriving the master secret.
5. ChangeCipherSpec/Finished: Both client and server now compute the master secret from $K_{Pre}$, $R_C$ and $R_S$, using a pseudorandom function (PRF) ([📖RFC5246, Section 8.1 ]):

$$K_{Master} = PRF(K_{Pre}, "master\ secret", R_C + R_S)$$

Once the client has computed the master secret, it signals the start of encrypted communication via a ChangeCipherSpec message, followed by a Finished message to authenticate the handshake: This message contains a hash over all preceding handshake messages and is the first protected message with the negotiated algorithms, keys and secrets applied - it is therefore crucial that the receiving peer validates this message (RFC5246, Section 7.4.9). The server repeats the procedure. After this, payload can be sent using the Record Protocol, where messages are authenticated and encrypted using the keys derived from the master secret.

^{Figure 2 Sequence diagram of a TLS 1.2 Handshake. (Source: adapted from [SF12, Figure 18-30, 881])}

Figure 2 also illustrates how TLS 1.2 supports session resumption - based on session ids shared by both client and the server, most of the key exchange and verification steps can be skipped if the communicating parties have previously established trust.

Also, if the server requests client certification, an additional CertificateVerify-message containing a signature over all preceding handshake messages is sent by the client, to prove it's in possession of the private key corresponding to a previously sent certificate, if one was provided ([📖SF12, p. 880 f.]).

Record Protocol

Data between the communicating parties is exchanged via the Record Protocol. Its responsibilities are fragmentation of the application data into chunks not larger than 16KB. The fragments are optionally compressed², a MAC is calculated using a key derived from the master secret. Finally, the result is encrypted using a symmetric cryptographic algorithm.

Forward Secrecy

The ServerKeyExchange-message in TLS 1.2 is used to include Diffie-Hellman parameters for a Diffie-Hellman key exchange with the client: The server sends this message if both client and server negotiated a non RSA-based cipher suite for the session, in which case the client would encrypt $K_{Pre}$ with the public key of the server. Using the ServerKeyExchange-message with ephemeral Diffie-Hellman parameters establishes Forward Secrecy in TLS 1.2, as the message would contain the parameters signed with a private key, e.g. using DSS (Digital Signature Standard)³ or RSA, which the client verifies.
The client sends its DH-public-key in the ClientKeyExchange message in return.
A compromised private key of the server would mean that previous session data cannot be decrypted, as the private key was only used for signing, not for encryption.

TLS 1.3

As a major difference between TLS 1.2 and TLS 1.3, [📖RFC8446] specifies that

"- Static RSA and Diffie-Hellman cipher suites have been removed; all public-key based key exchange mechanisms now provide forward secrecy.
- All handshake messages after the ServerHello are now encrypted. The newly introduced EncryptedExtensions message allows various extensions previously sent in the clear in the ServerHello to also enjoy confidentiality protection."

This establishes ForwardSecrecy by default, as the server and the client negotiate ephemeral Diffie-Hellman key shares in the ClientHello/ServerHello-messages using the key_share-extension (or the pre_shared_key-extension, if applicable). For TLS 1.3, dedicated key exchange messages such as ClientKeyExchange and ServerKeyExchange are removed.

---

Footnotes

1. so called Authenticated Encryption with Associated Data (AEAD) for establishing confidentiality, and HMAC-based Extract-and-Expand Key Derivation Function (HKDF) for establishing integrity (since TLS 1.3) ↩

2. Compression can expose security risks; see CVE-2012-4929 (retrieved 11.05.2025) ↩

3. https://csrc.nist.gov/pubs/fips/186-5/final (retrieved 16.05.2025) ↩

---

References

1. [RFC6101]: Freier, Alan O. and Karlton, Philip and Kocher, Paul C.: The Secure Sockets Layer (SSL) Protocol Version 3.0 (2011), RFC Editor, 10.17487/RFC6101 [BibTeX]
2. [RFC7568]: Barnes, Richard and Thomson, Martin and Pironti, Alfredo and Langley, Adam: Deprecating Secure Sockets Layer Version 3.0 (2015), RFC Editor, 10.17487/RFC7568 [BibTeX]
3. [RFC8446]: Rescorla, Eric: The Transport Layer Security (TLS) Protocol Version 1.3 (2018), RFC Editor, 10.17487/RFC8446 [BibTeX]
4. [TFW21]: Tanenbaum, Andrew and Wetherall, David and Feamster, Nick: Computer Networks Global Edition (2021), Pearson Deutschland [BibTeX]
5. [Eck23]: Eckert, Claudia: IT-sicherheit: Konzepte -- Verfahren -- Protokolle (2023), De Gruyter Oldenbourg, 10.1515/9783110985115 [BibTeX]
6. [RFC5246]: Rescorla, Eric and Dierks, Tim: The Transport Layer Security (TLS) Protocol Version 1.2 (2008), RFC Editor, 10.17487/RFC5246 [BibTeX]
7. [SF12]: Fall, K.R. and Stevens, W.R.: TCP/IP Illustrated (2012), Addison-Wesley [BibTeX]