Private Network Communication II
(Security Analysis of SSL3.0 and IPsec)
IS511
SSL/TLS Performance
 SSL handshake performance
 For each connection, you need to exchange the key
 Matters the most for small objects
 Who is the performance bottleneck?
 Client generates a random key, encrypts it with public
key of the server
 Server decrypts the pre_master_secret
 Both parties run PRNG twice
 Server has to deal with lots of clients
 Performance bottleneck
 Mitigation: connection resumption, persistent connection
 Tcpcrypt[USENX Security’10]: client decrypts the key 2
SSL/TLS Performance
 SSL data transfer performance
 Matters in large data transfer
 Videos on https?
 Symmetric key crypto is the bottleneck
 AES-NI enables fast AES encryption/decryption
 SSL/TLS performance summary
 For small files, public key crypto performance matters
 For large files, symmetric key crypto performance
matters
 See for yourself in doing homework
3
Secure Key Size in SSL/TLS
 1024-bit public key crypto is considered insecure
 768-bit RSA is broken in 2010
 1024-bit is no longer considered secure
 As of 2013, all US government equipments should use
2048bit or larger public key size for SSL
 Performance implication
 As RSA key size doubles, the computation needs
increases by a factor of 8 (O(n^3))
 In fact, you can see 6x to 8x performance degradation
 SSLShader[NSDI’2011]: use GPU for cheap computation
4
Perfect Forward Secrecy (PFS)
 Definition: a session key will be not compromised
even if a private key is revealed in the future

E.g., revealing a private key does not allow getting the
plaintext of the encrypted data in the past
 Diffie-Hellman provides perfect forward secrecy
 Ephemeral public key/private key
 Security-sensitive sites provide PFS
 RSA does not provide perfect forward secrecy
 Yet, many sites use RSA due to performance concern, etc.
5
Security Level of a System
 How strong is the weakest point of your system?
6
Two Security Analysis Papers
 “Analysis of the SSL 3.0 protocol”
 David Wagner and Bruce Schneier
 Security of a new SSL protocol (circa 1996)
 “Cryptography in Theory and Practice: The case of
Encryption in IPsec”


Kenneth Paterson and Arnold Yau
Vulnerabilities in unauthenticated IPsec
 Focuses on the gap between theory and practice of IPsec
7
Analysis of SSL 3.0 Protocol
 Cryptographic strength of SSL 3.0
 Problems with SSL 2.0
 Weak 40-bit authentication keys
 Weak MAC construction
 Padding bytes into the MAC in block cipher modes not
unauthenticated
 “Ciphersuite rollback attack”: an active attacker edits the list of
ciphersuite preferences in the hello messages -> force both parties
to choose a weak ciphersuite
 SSL 3.0 fix all of them
 So is it really safe now?
8
How Secure is Record Layer?
 Confidentiality: eavesdropping
 Key-management is handled well
 Hashing random per-connection salts and a strong shared secret
 Confidentiality: traffic analysis
 Recover confidential info by examining unencrypted
packet fields
 Vulnerability: can infer the URL length by ciphertext length
 Found by Bennett Yee
 Stream cipher more vulnerable (block cipher – random padding)
 Solution? Support random padding for all cipher modes
9
How Secure is Record Layer?
 Confidentiality: active attack
 Cut-and-paste attack (from IPsec)
 Cut sensitive information and paste it at insensitive part
 In the hope that insensitive part is decrypted and made public

Short-block attack (from IPsec)
 1-byte encrypted packet in a randomly-padded block (DES-CBC)
 Given 28 plaintext/ciphertext pairs, can figure out the one byte
 Correct guessing: TCP checksum and ACK
 SSL 3.0 defends against these attacks
 Cut-and-paste-attack
 Independent unidirectional session keys
 Authentication of each record

Short-block attack
 Typically web servers do not encrypt short blocks
 Telnet on SSL is potentially vulnerable
