tls optimization

Optimizing TLS/SSL

Nate Lawson

Cal Poly Grad NetworksFebruary 21, 2012

Friday, February 24, 2012

• Design and analyze security systems

• Emphasis on embedded, kernel, reverse engineering, and cryptography

Root Labs


• Smart phones, set-top boxes, game consoles, 2-factor tokens

• Trusted boot, device drivers

• Software tamper resistance

Focus


• Cryptography Research

• Paul Kocher’s company (author of SSL 3.0)

• Co-designed Blu-ray disc security layer, aka BD+

• Infogard Labs in SLO

Before


SourceDNA

• Software similarity search engine

• Scale index to large number of binaries

• Perform sophisticated alignment


Overview

• SSL walkthrough

• False Start

• BEAST attack

• Snap Start


• SSL (Secure Sockets Layer) v2.0 (1994)• Serious security problems including incomplete MAC

coverage of padding• SSL v3.0 (1996)

• Major revision to address security problems• TLS (Transport Layer Security) 1.0 (1999)

• Added new crypto algorithm support• IETF takes over

• TLS 1.1 (2006)• Address Vaudenay’s CBC attacks on record layer

• TLS 1.2 (2008)• SHA/MD5 for Finished message now SHA-256

History


• SSL provides security at the transport layer (OSI model L4)

• Stream of bytes in, private/untampered stream of bytes out

• Application logic is unmodified

• Can be adapted to datagram service also (DTLS)

• Compare to IPSEC

• Mostly used as an L3 protocol (datagram tunneling)

Layered model


Security goals• Privacy

• Data within SSL session should not be recoverable by anyone except the endpoints

• Integrity

• Data in transit should not be modified without detection

• Authentication

• No endpoint should be able to masquerade as another


Attacker capabilities

• Normal participant

• Can talk to server that is also talking to other parties

• Passive eavesdropping

• Observe any or all messages sent by other parties

• Active (Man in the Middle)

• Insert or replay old messages

• Modify

• Delete or reorder


Symmetric crypto

• Block ciphers turn plaintext block into ciphertext using a secret key

• Recipient inverts (decrypts) block using same key

• Examples: AES, 3DES


Block chaining

• Often requires “chaining” to encrypt messages longer than a single block

• This does not provide integrity protection


Public key crypto

• Data transformed with one key can only be inverted with the other key (asymmetric)

• Examples: RSA, (EC)Diffie-Hellman,(EC)DSA

• Can encrypt data to a recipient without also being able to decrypt it afterward

• Can sign data by encrypting it with one key and publishing the other


Certificates

• Associate a name with a public key

• Trusted party uses private key to sign the message “joe.com = 0x09f9…”

• Public key of trusted party came with your web browser

• Key management still a problem

• Expire certs and explicitly revoke them if a private key is compromised (CRL)

• Or, check with the trusted party each time you want to use one (OCSP)


ClientHello

ServerHello

Certificate

ClientKeyExchange

[ChangeCipherSpec]

[ChangeCipherSpec]

Finished

Finished

ServerHelloDone

ApplicationData ApplicationData

Client Server

TLS Handshake


Hello

• Initiates connection and specifies parameters

• Initiator sends list (i.e., CipherSuites) and responder selects one item from list

• SessionID is used for resuming (explained later)

VersionRandomDataSessionIDCipherSuitesCompressionMethods

Client / ServerHello


Certificate

• Provides a signed public key value to the other party

• Other side must verify information

• CN field is myhost.com = IP address in TCP connection

• Cert chain back to root

ASN.1Cert

(X.509 v3 format)

Certificate


ServerHelloDone

• Signifies end of server auth process

• Allows multi-pass authentication handshake

• Cert-based auth is single-pass


ClientKeyExchange

• Client sends encrypted premaster secret to server

• Assumes RSA public key crypto (most common)

• Server checks ClientVersion matches highest advertised version

RSA-PubKey-Encrypt( ClientVersion PreMasterSecret[48])

ClientKeyExchange


ChangeCipherSpec

• Indicates following datagrams will be encrypted

• Disambiguates case where next message may be error or encrypted data

• Each side now calculates data encryption key (K)

Hash( PreMasterSecret ClientRandom ServerRandom)

MasterSecret computation


Finished• Indicates all protocol

negotiation is complete and data may be exchanged

• Includes hashes of all handshake messages seen by each side

• Also, magic integers 0x434C4E54 or 0x53525652 (why?)

AES-K-Encrypt( Magic MD5(handshake_messages) SHA1(handshake_messages))

Finished


ApplicationData

• Encapsulates encrypted data for duration of session

• Can span multiple TCP packets

AES-CBC-K-Encrypt( Type Version Length Data MAC Padding PaddingLength)

ApplicationData


Session resumption


ClientHello

ServerHello

Certificate

ClientKeyExchange

[ChangeCipherSpec]

[ChangeCipherSpec]

