14. Transport Layer Security Protocol

The most widely used security protocol.

History:

SSL 2.0 developed by Netscape in 1994, 3.0 in 1995
Standardized as RFC 2246 in 1999, called TLS 1.0
TLS 1.1 (4346) in 2006, fix issues with non-random IVs, weaknesses from padding
(the below are good to use)
TLS 1.2 (5246) in 2008 allows standard authenticated encryption
TLS 1.3 (8446) in 2018 had major changes and separated key agreement and authentication algorithms

Overview

Three higher-level protocols:

TLS handshake protocol
TLS alert protocol signals events
TLS change cipher spec protocol for changing cryptographic algorithm (not available in TLS 1.3)

TLS record protocol provides basic services to the higher-level protocols. Stack:

|----------------------------------------|
| TLS       | TLS change |  TLS  | HTTP/ |
| Handshake |   cipher   | alert | Other |
|----------------------------------------|
|           TLS record protocol          |
|----------------------------------------|
|                  TCP                   |
|----------------------------------------|
|                  IP                    |
|----------------------------------------|

TLS Record Protocol

TLS offers:

Message confidentiality - message contents cannot be read in transit
Message integrity - receiver can detect modifications made to the message in transit

These services may be provided by a symmetric encryption algorithm (confidentiality) and MAC (authentication/integrity). TLS 1.2 and above offer authenticated encryption modes (CCM, GCM), combining these two services into one.

The handshake protocol establishes the symmetric session keys used by the record protocol.

The record protocol also deals with dividing messages into blocks and re-assembling received blocks and possibly with compressing/decompressing block contents.

Format

                HEADER
|--------------------------------------|
| Content |  Major  |  Minor  | Length |
|  type   | version | version |        |
|--------------------------------------|

          ENCRYPTED CONTENTS
|--------------------------------------|
|              Plaintext               |
|        (possibly compressed)         |
|      (not available in TLS 1.3)      |
|--------------------------------------|
|                 MAC                  |
|  (unless authentication encryption)  |
|--------------------------------------|

Content type can be change-cipher-spec, alert, handshake or application-data.

TLS 1.3 does not allow the cipher suite to be changed to prevent downgrade attacks - a new session must be created.

Major version is 3 for TLS and minor version 1 to 4 for TLS 1.0 to 1.3.

Length of data is in octets.

Operation

Each application-layer message is $2^{14}$ bytes or less
Compression removed in TLS 1.3 after attacks discovered, null by default in TLS 1.2
Authenticated data: data, header and implicit record sequence number
Plaintext: data and MAC (unless using authenticated encryption)
Session keys: established in handshake protocol
- One key for each of MAC and encryption for each direction
- A single key if using authenticated encryption
Specification: encryption/MAC algorithms specified in negotiated cipher suite

MAC algorithm:

SHA-2 allowed in TLS 1.2 and above
MD5 and SHA-1 not supported in TLS 1.3

Encryption algorithm:

Block cipher in CBC or a stream cipher
Most common block cipher is AES
3DES and RC4 not supported in TLS 1.3
For block ciphers, padding is applied after the MAC to get complete blocks

Authenticated encryption algorithm:

Allowed instead of separate encryption and MAC algorithms in TLS 1.2 and above
TLS 1.3 supports only AES with either CCM or GCM modes
Authenticated data in header and implicit record sequence number

TLS Handshake Protocol

For:

Negotiating the TLS version and cryptographic algorithms used
Establishing a shared symmetric session key for use in the record protocol
Authenticating the server and optionally authenticating the client

Many variations supported - many were dropped to in TLS 1.3.

Phases

Phase 1: initiating the logical connection and establishing the capabilities of the partner
Phases 2 and 3: performing the key exchange
- Operation depends on the handshake variant negotiated in phase 1
Phase 4: completing setup

Cipher Suites

Specify the public key algorithms used for key establishment and symmetric algorithms used for authenticated encryption/key computation.

