1. The Secure Socket Layer Protocol (SSL) CS391

2. Overview

3. What is SSL / TLS?  TLS = Transport Layer Security protocol, ver 1.0 De facto standard for Internet security De facto standard for Internet security “The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications” “The primary goal of the TLS protocol is to provide privacy and data integrity between two communicating applications” In practice, used to protect information transmitted between browsers and Web servers In practice, used to protect information transmitted between browsers and Web servers

4. TLS and SSL  TLS is based on the Secure Sockets Layers protocol (SSL), ver 3.0 Same protocol design, different algorithms Same protocol design, different algorithms  Deployed in nearly every web browser

5. SSL / TLS in the Real World

6. History of the Protocol  SSL 1.0 Designed by Netscape in the early 1990’s (before 1994) Designed by Netscape in the early 1990’s (before 1994)  SSL 2.0 The first published SSL version (by Netscape, November 1994) The first published SSL version (by Netscape, November 1994) Suffers from several problems. Suffers from several problems.  SSL 3.0 The latest SSL version (Designed by Netscape, 1996) The latest SSL version (Designed by Netscape, 1996)  TLS 1.0 Internet standard based on SSL 3.0, January 1999 Internet standard based on SSL 3.0, January 1999 Not interoperable with SSL 3.0 Not interoperable with SSL 3.0

7. SSL 2.0 Vulnerabilities  Short key length In export-weakened modes, SSL 2.0 unnecessarily weakens the authentication keys to 40 bits. In export-weakened modes, SSL 2.0 unnecessarily weakens the authentication keys to 40 bits.  Weak MAC construction  Message integrity vulnerability SSL 2.0 feeds padding bytes into the MAC in block cipher modes, but leaves the padding-length unauthenticated, may allow active attackers to delete bytes from the end of messages SSL 2.0 feeds padding bytes into the MAC in block cipher modes, but leaves the padding-length unauthenticated, may allow active attackers to delete bytes from the end of messages

8. SSL2 Vulnerabilities  Ciphersuite rollback attack An active attacker may edit the list of ciphersuite preferences in the hello messages to invisibly force both endpoints to use a weaker form of encryption An active attacker may edit the list of ciphersuite preferences in the hello messages to invisibly force both endpoints to use a weaker form of encryption “Least common denominator" security under active attack “Least common denominator" security under active attack

9. Request for Comments  TLS version 1.0 is described in RFC 2246  The RFC describes the protocol in sufficient detail for both developers and analysts.  Mixes prose and pseudocode.  protocols look like when they emerge from the committee  Try to download the RFC and use it as a reference for this lecture.

10. TLS Basics  TLS consists of two protocols  Handshake protocol Use public-key cryptography to establish a shared secret key between the client and the server Use public-key cryptography to establish a shared secret key between the client and the server  Record protocol Use the secret key established in the handshake protocol to protect communication between the client and the server Use the secret key established in the handshake protocol to protect communication between the client and the server

11. SSL and the Protocol Stack  SSL between Transmission Control Protocol (TCP) layer and Application layer  Actually 2 layers Record Record Secure Application Secure Application  Can run under any protocol that relies on TCP, including HTTP, LDAP, POP3, FTP

12. The Four Upper Layer Protocols  Handshaking Protocol Establish (agree on) communication (session) parameters Establish (agree on) communication (session) parameters  Change CipherSpec Protocol Inform peer that sender wishes to switch to a new set of encryption keys (generated by both peers). Inform peer that sender wishes to switch to a new set of encryption keys (generated by both peers).  Alert Protocol Messages important to SSL connections Messages important to SSL connections  Application Encryption Protocol Encrypt/Decrypt application data Encrypt/Decrypt application data

