4. Before
• Cryptography Research
• Paul Kocher’s company (author of SSL
3.0)
• Co-designed Blu-ray disc security layer,
aka BD+
• Infogard Labs in SLO
Friday, February 24, 2012
5. SourceDNA
• Software similarity search engine
• Scale index to large number of binaries
• Perform sophisticated alignment
Friday, February 24, 2012
7. History
• 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
Friday, February 24, 2012
8. Layered model
• 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)
Friday, February 24, 2012
9. 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
10. 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
11. 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
12. Block chaining
• Often requires
“chaining” to encrypt
messages longer than a
single block
• This does not provide
integrity protection
Friday, February 24, 2012
13. 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
15. 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
16. TLS Handshake
Client Server
ClientHello
ServerHello
Certificate
ServerHelloDone
ClientKeyExchange
[ChangeCipherSpec]
Finished
[ChangeCipherSpec]
Finished
ApplicationData ApplicationData
Friday, February 24, 2012
17. Hello
• Initiates connection and
specifies parameters Client / ServerHello
Version
• Initiator sends list (i.e., RandomData
SessionID
CipherSuites) and CipherSuites
responder selects one CompressionMethods
item from list
• SessionID is used for
resuming (explained
later)
Friday, February 24, 2012
18. Certificate
• Provides a signed public
key value to the other Certificate
party ASN.1Cert
• Other side must verify (X.509 v3 format)
information
• CN field is myhost.com
= IP address in TCP
connection
• Cert chain back to root
Friday, February 24, 2012
19. ServerHelloDone
• Signifies end of server auth process
• Allows multi-pass authentication handshake
• Cert-based auth is single-pass
Friday, February 24, 2012
20. ClientKeyExchange
• Client sends encrypted
premaster secret to
server ClientKeyExchange
RSA-PubKey-Encrypt(
•
ClientVersion
Assumes RSA public key PreMasterSecret[48]
crypto (most common) )
• Server checks
ClientVersion matches
highest advertised
version
Friday, February 24, 2012
21. ChangeCipherSpec
• Indicates following
datagrams will be
encrypted
MasterSecret computation
• Disambiguates case Hash(
PreMasterSecret
where next message may ClientRandom
be error or encrypted ServerRandom
data )
• Each side now calculates
data encryption key (K)
Friday, February 24, 2012
22. Finished
• Indicates all protocol
negotiation is complete
and data may be Finished
exchanged AES-K-Encrypt(
Magic
MD5(handshake_messages)
• Includes hashes of all SHA1(handshake_messages)
handshake messages )
seen by each side
• Also, magic integers
0x434C4E54 or
0x53525652 (why?)
Friday, February 24, 2012
23. ApplicationData
ApplicationData
• Encapsulates encrypted
AES-CBC-K-Encrypt(
data for duration of Type
session Version
Length
Data
• Can span multiple TCP MAC
Padding
packets PaddingLength
)
Friday, February 24, 2012
29. 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
31. CBC encryption
P1 P2 P3
IV ⊕ ⊕ ⊕
AESEnc AESEnc AESEnc
C1 C2 C3
Friday, February 24, 2012
32. IV reuse
P1 P2 P3 P4
IV ⊕ ⊕ IV’ ⊕ ⊕
AESEnc AESEnc AESEnc AESEnc
C1 C2 C3 C4
Friday, February 24, 2012
33. 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
34. HTTP
GET /example HTTP/1.1
Host: server.example.com
Origin: http://example.com
Cookie: 0123456789abcdef
Friday, February 24, 2012
35. HTTP
GET /example?PAD=AAA HTTP/1.1
Host: server.example.com
Origin: http://example.com
Cookie: 0123456789abcdef
Friday, February 24, 2012
39. Relations
G =15 bytes known data || 1 byte guess
P3 = C2 ⊕ G
C3 = AES(C2 ⊕ C2 ⊕ G) = AES(G)
Friday, February 24, 2012
40. 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
42. 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
43. 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
44. 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