print · source · login   

Transport Layer Security

Related publications: [RP15]

Description

TLS is used to secure, for example, the connection between a webserver and browser (i.e. using HTTPS).

The TLS protocol was originally known as SSL (Secure Socket Layer), which was developed at Netscape. SSL 1.0 was never released and version 2.0 contained numerous security flaws [RFC6176]. This lead to the development of SSL 3.0, on which all later versions are based. After SSL 3.0, the name was changed to TLS and currently three versions are published: 1.0, 1.1 and 1.2 [RFC2246][RFC4346][RFC5246]. The specifications for these versions are published in RFCs issued by the Internet Engineering Task Force (IETF).

To establish a secure connection, different subprotocols are used within TLS:

  • The Handshake protocol is used to establish session keys and parameters and to optionally authenticate the server and/or client.
  • The ChangeCipherSpec protocol consisting of only one message is used to indicate the start of the use of established session keys.
  • To indicate errors or notifications, the Alert protocol is used to send the level of the alert (either warning or fatal) and a one byte description.
Set-up
Fig. 1: A regular TLS session. An encrypted message m is denoted as {m}. If message m is optional, this is indicated by [m].

In Fig. 1 a normal flow for a TLS session is given. In the ClientHello message, the client indicates the desired TLS version, supported cipher suites and optional extensions. A cipher suite is a combination of algorithms used for the key exchange, encryption, and MAC computation. During the key exchange a premaster secret is established. This premaster secret is used in combination with random values from both the client and server to derive the master secret. This master secret is then used to derive the actual keys that are used for encryption and MAC computation. Different keys are used for messages from the client to the server and for messages in the opposite direction. Optionally, the key exchange can be followed by client verification where the client proves it knows the private key corresponding to the public key in the certificate it presents to the server. After the key exchange and optional client verification, a ChangeCipherSpec message is used to indicate that from that point on the agreed keys will be used to encrypt all messages and add a MAC to them. The Finished message is finally used to conclude the handshake phase. It contains a keyed hash, computed using the master secret, of all previously exchanged handshake messages. Since it is sent after the ChangeCipherSpec message it is the first message that is encrypted and MACed. After the handshake phase, application data can be exchanged over the established secure channel.