TECS Week 2005

SSL / TLS Case Study

John Mitchell

Stanford

Reference: http://www.stanford.edu/class/cs259/
Overview
 Introduction to the SSL / TLS protocol
• Widely deployed, “real-world” security protocol
 Protocol analysis case study
• Start with the RFC describing the protocol
• Create an abstract model and code it up in Mur
• Specify security properties
• Run Mur to check whether security properties are
satisfied
What is SSL / TLS?
 Transport Layer Security protocol, ver 1.0
• De facto standard for Internet security
• “The primary goal of the TLS protocol is to provide
privacy and data integrity between two communicating
applications”
• In practice, used to protect information transmitted
between browsers and Web servers
 Based on Secure Sockets Layers protocol, ver 3.0
• Same protocol design, different algorithms
 Deployed in nearly every web browser
SSL / TLS in the Real World
History of the Protocol
 SSL 1.0
• Internal Netscape design, early 1994?
• Lost in the mists of time
 SSL 2.0
• Published by Netscape, November 1994
• Badly broken
 SSL 3.0
• Designed by Netscape and Paul Kocher, November 1996
 TLS 1.0
• Internet standard based on SSL 3.0, January 1999
• Not interoperable with SSL 3.0
Let’s Get Going…

Informal
Formal Intruder
Protocol
Protocol Model
Description

RFC
(request for
comments) Analysis
Find error Tool
Request for Comments
 Network protocols are usually disseminated in the
form of an RFC
 TLS version 1.0 is described in RFC 2246
 Intended to be a self-contained definition
• Describes the protocol in sufficient detail for readers
who will be implementing it and those who will be
doing protocol analysis (that’s you!)
• Mixture of informal prose and pseudo-code
 Read some RFCs to get a flavor of what protocols
look like when they emerge from the committee
Evolution of the SSL/TLS RFC

80
70
60
50
40
Page count
30
20
10
0
SSL 2.0 SSL 3.0 TLS 1.0
From RFC to MurModel

Informal
Formal Intruder
Protocol
Protocol Model
Description

Mur code
RFC

Analysis
Find error Tool
TLS Basics
 TLS consists of two protocols
 Handshake protocol
• Use public-key cryptography to establish a shared
secret key between the client and the server
 Record protocol
• Use the secret key established in the handshake
protocol to protect communication between the client
and the server
 We will focus on the handshake protocol
TLS Handshake Protocol
 Two parties: client and server
 Negotiate version of the protocol and the set of
cryptographic algorithms to be used
• Interoperability between different implementations of
the protocol
 Authenticate client and server (optional)
• Use digital certificates to learn each other’s public keys
and verify each other’s identity
 Use public keys to establish a shared secret
Handshake Protocol

ClientHello CS C, VerC, SuiteC, NC

ServerHello SC VerS, SuiteS, NS, signCA{ S, KS }

ClientVerify CS signCA{ C, VC }

{ VerC, SecretC } KS
signC { Hash( Master(NC, NS, SecretC) + Pad2 +
Hash(Msgs + C + Master(NC, NS, SecretC) + Pad1)) }
(Change to negotiated cipher)
ServerFinished S  C { Hash( Master(NC, NS, SecretC) + Pad2 +
Hash( Msgs
Master(N + S + Master(NC, NS, SecretC) + Pad1))
C, NS, SecretC)
}

ClientFinished C  S { Hash( Master(NC, NS, SecretC) + Pad2 +

Master(NC, N+
Hash( Msgs S, C
Secret C)
+ Master(N C, NS, SecretC) + Pad1))
}
Handshake Protocol Structure

ClientHello

ServerHello,
[Certificate],
[ServerKeyExchange],
[CertificateRequest],
ServerHelloDone

C [Certificate],
ClientKeyExchange,
S
[CertificateVerify]

switch to negotiated cipher

Finished

switch to negotiated cipher

Finished
Abbreviated Handshake
 The handshake protocol may be executed in an
abbreviated form to resume a previously
established session
• No authentication, key material not exchanged
• Session resumed from an old state
 For complete analysis, have to model both full
and abbreviated handshake protocol
• This is a common situation: many protocols have
several branches, subprotocols for error handling, etc.
Rational Reconstruction

 Begin with simple, intuitive protocol