There were over 300 standardized cipher suites, many of which were discarded in TLS 1.3.

TLS 1.3 requires cipher suites to be Authenticated Encryption with Associated Data (AEAD). AEAD means that there is some associated data that must be sent in plain text (not confidential) but should be authenticated - for example, sequence numbers and other header information.

e.g. TLS_ECDHE_ECDSA_WITH_AES_256_CBC_SHA384:

Ephemeral elliptic curve Diffie-Hellman key transfer (new key for each session)
Key exchange parameters signed using ECDSA (and server’s certificate is also signed by CA using ECDSA)
AES with 256 bit key used as block cipher
Cipher block chaining mode of operation
SHA-2 with digest size of 384 used for the HMAC and for key generation/validation
- Hence required even if AEAD algorithm like GCM or CCM used

e.g. TLS_RSA_WITH_3DES_EDE_CBC_SHA:

Mandatory in TLS 1.0/1.1
RSA used for key exchange
3DES in CBC mode for encryption (confidentiality)
SHA-1 used for HMAC (data integrity) and key generation/validation

Handshake algorithms:

DHE-DSS: Diffie-Hellman key Exchange with Digital Signature Standard/Algorithm (TLS 1.2 only)
DHE-RSA: Ephemeral Diffie-Hellman with RSA signatures (TLS 1.2/1.3)
ECDHE-RSA: Elliptic Curve DHE with RSA signatures (TLS 1.2/1.3)
ECDHE-ECDSA: Elliptic Curve DHE with Elliptic Curve Digital Signature Algorithm (TLS 1.2/1.3)

DH-RSA: permanent DH parameters part of the server certificate (signed with RSA), so there is no forwards secrecy.

Record algorithms:

AES-CBC-SHA256: AES in CBC mode, SHA256 HMAC (TLS 1.2)
AES-GCM: AES in GCM mode for authenticated encryption (TLS 1.2/1.3)
CHACHA20-POLY1305: ChaCha stream cipher with Poly1305 MAC (TLS 1.2/1.3)

Forwards Secrecy:

Compromise of a long-term key should not lead to compromise of session keys established prior to the compromise
Diffie-Hellman handshakes offer forwards secrecy, but RSA-based handshakes do not. Hence, TLS 1.3 drops support for static RSA

Handshake

Phase 1: client/server negotiate TLS version, cipher suite and compression, and exchange nonces
Phase 2: server sends certificate and key exchange message (if required by cipher suite)
Phase 3: client sends certificate and key exchange message (if required by cipher suite)
Phase 4: secure communications. Finished messages also includes check value of all previous messages

Client hello (phase 1):

Highest TLS version supported
Cipher suites supported
Client nonce $N_C$

Server hello (phase 1):

Selected TLS version and cipher suite
Server nonce $N_S$

Server key exchange (phase 2):

Server inputs to key exchange

Client key exchange (phase 3):

Client inputs to key exchange

Change cipher suite (phase 4):

Use negotiated cipher suite for record layer

Ephemeral Diffie-Hellman Handshake Variant

Server key exchange; server sends:

Diffie-Hellman generator
Group parameters (e.g. $P$ )
Server’s ephemeral Diffie-Hellman value

The response is signed by the server using their private key. The client must check this.

Client key exchange; client sends their ephemeral Diffie-Hellman value. Signed if the client has their own certificate.

Pre-master secret ( $\text{pms}$ ) is the shared Diffie-Hellman secret that both parties have computed from the key exchange.

Steps:

Client hello: TLS version, supported cipher suites, client nonce $N_C$
Server hello: server certificate, chosen cipher suite, server nonce $N_S$
Server signature: $N_C$ , $N_S$ and server’s DH parameter signed using server private key
Client checks server signature, sends client’s DH parameter
Pre-master secret calculated using DH parameters
Session keys computed with PRF
Client finished message: encrypted with session key
Server finished message: encrypted with session key