14. The Client Hello Message  Client Hello Message  The client initiates a session by sending a Client Hello message to the server. The Client Hello message contains: Version Number. The version number of the highest version that the client supports. Version Number. The version number of the highest version that the client supports. Client Random. A 4-byte number that consists of the client’s date and time, plus a 28-byte cryptographically-generated pseudorandom number. This is used in the calculation of the Master Secret from which the encryption keys are derived. Client Random. A 4-byte number that consists of the client’s date and time, plus a 28-byte cryptographically-generated pseudorandom number. This is used in the calculation of the Master Secret from which the encryption keys are derived.

15. Client Hello Message (Optional) Session Identification. A byte string used to identify an active or resumable session state. (Optional) Session Identification. A byte string used to identify an active or resumable session state. Cipher Suite. The list of cipher suites available on the client. An example of a cipher suite is TLS_RSA_WITH_DES_CBC_SHA, where TLS is the protocol version, RSA is the algorithm that will be used for the key exchange, DES_CBC is the encryption algorithm (using a 56-bit key in CBC mode), and SHA-1 is the hash function. Cipher Suite. The list of cipher suites available on the client. An example of a cipher suite is TLS_RSA_WITH_DES_CBC_SHA, where TLS is the protocol version, RSA is the algorithm that will be used for the key exchange, DES_CBC is the encryption algorithm (using a 56-bit key in CBC mode), and SHA-1 is the hash function.

16. Server Response to Client Hello

17. Server Hello Message  Server Hello Message  The server responds with a Server Hello message. The Server Hello message includes: Version Number. The server sends the highest version number that is supported by both sides. Version Number. The server sends the highest version number that is supported by both sides. Server Random[32]. ServerRandom[32] is a 4-byte representation of the server’s date and time plus a 28-byte, cryptographically-generated, pseudorandom number. Server Random[32]. ServerRandom[32] is a 4-byte representation of the server’s date and time plus a 28-byte, cryptographically-generated, pseudorandom number. Session Identification (if any). This can be one of three choices. New session ID., Resumed Session ID, Null (new session, but the server is not willing to resume it at a later time) Session Identification (if any). This can be one of three choices. New session ID., Resumed Session ID, Null (new session, but the server is not willing to resume it at a later time)  Cipher Suite. The server chooses the strongest cipher that both the client and server support. If there are no cipher suites that both parties support, the session is ended with a handshake failure alert.  Compression Algorithm. If used, specifies the compression algorithm to use.

18. Server Certificate Message The server sends its certificate to the client. The server certificate contains the server’s public key. The client uses this key to authenticate the server and to encrypt the Premaster Secret. The Server Certificate message includes: The server’s certificate list. The first certificate in the list is the server’s X.509v3 certificate that contains the server’s public key. The server’s certificate list. The first certificate in the list is the server’s X.509v3 certificate that contains the server’s public key. Other validating certificates. All other validating certificates, up to but not including the root certificate from the CA, signed by the CA. Other validating certificates. All other validating certificates, up to but not including the root certificate from the CA, signed by the CA.

19. (Optional) Server Key Exchange Message The server creates and sends a temporary key to the client. This key can be used by the client to encrypt the Client Key Exchange message later in the process. The step is only required when the server’s certificate does not contain a public key that is suitable for key exchange or when the cipher suite mandates the use of an ephemeral key for the key exchange operation.

20. (Optional) Client Certificate Request Message  The server must always present its certificates to the client, but the client is not always required to authenticate itself.  Therefore, the client is not always required to send its certificates to the server.  If the server does not require client authentication, then this message is not sent.

21. Server Hello Done Message  This message indicates that the server is finished and awaiting a response from the client. This message has no content. It signals that the Server Hello sequence is finished.

22. Client Response to Server Hello

23. Client Certificate Message (Required if Requested)  If the server sent a Client Certificate Request, the client sends its certificate to the server for client authentication.  The client’s certificate contains the client’s public key.  The client certificate message includes the client’s certificate list. The first certificate in the list is the client’s X.509v3 certificate that contains the client’s public key.  After that are other validating certificates, up to but not including the root certificate from the CA, signed by the CA.