• Ignore client authentication
• Ignore verification messages at the end of the
handshake protocol
• Model only essential parts of messages (e.g., ignore
padding)
 Execute the model checker and find a bug
 Add a piece of TLS to fix the bug and repeat
• Better understand the design of the protocol
Protocol Step by Step: ClientHello

ClientHello

Client announces (in plaintext):

• Protocol version he is running
• Cryptographic algorithms he supports

C S
ClientHello (RFC)
struct { Highest version of the protocol
supported by the client

ProtocolVersion client_version;
Random random; Session id (if the client wants to
resume an old session)

SessionID session_id; Cryptographic algorithms

supported by the client (e.g.,
CipherSuite cipher_suites; RSA or Diffie-Hellman)

CompressionMethod compression_methods;
} ClientHello
ClientHello (Mur)
ruleset i: ClientId do
ruleset j: ServerId do
rule "Client sends ClientHello to server (new session)"
cli[i].state = M_SLEEP &
cli[i].resumeSession = false
==>
var
outM: Message; -- outgoing message
begin
outM.source := i;
outM.dest := j;
outM.session := 0;
outM.mType := M_CLIENT_HELLO;
outM.version := cli[i].version;
outM.suite := cli[i].suite;
outM.random := freshNonce();
multisetadd (outM, cliNet);
cli[i].state := M_SERVER_HELLO;
end;
end;
end;
ServerHello

C, Versionc, suitec, Nc

ServerHello

Server responds (in plaintext) with:

C
• Highest protocol version both client &
server support S
• Strongest cryptographic suite selected
from those offered by the client
ServerHello (Mur)
ruleset i: ServerId do
choose l: serNet do
rule “Server receives ServerHello (new session)"
ser[i].clients[0].state = M_CLIENT_HELLO &
serNet[l].dest = i &
serNet[l].session = 0
==>
var
inM: Message; -- incoming message
outM: Message; -- outgoing message
begin
inM := serNet[l]; -- receive message
if inM.mType = M_CLIENT_HELLO then
outM.source := i;
outM.dest := inM.source;
outM.session := freshSessionId();
outM.mType := M_SERVER_HELLO;
outM.version := ser[i].version;
outM.suite := ser[i].suite;
outM.random := freshNonce();
multisetadd (outM, serNet);
ser[i].state := M_SERVER_SEND_KEY;
end; end; end;
ServerKeyExchange

C, Versionc, suitec, Nc

Versions, suites, Ns,

ServerKeyExchange

C Server responds with his public-key

certificate containing either his RSA, or
S
his Diffie-Hellman public key
(depending on chosen crypto suite)
“Abstract” Cryptography
 We will use abstract data types to model
cryptographic operations
• Assumes that cryptography is perfect
• No details of the actual cryptographic schemes
• Ignores bit length of keys, random numbers, etc.
 Simple notation for encryption, signatures, hashes
• {M}k is message M encrypted with key k
• sigk(M) is message M digitally signed with key k
• hash(M) for the result of hashing message M with a
cryptographically strong hash function
ClientKeyExchange

C, Versionc, suitec, Nc

Versions, suites, Ns,

sigca(S,Ks),
“ServerHelloDone”

C ClientKeyExchange
S
Client generates some secret key material
and sends it to the server encrypted with
the server’s public key
ClientKeyExchange (RFC)
struct { Let’s model this as {Secret }
c Ks

select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
} exchange_keys
} ClientKeyExchange

struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret
“Core” SSL

C, Versionc, suitec, Nc

Versions, suites, Ns,

sigca(S,Ks),
“ServerHelloDone”

C {Secretc}Ks
S
If the protocol is correct, C and S share
some secret key material secretc at this point

switch to key derived switch to key derived

from secretc from secretc
 Participants as Finite-State Machines

Mur rules define a finite-state machine for each protocol participant

Client state Server state

ClientHello
M_SLEEP M_CLIENT_HELLO

ServerHello

M_SERVER_HELLO M_SEND_KEY

ServerKeyExchange

M_SERVER_KEY M_CLIENT_KEY

M_SEND_KEY M_DONE
ClientKeyExchange
IntruderModel