RSA Handshake Variant

Client hello: TLS version, supported cipher suites, client nonce $N_C$
Server hello: server certificate, chosen cipher suite, server nonce $N_S$
Client checks server certificate
Pre-master secret key transport: client randomly chooses pre-master secret $\text{pms}$ , encrypted with server’s public key
Session keys computed with PRF
Client finished message: encrypted with session key
Server finished message: encrypted with session key

Other Handshake Variants

Diffie-Hellman: static/fixed Diffie-Hellman with certified keys. If the client does not have a certificate, they use an ephemeral Diffie-Hellman key.

Anonymous Diffie-Hellman: ephemeral Diffie-Hellman, but keys are not signed at all - only protects against passive eavesdropping.

Session Key Generation

Master secret $\text{ms}$ generated using the pre-master secret and a pseudorandom function $\mathrm{PRF}$ :

\text{ms} = \mathrm{PRF}(\text{pms}, \text{\textquotedblleft master secret\textquotedblright}, N_C \| N_S)

The $\text{pms}$ to $\text{ms}$ conversion is required to ensure the $\text{ms}$ is in the right format as $\text{pms}$ may vary depending on the key transfer algorithm.

To generate the key material (the amount depends on cipher suite):

k = \mathrm{PRF}(\text{ms}, \text{\textquotedblleft key expansion\textquotedblright}, N_C \| N_S)

Independent session keys are partitioned from $k$ in each direction; a write key and a read key are used on each side.

Depending on cipher suite, key material may include encryption key, MAC key and IV.

The $\mathrm{PRF}$ is built from a HMAC specified by the TLS standard - SHA-2 in TLS 1.2 and a combination of MD5 and SHA-1 in TLS 1.0/1.1.

e.g. for TLS 1.2:

A(i) = \begin{cases} \text{nonce}, & i = 0 \\ \mathrm{HMAC}(\text{key}, A(i - 1)), & \text{otherwise} \end{cases}

\begin{aligned} \mathrm{PRF}(\text{key}, \text{label}, \text{nonce}) = & \mathrm{HMAC}(\text{key}, A(1) \| \text{label} \| \text{nonce}) \| \\ & \mathrm{HMAC}(\text{key}, A(2) \| \text{label} \| \text{nonce}) \| \\ & \vdots \end{aligned}

TLS Alert Protocol

Alert messages of varying degrees of severity:

Warning alerts
close_notify alerts
Fatal alerts

If alert messages are handled improperly, users may be vulnerable to truncation attacks.

Attacks

Backwards Compatibility

Insecure versions of TLS are depreciated slowly:

SSL 3.0 was depreciated in 2015
End-of-life for TLS 1.0 and 1.1 was in 2020

TLS 1.2 is secure as long as a good cipher suite is used:

RC4 shown to be vulnerable, offered in TLS 1.2

TLS 1.2 supported by 99.5% of websites, TLS 1.3 (released 2018) ~50% as of August 2021. See SSL Pulse for up-to-date statistics.

BEAST (Browser Exploit Against SSL/TLS)

Exploits non-standardized IV use in CBC mode encryption: IVs are chained from previous ciphertexts; attack could recover plaintext byte-by-byte.

Theoretical attack found in 2002 but required the full block to be guessed. In 2011 researchers found a method where they could have all but one byte in the block to be known, requiring only that byte to be guessed.

TLS 1.1 requires random IVs, and most browsers added mitigation strategies by putting only one byte of data in the first block (and padding the rest with random data) and the remaining bytes into the second block, forcing a randomized IV.

CRIME (Compression Ratio Info-leak Made Easy) and BREACH (Browser Reconnaissance and Exfiltration via Adaptive Compression of Hypertext)

Side channel attacks based on compression: different inputs result in different amounts of compression.