24. Client Key Exchange Message  The client sends a Client Key Exchange message after computing the premaster secret using the two random values that are generated during the Client Hello message and the Server Hello message.  Before it is transmitted to the server, the premaster secret is encrypted by the public key from the server’s certificate. Both parties compute the master secret locally and derive the session key from it.  If the server can decrypt this data and complete the protocol, the client is assured that the server has the correct private key. This step is crucial to prove the authenticity of the server. Only the server with the private key that matches the public key in the certificate can decrypt this data and continue the protocol negotiation.

25. Client Key Exchange Message  The Client Key Exchange message includes: Client’s protocol version. The server will verify that it matches the original value sent in the Client Hello message. This measure guards against rollback attacks. Rollback attacks work by manipulating the message in order to cause the server and the client to use a less secure, earlier version of the protocol. Client’s protocol version. The server will verify that it matches the original value sent in the Client Hello message. This measure guards against rollback attacks. Rollback attacks work by manipulating the message in order to cause the server and the client to use a less secure, earlier version of the protocol. Pre-master secret. This is the client-generated number (48-byte for RSA), encrypted with the server’s public key, that is used with the Client Random and the Server Random to create the Master Secret. Pre-master secret. This is the client-generated number (48-byte for RSA), encrypted with the server’s public key, that is used with the Client Random and the Server Random to create the Master Secret.

26. TLS Handshake Protocol  Two parties: client and server  Negotiate version of the protocol and the set of cryptographic algorithms to be used Interoperability between different implementations of the protocol Interoperability between different implementations of the protocol  Authenticate client and server (optional) Use digital certificates to learn each other’s public keys and verify each other’s identity Use digital certificates to learn each other’s public keys and verify each other’s identity  Use public keys to establish a shared secret

27. Handshake Protocol Structure C ClientHello ServerHello, [Certificate], [ServerKeyExchange], [CertificateRequest], ServerHelloDone S [Certificate], ClientKeyExchange, [CertificateVerify] Finished switch to negotiated cipher Finished switch to negotiated cipher

28. Abbreviated Handshake  The handshake protocol may be executed in an abbreviated form to resume a previously established session No authentication, key material not exchanged No authentication, key material not exchanged Session resumed from an old state Session resumed from an old state  For complete analysis, have to model both full and abbreviated handshake protocol This is a common situation: many protocols have several branches, subprotocols for error handling, etc. This is a common situation: many protocols have several branches, subprotocols for error handling, etc.

29. Rational Reconstruction  Begin with simple, intuitive protocol Ignore client authentication Ignore client authentication Ignore verification messages at the end of the handshake protocol Ignore verification messages at the end of the handshake protocol Model only essential parts of messages (e.g., ignore padding) Model only essential parts of messages (e.g., ignore padding)  Execute the model checker and find a bug  Add a piece of TLS to fix the bug and repeat Better understand the design of the protocol Better understand the design of the protocol

30. Protocol Step by Step: ClientHello C ClientHello S Client announces (in plaintext): Protocol version he is running Cryptographic algorithms he supports

31. struct { ProtocolVersion client_version; ProtocolVersion client_version; Random random; Random random; SessionID session_id; SessionID session_id; CipherSuite cipher_suites; CipherSuite cipher_suites; CompressionMethod compression_methods; CompressionMethod compression_methods; } ClientHello ClientHello (RFC) Highest version of the protocol supported by the client Session id (if the client wants to resume an old session) Cryptographic algorithms supported by the client (e.g., RSA or Diffie-Hellman)

32. ClientHello (Murj) ruleset i: ClientId do ruleset j: ServerId do ruleset j: ServerId do rule "Client sends ClientHello to server (new session)" rule "Client sends ClientHello to server (new session)" cli[i].state = M_SLEEP & cli[i].state = M_SLEEP & cli[i].resumeSession = false cli[i].resumeSession = false ==> ==> var var outM: Message; -- outgoing message outM: Message; -- outgoing message begin begin outM.source := i; outM.source := i; outM.dest := j; outM.dest := j; outM.session := 0; outM.session := 0; outM.mType := M_CLIENT_HELLO; outM.mType := M_CLIENT_HELLO; outM.version := cli[i].version; outM.version := cli[i].version; outM.suite := cli[i].suite; outM.suite := cli[i].suite; outM.random := freshNonce(); outM.random := freshNonce(); multisetadd (outM, cliNet); multisetadd (outM, cliNet); cli[i].state := M_SERVER_HELLO; cli[i].state := M_SERVER_HELLO; end; end; end;