Informal
Formal Intruder
Protocol
Protocol Model
Description

Mur code Mur code,

RFC similar for
all protocols

Analysis
Find error Tool
Intruder Can Intercept
 Store a message from the network in the data
structure modeling intruder’s “knowledge”
ruleset i: IntruderId do
choose l: cliNet do
rule "Intruder intercepts client's message"
cliNet[l].fromIntruder = false
==>
begin
alias msg: cliNet[l] do -- message from the net
…
alias known: int[i].messages do
if multisetcount(m: known,
msgEqual(known[m], msg)) = 0 then
multisetadd(msg, known);
end;
end;
end;
Intruder Can Decrypt if Knows Key
 If the key is stored in the data structure modeling
intruder’s “knowledge”, then read message
ruleset i: IntruderId do
choose l: cliNet do
rule "Intruder intercepts client's message"
cliNet[l].fromIntruder = false
==>
begin
alias msg: cliNet[l] do -- message from the net
…
if msg.mType = M_CLIENT_KEY_EXCHANGE then
if keyEqual(msg.encKey, int[i].publicKey.key) then
alias sKeys: int[i].secretKeys do
if multisetcount(s: sKeys,
keyEqual(sKeys[s], msg.secretKey)) = 0 then
multisetadd(msg.secretKey, sKeys);
end;
end;
end;
Intruder Can Create New Messages
 Assemble pieces stored in the intruder’s
“knowledge” to form a message of the right format
ruleset i: IntruderId do
ruleset d: ClientId do
ruleset s: ValidSessionId do
choose n: int[i].nonces do
ruleset version: Versions do
rule "Intruder generates fake ServerHello"
cli[d].state = M_SERVER_HELLO
==>
var
outM: Message; -- outgoing message
begin
outM.source := i; outM.dest := d; outM.session := s;
outM.mType := M_SERVER_HELLO;
outM.version := version;
outM.random := int[i].nonces[n];
multisetadd (outM, cliNet);
end; end; end; end;
Intruder Model and Cryptography
 There is no actual cryptography in our model
• Messages are marked as “encrypted” or “signed”, and
the intruder rules respect these markers
 Our assumption that cryptography is perfect is
reflected in the absence of certain intruder rules
• There is no rule for creating a digital signature with a
key that is not known to the intruder
• There is no rule for reading the contents of a message
which is marked as “encrypted” with a certain key,
when this key is not known to the intruder
• There is no rule for reading the contents of a “hashed”
message
Running Mur Analysis

Informal
Formal Intruder
Protocol
Protocol Model
Description

Mur code Mur code,

RFC similar for
all protocols

Analysis
Find error Tool

Specify security
conditions and run Mur
Secrecy
 Intruder should not be able to learn the secret
generated by the client
ruleset i: ClientId do
ruleset j: IntruderId do
rule "Intruder has learned a client's secret"
cli[i].state = M_DONE &
multisetcount(s: int[j].secretKeys,
keyEqual(int[j].secretKeys[s], cli[i].secretKey)) > 0
==>
begin
error "Intruder has learned a client's secret"
end;
end;
end;
Shared Secret Consistency
 After the protocol has finished, client and server
should agree on their shared secret
ruleset i: ServerId do
ruleset s: SessionId do
rule "Server's shared secret is not the same as its client's"
ismember(ser[i].clients[s].client, ClientId) &
ser[i].clients[s].state = M_DONE &
cli[ser[i].clients[s].client].state = M_DONE &
!keyEqual(cli[ser[i].clients[s].client].secretKey,
ser[i].clients[s].secretKey)
==>
begin
error "S's secret is not the same as C's"
end;
end;
end;
Version and Crypto Suite Consistency
 Client and server should be running the highest
version of the protocol they both support
ruleset i: ServerId do
ruleset s: SessionId do
rule "Server has not learned the client's version or suite correctly"
!ismember(ser[i].clients[s].client, IntruderId) &
ser[i].clients[s].state = M_DONE &
cli[ser[i].clients[s].client].state = M_DONE &
(ser[i].clients[s].clientVersion != MaxVersion |
ser[i].clients[s].clientSuite.text != 0)
==>
begin
error "Server has not learned the client's version or suite correctly"
end;
end;
end;
Finite-State Verification

 Mur rules for protocol

