SSL/TLS

9 minute read

UCL Course COMP0133: Distributed Systems and Security LEC-14

Scenario

Two parties, clients and servers, not previously known to one another
Two parties, clients and servers, want to authenticate one another
Two parties, clients and servers, want confidentiality and interity of communications in both directions

Actually,

SSL/TLS is usually used by client to authenticate server (although supports both directions)

since after client authenticates server by SSL/TLS,

communications in both directions are secure,

then, server can authenticate client by asking client to provide username and password

Problem

The authentication only using Public Key Encryption Scheme may cause

Man-in-the-Middle (MITM) Attacks

Process

Emulate server when talking to client (substitute own public key for server’s)
Emulate client when talking to server (substitute own public key for client’s)
Pass through most messages as-is 大部分消息保持原样
Record secret data, or modifies some significant data to cause damage

Challenge: Key Management

Solution

Idea

Use digital signatures to indicate endorsement of binding between some principal and its public key

e.g.,

I sign { ‘\( \text{www.amazon.com} \)’, \( pk_{amazon} \) } \( \implies \)

I state “I attest that the public key of ‘\( \text{www.amazon.com} \)’ is \( pk_{amazon} \) “

Certificate Authorities (CA)

Third Party Organizations

Each CA has its own key pair \( K_{CA}, k_{CA}^{-1} \)

Prerequisites

Every principal trusts CA (although there are some security issues about CAs)
Every principal knows CA’s public key \( K_{CA} \) (e.g., pre-configured into browser)

Process

CA creates certificate \( C_s \) for server \( s \) which may contain

\( \text{info} = \{ \ \text{Domain name of \( s \)}, \ \text{Principal (provides \( s \))}, \ K_s, \ \text{Expiration date of \( C_s \)}, \ \text{CA (provides \( C_s \))} \ \} \)
\( \text{sign} = \{ H(\text{info}) \}_{K_{CA}^{-1}} \)

where \( K_s \) is not encrypted (public key)

Server \( s \) can provide \( C_s \) to client (browser)

Client (browser) who has \( K_{CA} \) can verify \( C_s \) that CA attests that public key of \( s \) is \( K_s \)

Benefits: Offline

CAs need not be reachable on the Internet by clients or servers when clients want to authenticate servers

The possible reason is that servers will get their certificates from CA before setting up services

SSL 3.0 Handshake Overview

1 - Client sends to Server with ClientHello contains

client_version

The version of SSL that client is using: server can choose to sync or refuse (avoiding Downgrade Attaks)
client_random

Pseudorandom string of bits generated by client in plaintext
client_cipher_list

The list of ciphers or cipher suites that client implementent supports: server can choose

2 - Server replies to Client with ServerHello contains

server_version

The version of SSL that server is using
server_random

Pseudorandom string of bits generated by server in plaintext
server_cipher_list

The list of ciphers or cipher suites that server implementent supports

3 - Server sends to Client with ServerCertificate contains

server_certificate_list

The list of all certificates of server since client may trust different or various CAs

These certificates contain the public key \( K_s \) of server

4 - Client sends to Server with ClientKeyExchange contains

\( \{\textit{pre_master_secret} \}_{K_s} \)

\( \textit{pre_master_secret} \) is a new pseudorandom string of bits generated by client

Client encrypts \( \textit{pre_master_secret} \) using the public key \( K_s \) of server

after client verifies some certificates provided by server to get \( K_s \)

such that \( \textit{pre_master_secret} \) can only be known by the client and the server

5 - Client sends to Server with ChangeCipherSpec contains

client_cipher

The cipher or cipher suite that client chooses for the following communication after handshaking

6 - Client sends to Server with Finished contains

\( \textit{MAC}(\textit{master_secret}, \text{all messages}) \)

\( \textit{master_secret} \) is the key for \( \textit{MAC} \) which includes

\( \textit{pre_master_secret} \), client_random, and server_random

where \( \textit{pre_master_secret} \) should always be known for only the client and the server

\( \text{all messages} \) is the data for \( \textit{MAC} \) which is the concatenation of all messages from both sides

7 - Server replies to Client with ChangeCipherSpec contains

server_cipher

The cipher or cipher suite that server chooses for the following communication after handshaking

8 - Server replies to Client with Finished contains

\( \textit{MAC}(\textit{master_secret}, \text{all messages}) \)

\( \textit{master_secret} \) is the key for \( \textit{MAC} \) which includes

