Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

TLS Optimization

24,813 views

Published on

Recent proposals for optimizing SSL/TLS have associated security tradeoffs. This talk covers False Start, Snap Start, and the BEAST attack.

Published in: Technology, Education
  • Login to see the comments

TLS Optimization

  1. 1. Optimizing TLS/SSL Nate Lawson Cal Poly Grad Networks February 21, 2012Friday, February 24, 2012
  2. 2. Root Labs • Design and analyze security systems • Emphasis on embedded, kernel, reverse engineering, and cryptographyFriday, February 24, 2012
  3. 3. Focus • Smart phones, set-top boxes, game consoles, 2-factor tokens • Trusted boot, device drivers • Software tamper resistanceFriday, February 24, 2012
  4. 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 SLOFriday, February 24, 2012
  5. 5. SourceDNA • Software similarity search engine • Scale index to large number of binaries • Perform sophisticated alignmentFriday, February 24, 2012
  6. 6. Overview • SSL walkthrough • False Start • BEAST attack • Snap StartFriday, February 24, 2012
  7. 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-256Friday, February 24, 2012
  8. 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. 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 anotherFriday, February 24, 2012
  10. 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 reorderFriday, February 24, 2012
  11. 11. Symmetric crypto • Block ciphers turn plaintext block into ciphertext using a secret key • Recipient inverts (decrypts) block using same key • Examples: AES, 3DESFriday, February 24, 2012
  12. 12. Block chaining • Often requires “chaining” to encrypt messages longer than a single block • This does not provide integrity protectionFriday, February 24, 2012
  13. 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 otherFriday, February 24, 2012
  14. 14. Friday, February 24, 2012
  15. 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. 16. TLS Handshake Client Server ClientHello ServerHello Certificate ServerHelloDone ClientKeyExchange [ChangeCipherSpec] Finished [ChangeCipherSpec] Finished ApplicationData ApplicationDataFriday, February 24, 2012
  17. 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. 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 rootFriday, February 24, 2012
  19. 19. ServerHelloDone • Signifies end of server auth process • Allows multi-pass authentication handshake • Cert-based auth is single-passFriday, February 24, 2012
  20. 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 versionFriday, February 24, 2012
  21. 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. 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. 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
  24. 24. Session resumptionFriday, February 24, 2012
  25. 25. TLS Handshake Client Server ClientHello ServerHello Certificate ServerHelloDone ClientKeyExchange [ChangeCipherSpec] Finished [ChangeCipherSpec] Finished ApplicationData ApplicationDataFriday, February 24, 2012
  26. 26. Session resumption Client Server ClientHello ServerHello [ChangeCipherSpec] Finished [ChangeCipherSpec] Finished ApplicationData (request) ApplicationData (response)Friday, February 24, 2012
  27. 27. False StartFriday, February 24, 2012
  28. 28. False Start Client Server ClientHello ServerHello Certificate ServerHelloDone ClientKeyExchange [ChangeCipherSpec] Finished ApplicationData (request) [ChangeCipherSpec] Finished ApplicationData (response)Friday, February 24, 2012
  29. 29. Security • Attacker spoofing server can modify: • Version • RandomData • SessionID • CipherSuites & CompressionMethods • Certificate • Client will only detect after Finished message received or timeoutFriday, February 24, 2012
  30. 30. BEAST attackFriday, February 24, 2012
  31. 31. CBC encryption P1 P2 P3 IV ⊕ ⊕ ⊕ AESEnc AESEnc AESEnc C1 C2 C3Friday, February 24, 2012
  32. 32. IV reuse P1 P2 P3 P4 IV ⊕ ⊕ IV’ ⊕ ⊕ AESEnc AESEnc AESEnc AESEnc C1 C2 C3 C4Friday, February 24, 2012
  33. 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 secretFriday, February 24, 2012
  34. 34. HTTP GET /example HTTP/1.1 Host: server.example.com Origin: http://example.com Cookie: 0123456789abcdefFriday, February 24, 2012
  35. 35. HTTP GET /example?PAD=AAA HTTP/1.1 Host: server.example.com Origin: http://example.com Cookie: 0123456789abcdefFriday, February 24, 2012
  36. 36. IV reuse P1 P2 P3 P4 P5 P6 IV ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ AESEn AESEn AESEn AESEn AESEn AESEn C1 C2 C3 C4 C5 C6 ... ?PAD=AAA_ HTTP/1.1rnCookie: 0 123456789abcdefFriday, February 24, 2012
  37. 37. IV reuse P1 P2 P3 P4 P5 P6 IV ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ AESEn AESEn AESEn AESEn AESEn AESEn C1 C2 C3 C4 C5 C6 ... ?PAD=AA_H TTP/1.1rnCookie: 01 23456789abcdefFriday, February 24, 2012
  38. 38. IV reuse P1 P2 P3 P4 P5 P6 IV ⊕ ⊕ ⊕ ⊕ ⊕ ⊕ AESEn AESEn AESEn AESEn AESEn AESEn C1 C2 C3 C4 C5 C6 ... ?PAD=A_HT TP/1.1rnCookie: 012 3456789abcdefFriday, February 24, 2012
  39. 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. 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
  41. 41. Snap Start Client Server ClientHello Snap Start Extension ClientKeyExchange [ChangeCipherSpec] Finished ApplicationData (request) [ChangeCipherSpec] Finished ApplicationData (response)Friday, February 24, 2012
  42. 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 handshakeFriday, February 24, 2012
  43. 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 ticketsFriday, February 24, 2012
  44. 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 particularFriday, February 24, 2012
  45. 45. References TLS 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.htmlFriday, February 24, 2012

×