participants and the intruder
define a nondeterministic state
transition graph
...  Mur will exhaustively
... enumerate all graph nodes
 Mur will verify whether
specified security conditions
hold in every reachable node
Correctness
 If not, the path to the violating
condition violated node will describe the attack
When Does MurFind a Violation?
 Bad abstraction
• Removed too much detail from the protocol when
constructing the abstract model
• Add the piece that fixes the bug and repeat
• This is part of the rational reconstruction process
 Genuine attack
• Yay! Hooray!
• Attacks found by formal analysis are usually quite
strong: independent of specific cryptographic
schemes, OS implementation, etc.
• Test an implementation of the protocol, if available
“Core” SSL 3.0

C, Versionc=3.0, suitec, Nc

Versions=3.0, suites, Ns,

sigca(S,Ks),
“ServerHelloDone”

C {Secretc}Ks
S
If the protocol is correct, C and S share
some secret key material secretc at this point

switch to key derived switch to key derived

from secretc from secretc
Version Consistency Fails!

C, Versionc=2.0, suitec, Nc

Server is fooled into thinking he Versions=2.0, suites, Ns,

is communicating with a client
who supports only SSL 2.0 sigca(S,Ks),
“ServerHelloDone”

C {Secretc}Ks
S

C and S end up communicating using SSL 2.0

(weaker earlier version of the protocol)
Fixed “Core” SSL

C, Versionc=3.0, suitec, Nc

Versions=3.0, suites, Ns,

sigca(S,Ks),
Prevents version “ServerHelloDone”
rollback attack

C {Versionc,Secretc}Ks
Add rule to check that received version
is equal to version in ClientHello S
If the protocol is correct, C and S share
some secret key material secretc at this point

switch to key derived switch to key derived

from secretc from secretc
A Case of Bad Abstraction
struct { Model this as {Version , Secret }
c c Ks

select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman: ClientDiffieHellmanPublic;
} exchange_keys
} ClientKeyExchange
This piece matters! Need to add it to the model.
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret
Summary of Reconstruction

 A = Basic protocol
 C = A + certificates for public keys
– Authentication for client and server
 E = C + verification (Finished) messages
– Prevention of version and crypto suite attacks
 F = E + nonces
– Prevention of replay attacks
 Z = “Correct” subset of SSL
Anomaly (Protocol F)

… SuiteC …

… SuiteS …
…

C Switch to negotiated cipher S

Finished Finished

data data
Anomaly (Protocol F)

o d ifCy…
… Suite
M
d i
S y
… Suite f…
Mo…
C Switch to negotiated cipher S
X X
Finished Finished

data data
Protocol Resumption

SessionId, VerC= 3.0, NC, ...

VerS= 3.0, NS, ...

C Finished Finished S

data data
Version Rollback Attack

SessionId, VerC= 2.0, NC, ...

VerS= 2.0, NS, ...

C
X
Finished
{ NS } SecretKey
X
Finished
{ NC } SecretKey
S

data data
Basic Pattern for Doing This Yourself

 Read and understand protocol specification

• Typically an RFC or a research paper
• We’ll have a few on the CS259 website: take a look!
 Choose a tool
• Mur works, also many other tools
• Play with Mur now to get some experience
(installing, running simple models, etc.)
 Start with a simple (possibly flawed) model
• Rational reconstruction is a good way to go
 Give careful thought to security conditions
Background Reading on SSL 3.0
Optional, for deeper understanding of SSL / TLS

 D. Wagner and B. Schneier. “Analysis of the SSL 3.0 protocol.”

USENIX Electronic Commerce ’96.
• Nice study of an early proposal for SSL 3.0
 J.C. Mitchell, V. Shmatikov, U. Stern. “Finite-State Analysis of SSL
3.0”. USENIX Security ’98.
• Mur analysis of SSL 3.0 (similar to this lecture)
• Actual Mur model available
 D. Bleichenbacher. “Chosen Ciphertext Attacks against Protocols
Based on RSA Encryption Standard PKCS #1”. CRYPTO ’98.
• Cryptography is not perfect: this paper breaks SSL 3.0 by directly
attacking underlying implementation of RSA