\( \textit{pre_master_secret} \), client_random, and server_random

where \( \textit{pre_master_secret} \) should always be known for only the client and the server

\( \text{all messages} \) is the data for \( \textit{MAC} \) which is the concatenation of all messages from both sides

Why needs \( \textit{MAC}(\textit{master_secret}, \text{all messages}) \) ?

For example, there exist Cipher Suite Rollback Attacks which tamper client_cipher_list or server_cipher_list

which aims to to force client and server syncing into some weaker cipher or cipher suite

\( \textit{MAC} \) can help to check the integrity of all messages sent and received since client and receiver know them

What session keys means ?

The need of Hybrid Encryption in practice

such that client and server can share a symmetric key for their sessions

The \( \textit{pre_master_secret} \) is to generate the \( \textit{master_secret} \)

The \( \textit{master_secret} \) is to \( \textit{MAC} \) all sent and received messages

neither \( \textit{pre_master_secret} \) nor \( \textit{master_secret} \) is the session key

Session Key Establishment

Client and Server independently compute the symmetric session keys

Take

client_random
\( \textit{master_secret} \)
server_random

to generate a long key block by some PRF

Divde the long key block by the corresponding key lengthes to establish

Client MAC Key
Server MAC Key
Client Write Key
Server Write Key
Client IV
Server IV

which make up the symmetric session keys

Use Session Keys to Send Data

Data encrypted by client and server using their own Write Key

Data \( \textit{MAC} \)-ed by client and server using their own MAC Key

Each SSL record (block) includes

a sequence number for that sender (for receiver to reassemble the message in correct order)
a MAC which is \( \textit{MAC}(\textit{Sequence number}, \textit{Data plaintext}, \textit{Data length}) \)

Actually,

in SSL 2.0, \( \textit{Data length} \) is not \( \textit{MAC} \)-ed, which may cause some attacks

Because data should be padded to fit symmetric cipher block length

therefore, length of data (without padding) must be sent to receiver (in data length field)

If adversaries could change the value in data length field, they could truncate plaintext as desired

Lesson: Always \( \textit{MAC} \) all context used to interpret message at receiver

Properties

Confidentiality

Passive eavesdropper cannot decrypt data

since \( \textit{pre_master_secret} \) encrypted with server’s public key \( K_s \), and server’s private key \( K_s^{-1} \) is secret

Authentication

For authentication of server

Trust each data record comes from server that holds private key matching public key in certificate

Fake server cannot impersonate real one using real certificate and public key

since it does not know private key of real server

which leads to decrypting \( \textit{pre_master_secret} \) from client is impossible

WHAT IF

Fake server obtains own certificate for own domain name from valid CA, supplies to client

cannot work since client (broswer) will check the domain name in certificate which differs from real one

For authentication of client

Not without client certificates or client can send username and password over encrypted SSL channel

Integrity

Replay attacks on Key exchange is impossible

since new random nonce (client_random and server_random) generated from each side each side

Replay attacks on data from earlier in the session (e.g., old seq# to new seq#) is impossible

since the sequence number has been \( \textit{MAC} \)-ed

Vulnerabilities

CA Security Problem

It is easy to get fraudulent certificate from CA (just being paid)

It is necessary to consider CA security problem
since the weakest CA the browser trusts by default will be very weak indeed

Foward Secrecy Problem in SSL 3.0

SSL 3.0 whose RSA encryption variant does not provide Forward Secrecy

Definition of Foward Secrecy

The encryption scheme provides foward secrecy if

Adversary records entire communication between client and server (still cannot get information of any keys)
Adversary obtains the private key of the server later due to some reasons
Adversary still cannot decrypt the recorded communicaiton to get data

Attacks

In SSL 3.0, adversary can decrypt \( \textit{pre_master_secret} \) by the obtained private key \( K_s^{-1} \)

such that it can compute \( \textit{master_secret} \) with client_random and server_random to get session keys

POODLE Vulnerability in SSL 3.0

Padding Oracle On Downgraded Legacy Encryption (POODLE)

leads to downgrade attacks which transfers secure version to insecure version by misusing the support for usability

0 RTTs Vulnerability in TLS 1.3

Reduce latency of handshake from 2 RTTs to 1 RTT (client “guess” which cipher suite server will select)
Support resumption of TLS connection for parties that have previously communicated with 0 RTTs

Not immune to replay attacks such that server applications must ensure requests idempotent
Eliminate 消除 RSA handshake because it does not support forward secrecy

Endong Liu