tls optimization
DESCRIPTION
Recent proposals for optimizing SSL/TLS have associated security tradeoffs. This talk covers False Start, Snap Start, and the BEAST attack.TRANSCRIPT
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
Friday, February 24, 2012
• Smart phones, set-top boxes, game consoles, 2-factor tokens
• Trusted boot, device drivers
• Software tamper resistance
Focus
Friday, February 24, 2012
• 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
Friday, February 24, 2012
SourceDNA
• Software similarity search engine
• Scale index to large number of binaries
• Perform sophisticated alignment
Friday, February 24, 2012
Overview
• SSL walkthrough
• False Start
• BEAST attack
• Snap Start
Friday, February 24, 2012
• 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
Friday, February 24, 2012
• 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
Friday, February 24, 2012
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
Friday, February 24, 2012
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
Friday, February 24, 2012
Symmetric crypto
• Block ciphers turn plaintext block into ciphertext using a secret key
• Recipient inverts (decrypts) block using same key
• Examples: AES, 3DES
Friday, February 24, 2012
Block chaining
• Often requires “chaining” to encrypt messages longer than a single block
• This does not provide integrity protection
Friday, February 24, 2012
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
Friday, February 24, 2012
Friday, February 24, 2012
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)
Friday, February 24, 2012
ClientHello
ServerHello
Certificate
ClientKeyExchange
[ChangeCipherSpec]
[ChangeCipherSpec]
Finished
Finished
ServerHelloDone
ApplicationData ApplicationData
Client Server
TLS Handshake
Friday, February 24, 2012
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
Friday, February 24, 2012
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
Friday, February 24, 2012
ServerHelloDone
• Signifies end of server auth process
• Allows multi-pass authentication handshake
• Cert-based auth is single-pass
Friday, February 24, 2012
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
Friday, February 24, 2012
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
Friday, February 24, 2012
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
Friday, February 24, 2012
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
Friday, February 24, 2012
Session resumption
Friday, February 24, 2012
ClientHello
ServerHello
Certificate
ClientKeyExchange
[ChangeCipherSpec]
[ChangeCipherSpec]
Finished
Finished
ServerHelloDone
ApplicationData ApplicationData
Client Server
TLS Handshake
Friday, February 24, 2012
ClientHello
ServerHello
[ChangeCipherSpec]
[ChangeCipherSpec]
Finished
Finished
ApplicationData (request)
ApplicationData (response)
Client Server
Session resumption
Friday, February 24, 2012
False Start
Friday, February 24, 2012
ClientHello
ServerHello
Certificate
ClientKeyExchange
[ChangeCipherSpec]
[ChangeCipherSpec]
Finished
Finished
ServerHelloDone
ApplicationData (request)
ApplicationData (response)
Client Server
False Start
Friday, February 24, 2012
Security• Attacker spoofing server can modify:
• Version
• RandomData
• SessionID
• CipherSuites & CompressionMethods
• Certificate
• Client will only detect after Finished message received or timeout
Friday, February 24, 2012
BEAST attack
Friday, February 24, 2012
CBC encryption
P1
AESEnc
IV
C1
P2
AESEnc
C2
P3
AESEnc
C3
⊕ ⊕ ⊕
Friday, February 24, 2012
IV reuse
P1
AESEnc
IV
C1
P2
AESEnc
C2
⊕ ⊕
P3
AESEnc
IV’
C3
P4
AESEnc
C4
⊕ ⊕
Friday, February 24, 2012
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
Friday, February 24, 2012
HTTP
GET /example HTTP/1.1
Host: server.example.com
Origin: http://example.com
Cookie: 0123456789abcdef
Friday, February 24, 2012
HTTP
GET /example?PAD=AAA HTTP/1.1
Host: server.example.com
Origin: http://example.com
Cookie: 0123456789abcdef
Friday, February 24, 2012
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
⊕ ⊕
Friday, February 24, 2012
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
⊕ ⊕
Friday, February 24, 2012
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
⊕ ⊕
Friday, February 24, 2012
Relations
G =15 bytes known data || 1 byte guess
P3 = C2 ⊕ G
C3 = AES(C2 ⊕ C2 ⊕ G) = AES(G)
Friday, February 24, 2012
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’)
Friday, February 24, 2012
ClientHello
[ChangeCipherSpec]
Finished
ApplicationData(request)
ApplicationData (response)
Client Server
Snap Start
[ChangeCipherSpec]
Finished
ClientKeyExchange
Snap Start Extension
Friday, February 24, 2012
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
Friday, February 24, 2012
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
Friday, February 24, 2012
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
Friday, February 24, 2012
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
Friday, February 24, 2012