10
Message Authentication
 SSL 2.0 used inseure MAC
 SSL 3.0 fixes the problem
 SSL 3.0 adopts HMAC
 HMAC is known to be very secure against cryptanalysis
attacks
 Replay attacks?
 Prevents them by MAC’ed sequence numbers
 Protects against delayed, re-ordered, deleted data
11
Drop ChangeCipherSpec Message
 Assume the negotiated ciphersuite includes only
“message authentication and no encryption”
 Finished message does not include authentication
of ChangeChiperSpec

Malicious man-in-the-middle entity can drop it
{m}k: m + HMAC(k, m)
… Normal handshake …
C->S: {ChangeCipherSpec}
C->S: {Finished} {a}k
S->C: {ChangeCipherSpec}
S->C: {Finished} {a}k
C->S: {m}k
… Normal handshake …
C->M: {ChangeCipherSpec}
C->M: {Finished} {a}k
M->S: {Finished} a
S->M: {ChangeCipherSpec}
S->M: {Finished} {a}k
S->C: {Finished} a
C->M: {m}k
M->S: m
12
Drop ChangeCipherSpec Message
 What if the chosen ciphersuite includes encryption?
 Attacks probably fail
 But if the encryption is weak (40bit key)?
 Simplest Fix
 Accept Finish only after accepting ChangeCipherSpec
 Maybe it is too obvious?
 No: Netscape SSLRef3.0b1 accepts Finish without
ChangeCipherSpec
13
Version Rollback Attack
 Adversary modifies SSL 3.0 hello to SSL 2.0 hello
 Paul Kocher’s workaround to detect the attack
Use RSA PKCS non-random padding bytes
RSA is the only key-exchange algorithm in SSL 2.0
14
Key-exchange Algorithm Rollback
 Basic idea: make client and server use different
key exchange algorithms (DH, RSA)

Reveal pre_master_secret by having client encrypt it
with wrong parameters
[client hello]
C->M: SSL_RSA…
M->S: SSL_DHE_RSA…
// make server choose DHE
[server hello]
S->M: SSL_DHE_RSA…
M->C: SSL_RSA…
// make client choose RSA
[server key exchange]
S->M: {p,g,y}Ks
M->C: {p,g,y}Ks
// server provide DHE params
[client key exchange]
C->M: kg mod p // client use RSA to encrypt k with wrong params
15
M->S: gx mod p
Key-exchange Algorithm Rollback
 Basic idea: make client and server use different
key exchange algorithms (DH, RSA)

Reveal pre_master_secret by having client encrypt it
with wrong parameters
[client hello]
C->M: SSL_RSA…
M->S: SSL_DHE_RSA…
// make server choose DHE
[server hello]
S->M: SSL_DHE_RSA…
M->C: SSL_RSA…
// make client choose RSA
[server key exchange]
S->M: {p,g,y}Ks
M->C: {p,g,y}Ks
// server provide DHE params
[client key exchange]
C->M: kg mod p // client use RSA to encrypt k with wrong params
16
M->S: gx mod p
Key-exchange Algorithm Rollback
 kg mod p: k is pre_master_secret, but g and p are
DHE parameters not RSA’s



gx


g-th root of this value would produce ‘k’
M can figure out pre_master_secret
mod p is given to server
Server would think (gxy mod p) is pre_master_secret
So, complete man-in-the-middle attack is launched
 This is caused by possible implementation bugs
 Careful implementations check the length of params
 Hm, you may want to say Finish message?
 Finish is supposed to provide MAC?
17
Cryptography in Theory and Practice:
The case of Encryption in IPsec
 Unauthenticated encryption is prevalent
 Why? One reason is a performance concern
 Unauthenticated encryption is vulnerable to attacks
 Widely-known in theory community
 But in practice, it’s often neglected
 Paper based on Steve Bellovin’s paper
 Previous SSL paper cites the same paper a lot
 IPsec vulnerabilities
 This version builds on Steve Bellovin’s observation
 More practical/efficient attack