33. ServerHello C C, Version c, suite c, N c ServerHello S Server responds (in plaintext) with: Highest protocol version both client & server support Strongest cryptographic suite selected from those offered by the client

34. ServerHello (Murj) ruleset i: ServerId do choose l: serNet do choose l: serNet do rule “Server receives ServerHello (new session)" rule “Server receives ServerHello (new session)" ser[i].clients[0].state = M_CLIENT_HELLO & ser[i].clients[0].state = M_CLIENT_HELLO & serNet[l].dest = i & serNet[l].dest = i & serNet[l].session = 0 serNet[l].session = 0 ==> ==> var var inM: Message; -- incoming message inM: Message; -- incoming message outM: Message; -- outgoing message outM: Message; -- outgoing message begin begin inM := serNet[l]; -- receive message inM := serNet[l]; -- receive message if inM.mType = M_CLIENT_HELLO then if inM.mType = M_CLIENT_HELLO then outM.source := i; outM.source := i; outM.dest := inM.source; outM.dest := inM.source; outM.session := freshSessionId(); outM.session := freshSessionId(); outM.mType := M_SERVER_HELLO; outM.mType := M_SERVER_HELLO; outM.version := ser[i].version; outM.version := ser[i].version; outM.suite := ser[i].suite; outM.suite := ser[i].suite; outM.random := freshNonce(); outM.random := freshNonce(); multisetadd (outM, serNet); multisetadd (outM, serNet); ser[i].state := M_SERVER_SEND_KEY; ser[i].state := M_SERVER_SEND_KEY; end; end; end; end; end; end;

35. ServerKeyExchange C Version s, suite s, N s, ServerKeyExchange S Server responds with his public-key certificate containing either his RSA, or his Diffie-Hellman public key (depending on chosen crypto suite) C, Version c, suite c, N c

36. “Abstract” Cryptography  We will use abstract data types to model cryptographic operations Assumes that cryptography is perfect Assumes that cryptography is perfect No details of the actual cryptographic schemes No details of the actual cryptographic schemes Ignores bit length of keys, random numbers, etc. Ignores bit length of keys, random numbers, etc.  Simple notation for encryption, signatures, hashes {M} k is message M encrypted with key k {M} k is message M encrypted with key k sig k (M) is message M digitally signed with key k sig k (M) is message M digitally signed with key k hash(M) for the result of hashing message M with a cryptographically strong hash function hash(M) for the result of hashing message M with a cryptographically strong hash function

37. ClientKeyExchange C Version s, suite s, N s, sig ca (S,K s ), “ServerHelloDone” S C, Version c, suite c, N c ClientKeyExchange Client generates some secret key material and sends it to the server encrypted with the server’s public key

38. struct { select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret; case rsa: EncryptedPreMasterSecret; case diffie_hellman: ClientDiffieHellmanPublic; case diffie_hellman: ClientDiffieHellmanPublic; } exchange_keys } exchange_keys } ClientKeyExchange struct { ProtocolVersion client_version; ProtocolVersion client_version; opaque random[46]; opaque random[46]; } PreMasterSecret ClientKeyExchange (RFC) Let’s model this as {Secret c } Ks

39. “Core” SSL C Version s, suite s, N s, sig ca (S,K s ), “ServerHelloDone” S C, Version c, suite c, N c {Secret c } Ks switch to key derived from secret c If the protocol is correct, C and S share some secret key material secret c at this point switch to key derived from secret c

