Private Network Communication II(Security Analysis of SSL3.0 and IPsec)

IS511

2

SSL/TLS PerformanceSSL 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

3

SSL/TLS PerformanceSSL 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

4

Secure Key Size in SSL/TLS1024-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

5

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.

6

Security Level of a System

How strong is the weakest point of your system?

7

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

8

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?

9

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 YeeStream cipher more vulnerable (block cipher – random

padding)Solution? Support random padding for all cipher modes

10

How Secure is Record Layer?Confidentiality: active attack

Cut-and-paste attack (from IPsec)Cut sensitive information and paste it at insensitive partIn 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 ACKSSL 3.0 defends against these attacks

Cut-and-paste-attackIndependent unidirectional session keys Authentication of each record

Short-block attackTypically web servers do not encrypt short blocksTelnet on SSL is potentially vulnerable

11

Message Authentication

SSL 2.0 used inseure MACSSL 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

12

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

… Normal handshake … C->S: {ChangeCipherSpec}C->S: {Finished} {a}kS->C: {ChangeCipherSpec}S->C: {Finished} {a}kC->S: {m}k

… Normal handshake … C->M: {ChangeCipherSpec}C->M: {Finished} {a}kM->S: {Finished} aS->M: {ChangeCipherSpec}S->M: {Finished} {a}kS->C: {Finished} aC->M: {m}k

M->S: m

{m}k: m + HMAC(k, m)

13

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

14

Version Rollback Attack

Adversary modifies SSL 3.0 hello to SSL 2.0 hello

Paul Kocher’s workaround to detect the attackUse RSA PKCS non-random padding bytesRSA is the only key-exchange algorithm in SSL 2.0

15

Key-exchange Algorithm RollbackBasic 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 // server provide DHE paramsM->C: {p,g,y}Ks

[client key exchange]C->M: kg mod p // client use RSA to encrypt k with wrong params M->S: gx mod p

16

Key-exchange Algorithm RollbackBasic 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 // server provide DHE paramsM->C: {p,g,y}Ks

[client key exchange]C->M: kg mod p // client use RSA to encrypt k with wrong params M->S: gx mod p

17

Key-exchange Algorithm Rollbackkg mod p: k is pre_master_secret, but g and p

are DHE parameters not RSA’s g-th root of this value would produce ‘k’ M can figure out pre_master_secret

gx mod p is given to server Server would think (gxy mod p) is

pre_master_secret So, complete man-in-the-middle attack is

launchedThis is caused by possible implementation

bugs Careful implementations check the length of

paramsHm, you may want to say Finish message?

Finish is supposed to provide MAC?

18

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

19

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

packetProtocol field manipulation

Modify the protocol field to one that’s not supported

Have the end node generate an ICMP packet

20

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

21

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

22

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 IPsecAttacker

23

Destination Address Rewriting

ver length

32 bits

data (variable length,typically a TCP

or UDP segment)

16-bit identifier

header checksum

time tolive

32 bit source IP address

head.len

type ofservice

flgsfragment

offsetupper layer

32 bit destination IP address

Options (if any)

How to change dest IP? Dest IP = DestAddr Attacker IP = AttrAddr XOR the first four bytes

of C2 with M= (DestAddr AttrAddr)

Implications?

P2(C2)

P1(C1)

P3(C3)

24

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

25

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

26

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?

27

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)

28

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