Finished

Finished

ServerHelloDone

ApplicationData ApplicationData

Client Server

TLS Handshake


ClientHello

ServerHello

[ChangeCipherSpec]

[ChangeCipherSpec]

Finished

Finished

ApplicationData (request)

ApplicationData (response)

Client Server

Session resumption


False Start


ClientHello

ServerHello

Certificate

ClientKeyExchange

[ChangeCipherSpec]

[ChangeCipherSpec]

Finished

Finished

ServerHelloDone

ApplicationData (request)


Client Server

False Start


Security• Attacker spoofing server can modify:

• Version

• RandomData

• SessionID

• CipherSuites & CompressionMethods

• Certificate

• Client will only detect after Finished message received or timeout


BEAST attack


CBC encryption

P1

AESEnc

IV

C1

P2

AESEnc

C2

P3

AESEnc

C3

⊕ ⊕ ⊕


IV reuse

P1

AESEnc

IV

C1

P2

AESEnc

C2

⊕ ⊕

P3

AESEnc

IV’

C3

P4

AESEnc

C4

⊕ ⊕


Process

1. Send message with 1 unknown byte

2. Send another message with guess for that byte aligned with same slot

3. If ciphertext matches, guess was correct

Repeat for up to 256 * n bytes of secret


HTTP

GET /example HTTP/1.1

Host: server.example.com

Origin: http://example.com

Cookie: 0123456789abcdef


http://example.com

http://example.com

HTTP

GET /example?PAD=AAA HTTP/1.1

Host: server.example.com

Origin: http://example.com

Cookie: 0123456789abcdef


http://example.com

http://example.com

IV reuseP1

AESEn

IV

C1

P2

AESEn

C2

⊕ ⊕

P3

AESEn

C3

P4

AESEn

C4

⊕ ⊕

... ?PAD=AAA_ 123456789abcdefHTTP/1.1\r\nCookie: 0

P5

AESEn

C5

P6

AESEn

C6

⊕ ⊕


IV reuseP1

AESEn

IV

C1

P2

AESEn

C2

⊕ ⊕

P3

AESEn

C3

P4

AESEn

C4

⊕ ⊕

... ?PAD=AA_H 23456789abcdefTTP/1.1\r\nCookie: 01

P5

AESEn

C5

P6

AESEn

C6

⊕ ⊕


IV reuseP1

AESEn

IV

C1

P2

AESEn

C2

⊕ ⊕

P3

AESEn

C3

P4

AESEn

C4

⊕ ⊕

... ?PAD=A_HT 3456789abcdefTP/1.1\r\nCookie: 012

P5

AESEn

C5

P6

AESEn

C6

⊕ ⊕


Relations

G =15 bytes known data || 1 byte guess

P3 = C2 ⊕ G

C3 = AES(C2 ⊕ C2 ⊕ G) = AES(G)


Attacker requirements•Ability to choose or influence some of the

message

•Internal alignment via adjustment of padding fields

•Choice of plaintext guess

•Partial knowledge of the original message

•See each previous record’s C2 (IV’)


ClientHello

[ChangeCipherSpec]

Finished

ApplicationData(request)


Client Server

Snap Start

[ChangeCipherSpec]

Finished

ClientKeyExchange

Snap Start Extension


Snap Start changes

• Server advertises initial orbit and cipher suite in Hello extension

• On next connection, client sends:

• Prior orbit, cipher suite

• Chosen random_bytes

• Checksum of predicted server handshake


Limitations

• Client uses cached cipher suite

• Client chooses random_bytes

• Server must track some number of previous values and reject connection if reused

• Server must validate timestamp

• No SessionID and so no resume or must use session tickets


Conclusions

• SSL provides a well-tested secure transport layer

• Security protocols require careful interdependence of components

• Easy to make mistakes designing security and crypto in particular


ReferencesTLS Overview, http://en.wikipedia.org/wiki/Transport_Layer_Security

False Start draft, https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00

Snap Start draft (withdrawn), http://www.imperialviolet.org/binary/draft-agl-tls-snapstart-00.html

Security criticism of False & Snap Start, http://www.ietf.org/mail-archive/web/tls/current/msg06933.html

BEAST Attack description, http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html

Fixing BEAST, http://www.educatedguesswork.org/2011/11/rizzoduong_beast_countermeasur.html


http://en.wikipedia.org/wiki/Transport_Layer_Security

http://en.wikipedia.org/wiki/Transport_Layer_Security

https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00

https://tools.ietf.org/html/draft-bmoeller-tls-falsestart-00

http://www.imperialviolet.org/binary/draft-agl-tls-snapstart-00.html




http://www.ietf.org/mail-archive/web/tls/current/msg06933.html




http://www.educatedguesswork.org/2011/09/security_impact_of_the_rizzodu.html




http://www.educatedguesswork.org/2011/11/rizzoduong_beast_countermeasur.html




tls optimization

Technology