40. Participants as Finite-State Machines M_SLEEP ClientHello Mur j rules define a finite-state machine for each protocol participant Client state M_SERVER_HELLOM_SERVER_KEYM_SEND_KEY M_CLIENT_HELLO Server state M_SEND_KEYM_CLIENT_KEYM_DONE ServerHello ServerKeyExchange ClientKeyExchange

41. Intruder Model Intruder Model Analysis Tool Formal Protocol Informal Protocol Description Find error Mur j code RFC Mur j code, similar for all protocols

42. Intruder Can Intercept  Store a message from the network in the data structure modeling intruder’s “knowledge” ruleset i: IntruderId do choose l: cliNet do choose l: cliNet do rule "Intruder intercepts client's message" rule "Intruder intercepts client's message" cliNet[l].fromIntruder = false cliNet[l].fromIntruder = false ==> ==> begin begin alias msg: cliNet[l] do -- message from the net alias msg: cliNet[l] do -- message from the net … alias known: int[i].messages do alias known: int[i].messages do if multisetcount(m: known, if multisetcount(m: known, msgEqual(known[m], msg)) = 0 then msgEqual(known[m], msg)) = 0 then multisetadd(msg, known); multisetadd(msg, known); end; end;

43. Intruder Can Decrypt if Knows Key  If the key is stored in the data structure modeling intruder’s “knowledge”, then read message ruleset i: IntruderId do choose l: cliNet do choose l: cliNet do rule "Intruder intercepts client's message" rule "Intruder intercepts client's message" cliNet[l].fromIntruder = false cliNet[l].fromIntruder = false ==> ==> begin begin alias msg: cliNet[l] do -- message from the net alias msg: cliNet[l] do -- message from the net … if msg.mType = M_CLIENT_KEY_EXCHANGE then if msg.mType = M_CLIENT_KEY_EXCHANGE then if keyEqual(msg.encKey, int[i].publicKey.key) then if keyEqual(msg.encKey, int[i].publicKey.key) then alias sKeys: int[i].secretKeys do alias sKeys: int[i].secretKeys do if multisetcount(s: sKeys, if multisetcount(s: sKeys, keyEqual(sKeys[s], msg.secretKey)) = 0 then keyEqual(sKeys[s], msg.secretKey)) = 0 then multisetadd(msg.secretKey, sKeys); multisetadd(msg.secretKey, sKeys); end; end;

44. Intruder Can Create New Messages  Assemble pieces stored in the intruder’s “knowledge” to form a message of the right format ruleset i: IntruderId do ruleset d: ClientId do ruleset d: ClientId do ruleset s: ValidSessionId do ruleset s: ValidSessionId do choose n: int[i].nonces do choose n: int[i].nonces do ruleset version: Versions do ruleset version: Versions do rule "Intruder generates fake ServerHello" rule "Intruder generates fake ServerHello" cli[d].state = M_SERVER_HELLO cli[d].state = M_SERVER_HELLO ==> ==> var var outM: Message; -- outgoing message outM: Message; -- outgoing message begin begin outM.source := i; outM.dest := d; outM.session := s; outM.source := i; outM.dest := d; outM.session := s; outM.mType := M_SERVER_HELLO; outM.mType := M_SERVER_HELLO; outM.version := version; outM.version := version; outM.random := int[i].nonces[n]; outM.random := int[i].nonces[n]; multisetadd (outM, cliNet); multisetadd (outM, cliNet); end; end; end; end; end; end; end; end;

45. Intruder Model and Cryptography  There is no actual cryptography in our model Messages are marked as “encrypted” or “signed”, and the intruder rules respect these markers Messages are marked as “encrypted” or “signed”, and the intruder rules respect these markers  Our assumption that cryptography is perfect is reflected in the absence of certain intruder rules There is no rule for creating a digital signature with a key that is not known to the intruder There is no rule for creating a digital signature with a key that is not known to the intruder There is no rule for reading the contents of a message which is marked as “encrypted” with a certain key, when this key is not known to the intruder There is no rule for reading the contents of a message which is marked as “encrypted” with a certain key, when this key is not known to the intruder There is no rule for reading the contents of a “hashed” message There is no rule for reading the contents of a “hashed” message