CRIME is based on compression in the TLS level, BREACH on compression at the HTTP level.

CRIME: attacker has ability to control part of request. If request gets smaller, the attacker-controlled content is probably matches part of source content (e.g. cookies).

TLS 1.3 does not allow compression. Disabling compression at a HTTP level results in a large performance hit.

POODLE (Padding Oracle On Downgraded Legacy Encryption)

A padding oracle enables an attacker to know if a message in a ciphertext was correctly padded.

Encryption in CBC mode can provide a padding oracle due to its error propagation properties: servers (after decrypt all blocks and validating the padding) may sometimes return an ‘invalid padding’ error.

Main mitigation is to have a uniform error response so that attacker cannot distinguish between padding and MAC errors.

Theoretical in 2002, practical in 2014 with POODLE, which forced a downgrade into SSL 3.0.

Heartbleed

Implementation error in OpenSSL found in 2014: improper input validation due to missing bounds check in heartbeat messages allowed memory leakage.

Heartbeats allow clients/servers to send a few bytes of data that the partner should echo back: OpenSSL did not validate that the length field matched actual length of the heartbeat, so the allocated memory could include freed data that contained sensitive data (e.g usernames/passwords, private keys).

Other Attacks

Man-In-The-Middle (MITM)
- Found in 2015, Lenovo was bundling Superfish spyware in their computers, which including a self-signed root certificate that used the same private key across devices
STARTTLS command injection
Sweet32
Triple Handshake
RC4 attacks
Lucky Thirteen
Renegotiation

TLS 1.3

Drafted 2014, adopted as RFC 8446 in August 2018.

TLS 1.3 did a large spring cleaning, removing:

Static RSA, Diffie-Hellman key exchange
Cipher-suite renegotiation (change-cipher-spec)
SSL negotiation
DSA
Data compression
Non-AEAD (authenticated encryption with associated data) cipher suites
- AEAD is more efficient, secure, require less keys and are easier to implement compared to separate encryption and MACs algorithms.
MD5, SHA-335 hash functions
Change Cipher Spec protocol

TLS 1.3 also added:

Separation of key agreement and authentication algorithms from cipher suites
Mandating perfect secrecy: ephemeral keys during EC Diffie-Hellman key agreement
Encrypting content type
0-RTT mode (using pre-shared key)
Post-handshake client authentication
ChaCha20 stream cipher with Poly1305 MAC

Handshake:

Client hello:
- TLS version, supported cipher suites
- Key share:
  - Guesses selected cipher suite (s), sends key share (s)
  - If guess was wrong, server sends retry hello request
Server hello:
- Selected TLS version, cipher suite
- Key share
  - Everything after this in the handshake can be encrypted
- Server certificate (and optionally the certificates up the chain)
- Hash of handshake messages signed with server certificate
Client handshake finished
- Hash of handshake messages signed with session key

0-RTT Overview

Even faster handshakes using pre-shared key (resumption master secret) obtained for the purpose of 0-RTT after a previous (and recent) connection.

TLS 1.3 1-RTT (with ephemeral Diffie-Hellman key exchange):

Client hello
Server hello plus:
- Diffie-Hellman key share
- Encrypted extensions
- Certificate
- Key to verify certificate
Client response:
- Diffie-Hellman key share
- Certificate
- Verification data

TLS 1.2 1-RTT session resumption:

Client hello plus:
- Diffie-Hellman key share
- Pre-shared key (from previous connection after handshake)
Server hello
- Diffie-Hellman key share
- Encrypted extensions

TLS 1.3 0-RTT:

Client hello:
- Key share
- Application data encrypted with resumption key negotiated previously
- End of early data alert
Server hello:
- Key share
- Application data encrypted with session key
Client handshake finished:
- And more application data
Further messages encrypted with new session key

Limitations:

Attackers can capture encrypted 0-RTT and re-send them to the server: if the server is misconfigured, it may accept the replayed requests