Transport Layer Security (TLS)

Transport Layer Security (TLS)

Jes´us Arias Fisteus

Web Applications (2022/23)

HTTP Secure (HTTPS)

Hypertext Transfer Protocol Secure (HTTPS) is an adaptation of HTTP for secure communication, where messages are transmitted on top of the Transport Layer

Security (TLS) protocol.

(The default TCP port for HTTPS is 443)

Transport Layer Security (TLS)

Transport Layer Security (TLS) provides a secure channel between two communicating peers.

I

The connection is private, as data is encrypted with symmetric cryptography.

I

The identity of the server can be verified using the public-key infrastructure.

I

Data integrity can be verified, i.e. data loss or alteration

during transmission can be detected.

Transport Layer Security (TLS)

I

TLS is the de facto standard to secure communications between applications.

I

Its origin is SSL (Secure Sockets Layer), first developed at Netscape in the 90’s.

I

It is an IETF standard.

I

Its current version is TLS 1.3 (RFC 8446).

Components of the TLS protocol

I

Handshake protocol:

I A TLS session between client and server is established.

I

Record protocol:

I Data is securely transmitted from client to server and from server to client within the context of an already established TLS session.

Steps of the handshake protocol

1.

Negotiation:

I Client and server agree on a TLS protocol version and the cryptographic algorithms and parameters to use.

2.

Key exchange:

I Client and server derive the symmetric keys to be used for encrypting transmitted data.

3.

Authentication:

I The client authenticates the server (and, optionally, the server can also authenticate the client).

Handshake: negotiation

I

The client specifies the algorithms it supports by sending the ClientHello message, which includes:

I One or more key exchange algorithms.

I Two or more digital signature algorithms.

I One or more hash functions to be used for HKDF.

I One or more authenticated encryption algorithms.

I

The server chooses the algorithms to be used from the list of

algorithms the client specified, and communicates them to it

by sending a ServerHello message.

Handshake: key exchange

1.

Client and server communicate each other their public keys:

I The public keys they use should be ephemeral in order to provide forward secrecy.

I In TLS 1.3 they can be communicated in the ClientHello and ServerHello messages in order to optimize the process.

Handshake: key exchange

2.

The symmetric keys to be used for the session are derived by using the HMAC-based Extract-and-Expand Key Derivation Function (HKDF) algorithm and the selected hash function:

I A pair of random values chosen by the client in the ClientHello message and the server in the ServerHello message randomize the derived keys.

I In TLS 1.3 different keys are derived for different parts of the communication.

(In TLS 1.3 further handshake communication after keys have

been derived is encrypted.)

Handshake: authentication

I

Servers must be authenticated:

I Websites need acertificate(a long term website’s public key signed by a certification authority).

I The website’s certificate can be validated through thepublic key infrastructure.

I

Optionally, clients can be authenticated too, but normally just

servers are subject to authentication in the Web.

The public key infrastructure

I

Web browsers trust a set of root certificate authorities.

I

Root certificate authorities may sign certificates for intermediate certificate authorities.

I

Root and intermediate certificate authorities can sign certificates for websites.

I

Certificates are validated by verifying their signatures against

the signing certificate authority’s own certificate, following the

verification process through the certificate chain up to a root

certificate authority.

Certificates

I

X.509 certificates are normally used.

I

Website certificates contain, among others:

I The website’s public key.

I The domain name(s) to which the certificate applies.

I Initial and final date and time of the certificate’s validity period.

I The signature of the certificate’s data by the certification authority issuing it.

Handshake: authentication

1.

The server sends:

I Its own certificate.

I The certificate chain (the chain of certificates of the certificate authorities that sign it, up to a root certificate authority).

I A signature of all the previous handshake messages done with the private key associated to the public key in the server’s certificate.

2.

The client verifies the signature of the handshake messages

and the chain of certificates.

Handshake: session resumption

I

It’s normal for clients to connect several times to the same websites, but TLS handshakes are costly.

I

TLS allows previous sessions to be resumed by reusing

previously exchanged keys through a pre-session keys (PSK) handshake:

I Servers may produce a session ticket that the client can use in the future to resume a closed session.

I Clients may send a ClientHello message with the session ticket in order to ask the server to resume a previous session, thus skipping negotiation, key exchange and authentication.

Application data transmission (record protocol)

I

Encryption of application data:

I Data is encrypted with a symmetric key.

I

Protection against message tampering:

I Messages are authenticated and the integrity of their contents is verified through the use of authenticated encryption.

I

Protection against replayed or reordered messages:

I Data is split into records, which are assigned a sequence number. Peers verify the sequence number of the records they receive.

References

I

The Transport Layer Security (TLS) Protocol Version 1.3.

IETF RFC 8446. August 2018.

I

David Wong, Real-World Cryptography, Manning Publications (2021):

I Chapter 9 (Secure Transport).

I Online access at O’Reilly through UC3M Library