46. Running Murj Analysis Intruder Model Analysis Tool Formal Protocol Informal Protocol Description Find error Mur j code RFC Mur j code, similar for all protocols Specify security conditions and run Mur j

47. Secrecy  Intruder should not be able to learn the secret generated by the client ruleset i: ClientId do ruleset j: IntruderId do ruleset j: IntruderId do rule "Intruder has learned a client's secret" rule "Intruder has learned a client's secret" cli[i].state = M_DONE & cli[i].state = M_DONE & multisetcount(s: int[j].secretKeys, multisetcount(s: int[j].secretKeys, keyEqual(int[j].secretKeys[s], cli[i].secretKey)) > 0 keyEqual(int[j].secretKeys[s], cli[i].secretKey)) > 0 ==> ==> begin begin error "Intruder has learned a client's secret" error "Intruder has learned a client's secret" end; end; end;

48. Shared Secret Consistency  After the protocol has finished, client and server should agree on their shared secret ruleset i: ServerId do ruleset s: SessionId do ruleset s: SessionId do rule "Server's shared secret is not the same as its client's" rule "Server's shared secret is not the same as its client's" ismember(ser[i].clients[s].client, ClientId) & ismember(ser[i].clients[s].client, ClientId) & ser[i].clients[s].state = M_DONE & ser[i].clients[s].state = M_DONE & cli[ser[i].clients[s].client].state = M_DONE & cli[ser[i].clients[s].client].state = M_DONE & !keyEqual(cli[ser[i].clients[s].client].secretKey, !keyEqual(cli[ser[i].clients[s].client].secretKey, ser[i].clients[s].secretKey) ser[i].clients[s].secretKey) ==> ==> begin begin error "S's secret is not the same as C's" error "S's secret is not the same as C's" end; end; end;

49. Version and Crypto Suite Consistency  Client and server should be running the highest version of the protocol they both support ruleset i: ServerId do ruleset s: SessionId do ruleset s: SessionId do rule "Server has not learned the client's version or suite correctly" rule "Server has not learned the client's version or suite correctly" !ismember(ser[i].clients[s].client, IntruderId) & !ismember(ser[i].clients[s].client, IntruderId) & ser[i].clients[s].state = M_DONE & ser[i].clients[s].state = M_DONE & cli[ser[i].clients[s].client].state = M_DONE & cli[ser[i].clients[s].client].state = M_DONE & (ser[i].clients[s].clientVersion != MaxVersion | (ser[i].clients[s].clientVersion != MaxVersion | ser[i].clients[s].clientSuite.text != 0) ser[i].clients[s].clientSuite.text != 0) ==> ==> begin begin error "Server has not learned the client's version or suite correctly" error "Server has not learned the client's version or suite correctly" end; end; end;

50. Finite-State Verification... l Mur j rules for protocol participants and the intruder define a nondeterministic state transition graph l Mur j will exhaustively enumerate all graph nodes l Mur j will verify whether specified security conditions hold in every reachable node l If not, the path to the violating node will describe the attack Correctness condition violated

51. When Does Murj Find a Violation?  Bad abstraction Removed too much detail from the protocol when constructing the abstract model Removed too much detail from the protocol when constructing the abstract model Add the piece that fixes the bug and repeat Add the piece that fixes the bug and repeat This is part of the rational reconstruction process This is part of the rational reconstruction process  Genuine attack Yay! Hooray! Yay! Hooray! Attacks found by formal analysis are usually quite strong: independent of specific cryptographic schemes, OS implementation, etc. Attacks found by formal analysis are usually quite strong: independent of specific cryptographic schemes, OS implementation, etc. Test an implementation of the protocol, if available Test an implementation of the protocol, if available

