Skip to main content

SSL/TLS

SSL1 (Secure Socket Layer) is a communication protocol providing confidentiality, authenticity and integrity in network communications.

SSL 3.0 was deprecated by RFC7568 and superseded by TLS2 (Transport Layer Security), 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 session3. The client also sends a nonce RCR_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 RSR_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.

  1. ClientKeyExchange: The client validates the server certificate and begins the key exchange procedure, which includes generating a seed, the premaster secret KPreK_{Pre}: If RSA is used for key exchange, KPreK_{Pre} is generated by the client, encrypted with the public key of the server, then sent to the server ([📖Eck23, p. 798]). If Diffie-Hellmann is used, KPreK_{Pre} is generated by both parties independently, resulting in the same value for KPreK_{Pre}. The premaster secret is used in the next step for deriving the master secret.
  2. ChangeCipherSpec/Finished: Both client and server now compute the master secret from KPreK_{Pre}, RCR_C and RSR_S, using a pseudorandom function (PRF) (RFC5246, Section 8.1):
KMaster=PRF(KPre,"master secret",RC+RS)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 [FS12, 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 ([📖FS12, 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 compressed4, a MAC is calculated using a key derived from the master secret. Finally, the result is encrypted using a symmetric cryptographic algorithm.

Footnotes​

  1. RFC6101 ↩

  2. RFC8446 ↩

  3. 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) ↩

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