18
Attacks on Unauthenticated IPsec Protocols
 Destination address rewriting
 Change the destination address to attacker’s
 All packets are now re-routed to attacker’s address
 IP options processing
 Add garbage values in IP option fields
 Have the security gateway generate an ICMP packet
 Protocol field manipulation
 Modify the protocol field to one that’s not supported
 Have the end node generate an ICMP packet
19
Cipher Block Chaining (CBC) Mode
 CBC generates its own random numbers
 Have encryption of current block depend on result of previous block
 Encryption: Ci = KS(Pi  Ci-1)
 Decryption: Pi = KS(Ci)  Ci-1
 How do we encrypt the first block?
 Initialization vector (IV): random block = C0
 IV does not have to be secret (sent in plaintext)
 Change IV for each message (or session)
 Guarantees that even if the same message is sent repeatedly, the
ciphertext will be completely different each time
20
Bit Flipping Attack on CBC Mode
 Given ciphertext, C0, C1, …, Cq, flip a specific bit j
in Ci-1 will flip a bit in plaintext Pi



Note Pi = Ks(Ci)  Ci-1
So, flipping bit j in Ci-1 will flip the bit in Pi
Also, flipping bit j in Ci-1 will produce wrong Pi-1
 All attacks in the paper exploit this property
21
Destination Address Rewriting
 How to change the dest. address of IPsec packets?
 So that the packets are delivered to attacker?
 Assume the attacker can modify IPsec packets
 Assume 64bit (8byte) block size
 IPv4 header: a series of 8-byte blocks (3 blocks)
 Assume the attacker knows the destination address
IPsec
Attacker
IPsec
22
Destination Address Rewriting
32 bits
type of
ver head.
len service
length
fragment
16-bit identifier flgs
offset
time to upper
header
layer
live
checksum
32 bit source IP address
32 bit destination IP address
Options (if any)
 How to change dest IP?
P1(C1)
 Dest IP = DestAddr
 Attacker IP = AttrAddr
 XOR the first four bytes of
P2(C2)
C2 with M= (DestAddr 
AttrAddr)
 Implications?
P3(C3)
data
(variable length,
typically a TCP
or UDP segment)
23
Implications on Modification of C2
 Modifying C2 will produce random P2:
 P2 has TTL, protocol, checksum, source IP address
 Conditions for successful attacks
 Modified TTL should be large enough
 Modified checksum should be correct
 Attack success probability?
 Roughly one out of 217 attempts
 Once successful, the plaintext packet will be
delivered to attacker
24
What about Subsequent IPsec Packets?
 Do we have to repeat 217 times for EACH packet?
 No: reuse previous C2’
 Reuse C0, C1, C2’, C3 of the IPsec packet in the previous
successful attack
 The last three blocks should be intact (Cq-2, Cq-1, Cq)
 One successful attack will reveal all subsequent
packets in plaintext
25
More General Cases
 What if the attacker does not the destination IP?
 Assume the attacker knows the destination IP prefix
 E.g., Class C: 143.248.1.1/24
 Brute force attack – iterate every IP address
 On average, it will be successful ater 27 IP addresses
 128bit block instead of 64bit block?
 The first 32 bits of P2 is destination IP field
 Should modify the first 32 bits of C1
 Implications?
26
Attack on IP Option Processing
 Attack scenario (roughly)
 Modify the header length > 5
 Induce random numbers right after 20-th IP header byte
 IPsec gateway tries to process the option, but fails
 If there is failure, ICMP packet is generated
 ICMP packet contains plaintext packet header/payload

Attacker needs to monitor packets around the Ipsec
gateway (e.g., Wi-FI AP that uses IPsec packets without
any WI-Fi security)
27
Attack on IP Protocol Field
 Attack scenario (roughly)
 Set the protocol field anything but TCP, UDP, ICMP
 Any large number in that field will freak out the real
destination
 The destination will generate a ICMP packet
 ICMP packet contains plaintext packet header/payload
 Attacker needs to monitor packets around the
destination node
28