Vietnam National University Ho Chi Minh City, University of Science
Department of Information Technology
Secured Socket Layer
Assoc. Prof. Trần Minh Triết
PhD. Trương Toàn Thịnh
4.0
fit@hcmus
SSL / TLS in daily life?
4.0
fit@hcmus
4.0
fit@hcmus
The evolution of the protocol
SSL 1.0
Internal research in Netscape (~early 1994?)
“Lost in the mists of time”
Main author: Taher Elgamal
SSL 2.0
Netscape published on 11/1994
There are still a few problems
Expired on 2011 (RFC 6176)
SSL 3.0
Published in RFC 6101
Netscape and Paul Kocher designed (11/1996)
Expired on 6/2015 (RFC 7568)
https://datatracker.ietf.org/doc/html/rfc6101
4.0
fit@hcmus
The evolution of the protocol
TLS 1.0 và TLS 1.1
Internet standards based on SSL 3.0 (01/1999)
Incompatible works with SSL 3.0
Expired on ~ 3/2020
TLS 1.1 updated from TLS 1.0
TLS 1.0 published in RFC 2246 and TLS 1.1 in RFC 4346
TLS 1.2
Updated from TLS 1.1
Currently in use
Published in RFC 5246
TLS 1.3
Updated from TLS 1.2
Used by some libraries, browsers and software
Published in RFC 8446
https://datatracker.ietf.org/doc/html/rfc5246
4.0
fit@hcmus
Some limitations in SSL 2.0
Key length is too short
In weakened modes before being released to the public, SSL 2.0 has
narrowed the key length for authentication to 40 bits.
Generate weak MAC
Vulnerable to integrity attack
SSL 2.0 adds bytes (padding) to the MAC in block cipher modes, but
has no control over padding length validation. This makes it possible
for an attacker to delete some bytes at the end of the message.
Ciphersuite rollback attack
An attacker can modify the “ClientHello” message to “trick” the
server into choosing an old version or a weak algorithm
4.0
fit@hcmus
Basics of TLS (TLS Handshake Protocol)
TLS consists of two protocols:
Handshake protocol: use asymmetric encryption to establish a
shared secret key between client and server
Include Client and Server
Negotiate protocol version and the set of cryptographic algorithms to be used
Compatibility & interoperability between different implementations of the general
protocol
Authenticate client and server (optional)
Use an e-certificate to know the partner's public key and confirm each other's identity
Use public key to establish public-secret
Record protocol: Use the secret key established in the handshake
protocol to protect communication between client and server
Structure of Handshake protocol (in general)
4.0
fit@hcmus
Client 1
1
ClientHello Server
ServerHello, 22
[Certificate],33
[ServerKeyExchange],33
[CertificateRequest],44
ServerHelloDone55
6[Certificate],
6
7ClientKeyExchange,
7
8[CertificateVerify]
8
Switch to the negotiated encryption algorithm
99Finished
Switch to the negotiated encryption algorithm
Finished 10
10
4.0
fit@hcmus
ClientHello
Client Server
1
1 ClientHello
Client reports (data NOT encrypted):
• Version of in-use protocol
• Supported encryption algorithms
4.0
fit@hcmus
ClientHello
4 bytes timestamp, 28 bytes random value
session_id:
0 for new connection of existing session
= 0 for new connection of new session
client_version: maximum version value
cipher_suites: Ordered list of supported client algorithms
compression_methods: an ordered list of compression algorithms
that the client supports Highest version of the protocol
supported by the client
struct {
TimeStamp timestamp; Session id (if the client wants
ProtocolVersion client_version; to resume an old session)
Random random;
SessionID session_id; Client-supported
CipherSuite cipher_suites; cryptographic algorithms
CompressionMethod (e.g., RSA or Diffie-Hellman)
compression_methods;
} ClientHello
4.0
fit@hcmus
ServerHello
Client 1
1 C, Versionc, suitec, Nc
Server
ServerHello 22
Server responds (data NOT encrypted):
• Highest version supported by server and client
• The strongest set of cryptographic algorithms
supported by the client
4.0
fit@hcmus
ServerHello
The structure consists of
32 bytes random value
session_id: new value or old value reused
version: min{versionclient supports, versionmaximum server supports}
cipher_suite list: list of selected algorithms (select only one algorithm in
each category)
compression list: Select only from client-supported compression
algorithms
Key exchange method
RSA: need to certify the recipient's public key
Fixed DH: Both parties must have a public-key certificate
Ephemeral DH: Both sides need the key to sign and certify the public-key
Anonymous DH: don’t validate DH key, man-in-the-middle attack possible
Fortezza: rarely used
4.0
fit@hcmus
ServerHello
CipherAlgorithm
RC4, RC2, DES, 3DES, DES40, IDEA, Fortezza
MACAlgorithm
MD5 or SHA-1
CipherType
stream or block
IsExportable: true or false
HashSize
0, 16 or 20 bytes
Key Material: used to generate a write-key
IV Size: size of IV in CBC
4.0
fit@hcmus
ServerKeyExchange
Client 1
1 C, Versionc, suitec, Nc
Server
Versions, suites, Ns, 22
ServerKeyExchange 33
Server sends its certificate of public-key (RSA
or Diffie-Hellman, depending on the selected
set of algorithms)
4.0
fit@hcmus
ServerKeyExchange
No need for RSA and Fixed DH
Needed with Anonymous DH, Ephemeral DH
Use with RSA if the server only has a key for signing. The
server then sends a temporary public key (RSA) to the client
Message ServerKeyExchange:
Signed by server
Signature on hash value of:
ClientHello.random, ServerHello.random
Parameter of Server Key Exchange
4.0
fit@hcmus
ClientKeyExchange
Client 1
1 C, Versionc, suitec, Nc
Server
Versions, suites, Ns, 22
sigca(S,Ks), 33
“ServerHelloDone” 44
4.0
fit@hcmus
ClientKeyExchange
Client 1
1 C, Versionc, suitec, Nc
Server
Versions, suites, Ns, 22
sigca(S,Ks), 33
“ServerHelloDone” 44
5
5ClientKeyExchange
Client generates a secret-key (encrypted with the
server's public-key) and sends it to the server
4.0
fit@hcmus
ClientKeyExchange
Structure
struct {
select (KeyExchangeAlgorithm) {
case rsa: EncryptedPreMasterSecret;
case diffie_hellman:
ClientDiffieHellmanPublic;
RSA or Diffie-Hellman key
} exchange_keys exchange algorithm
} ClientKeyExchange
struct {
ProtocolVersion client_version;
Client-side protocol
opaque random[46];
} PreMasterSecret
version
“Core” SSL
4.0
fit@hcmus
Client 1
1 C, Versionc, suitec, Nc
Server
Versions, suites, Ns, 22
sigca(S,Ks), 33
“ServerHelloDone” 44
5
5 {Secretc}Ks
If the protocol is correct, from now on, C and
S share a common secret key
Switch to using key Switch to using key
deduced from secretc deduced from secretc
4.0
fit@hcmus
States of Client and Server
Client state Server state
ClientHello
M_SLEEP
M_SLEEP M_CLIENT_HELLO
M_CLIENT_HELLO
ServerHello
M_SERVER_HELL
M_SERVER_HELL
M_SEND_KEY
M_SEND_KEY
O
O
ServerKeyExchange
M_SERVER_KE
M_SERVER_KE
M_CLIENT_KEY
M_CLIENT_KEY
Y
Y
M_SEND_KEY
M_SEND_KEY M_DONE
M_DONE
ClientKeyExchange
4.0
fit@hcmus
Main part of SSL 3.0
Client 1
1C, Versionc = 3.0, suitec, Nc
Server
Versions = 3.0, suites, Ns, 22
sigca(S,Ks), 33
“ServerHelloDone” 44
5
5 {Secretc}Ks
If the protocol is correct, from now on,
C and S share the common secret key
Switch to using key Switch to using key
deduced from secretc deduced from secretc
Mis-choose old version!
4.0
fit@hcmus
Client 1
1C, Versionc = 2.0, suitec, Nc
Server
Versions = 2.0, suites, Ns, 22
sigca(S,Ks), 33
“ServerHelloDone” 44
5
5 {Secretc}Ks
The server was "tricked" and decided to
establish communication
between S and C using the old version
4.0
fit@hcmus
Adjust SSL
Client 1
1C, Versionc = 3.0, suitec, Nc
Server
Versions = 3.0, suites, Ns, 22
sigca(S,Ks), 33
“ServerHelloDone” 44
5
5{Versionc,Secretc}Ks
If the protocol is correct, from now on,
C and S share the common secret key
Prevent attack
Added version check
with old version
matches the information in ClientHello
Switch to using key Switch to using key
deduced from secretc deduced from secretc
4.0
fit@hcmus
Summary
A = basic protocol
C = A + certificate of public key
Authentication for client and server
E = C + confirmation message (Finished)
Prevent attacks from “tricking” the server to choose the old version
or weak algorithms
F = E + nonse
Prevent replay attack
4.0
fit@hcmus
Anomaly detection with Finished
n ge
Client a C…
… Suite
Ch
Server
n ge
ha …
…CSuite S
Switch to sharing algorithms
X X
Finished Finished
data data
4.0
fit@hcmus
Example: Version Rollback Attack
SSL 2.0 Finish message “forgot” with
version information
Client Server
SessionId, VerC= 2.0, NC, ...
VerS= 2.0, NS, ...
X
Finished
{ NS } SecretKey
X
Finished
{ NC } SecretKey
data data
Server Authentication
4.0
fit@hcmus
Need to use certificate X.509 v3 in
case of using RSA, Fixed DH,
Ephemeral DH
Client 1
1 ClientHello
Server
ServerHello 22
Certificate 33
“ServerHelloDone” 44
55ClientKeyExchange
6
6[ChangeCipherSpec]
7
7 Finished
[ChangeCipherSpec] 88
Finished 99
4.0
fit@hcmus
Server & Client Authentication
1
1 ClientHello
ServerHello 22
Client Certificate 33
Server
CertificateRequest 44
“ServerHelloDone” 55
66 Certificate
77 ClientKeyExchange
88 CertificateVerify
9
9[ChangeCipherSpec]
10 Finished
10
[ChangeCipherSpec]11
11
Finished 12
12