52. “Core” SSL 3.0 C Version s =3.0, suite s, N s, sig ca (S,K s ), “ServerHelloDone” S C, Version c =3.0, suite c, N c {Secret c } Ks switch to key derived from secret c If the protocol is correct, C and S share some secret key material secret c at this point switch to key derived from secret c

53. Version Consistency Fails! C Version s =2.0, suite s, N s, sig ca (S,K s ), “ServerHelloDone” S C, Version c =2.0, suite c, N c {Secret c } Ks C and S end up communicating using SSL 2.0 (weaker earlier version of the protocol) Server is fooled into thinking he is communicating with a client who supports only SSL 2.0

54. struct { select (KeyExchangeAlgorithm) { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret; case rsa: EncryptedPreMasterSecret; case diffie_hellman: ClientDiffieHellmanPublic; case diffie_hellman: ClientDiffieHellmanPublic; } exchange_keys } exchange_keys } ClientKeyExchange struct { ProtocolVersion client_version; ProtocolVersion client_version; opaque random[46]; opaque random[46]; } PreMasterSecret A Case of Bad Abstraction Model this as {Version c, Secret c } Ks This piece matters! Need to add it to the model.

55. Fixed “Core” SSL C Version s =3.0, suite s, N s, sig ca (S,K s ), “ServerHelloDone” S C, Version c =3.0, suite c, N c {Version c,Secret c } Ks switch to key derived from secret c If the protocol is correct, C and S share some secret key material secret c at this point switch to key derived from secret c Prevents version rollback attack Add rule to check that received version is equal to version in ClientHello

56. Summary of Reconstruction  A = Basic protocol  C = A + certificates for public keys Authentication for client and serverAuthentication for client and server  E = C + verification (Finished) messages Prevention of version and crypto suite attacksPrevention of version and crypto suite attacks  F = E + nonces Prevention of replay attacksPrevention of replay attacks  Z = “Correct” subset of SSL

57. Anomaly (Protocol F) CS … Suite C … … Suite S … … Switch to negotiated cipher Finished data

58. Anomaly (Protocol F) CS … Suite C … … Suite S … … Switch to negotiated cipher Finished data X X Modify

59. Protocol Resumption CS SessionId, Ver C = 3.0, N C,... Finished data Ver S = 3.0, N S,...

60. Version Rollback Attack CS SessionId, Ver C = 2.0, N C,... Finished data Ver S = 2.0, N S,... X X { N S } SecretKey { N C } SecretKey SSL 2.0 Finished messages do not include version numbers or cryptosuites

61. Basic Pattern for Doing Your Project  Read and understand protocol specification Typically an RFC or a research paper Typically an RFC or a research paper We’ll put a few on the website: take a look! We’ll put a few on the website: take a look!  Choose a tool Murj by default, but we’ll describe many other tools Murj by default, but we’ll describe many other tools Play with Murj now to get some experience (installing, running simple models, etc.) Play with Murj now to get some experience (installing, running simple models, etc.)  Start with a simple (possibly flawed) model Rational reconstruction is a good way to go Rational reconstruction is a good way to go  Give careful thought to security conditions

62. Background Reading on SSL 3.0 Optional, for deeper understanding of SSL / TLS  D. Wagner and B. Schneier. “Analysis of the SSL 3.0 protocol.” USENIX Electronic Commerce ’96. Nice study of an early proposal for SSL 3.0 Nice study of an early proposal for SSL 3.0  J.C. Mitchell, V. Shmatikov, U. Stern. “Finite-State Analysis of SSL 3.0”. USENIX Security ’98. Mur  analysis of SSL 3.0 (similar to this lecture) Mur  analysis of SSL 3.0 (similar to this lecture) Actual Mur  model available Actual Mur  model available  D. Bleichenbacher. “Chosen Ciphertext Attacks against Protocols Based on RSA Encryption Standard PKCS #1”. CRYPTO ’98. Cryptography is not perfect: this paper breaks SSL 3.0 by directly attacking underlying implementation of RSA Cryptography is not perfect: this paper breaks SSL 3.0 by directly attacking underlying implementation of RSA