---------- Review SSL ---------- (0) Client establishes TCP connection with server (1) Client sends CLIENT HELLO - specifies version and supported cipher suites; also includes a random nonce, NONCE_CLIENT (28 bytes) - also includes session ID and compression method - e.g. cipher suites = TLS_RSA_WITH_RC4_128_MD5 TLS_RSA_WITH_RC4_128_SHA TLS_RSA_WITH_3DES_EDE_CBC_SHA TLS_RSA_WITH_DES_CBC_SHA ... (2) Server responds with SERVER HELLO - chooses a cipher suite, in our case: TLS_RSA_WITH_RC4_128_MD5 - also sends a random nonce, NONCE_SERVER (28 bytes) - also includes protocol version, session ID, compression method (3) Server sends SERVER HELLO DONE - includes server cert (4) the client authenticates the server - using the provided cert(s) (5) the client creates the PreMaster Secret, encrypts that with the server's public key then sends that to the server [assuming RSA] - this is the Key Exchange message - premaster secret might be 48 bytes: 1st 2 bytes are client version next 46 bytes are random bytes generated by the client (6) then both the client and server perform the same steps (in parallel) on the PreMaster Secret (PMS) in order to obtain the Master Secret - the server decrypts the PreMaster Secret, verifies that the first 2 bytes of this are the same client version as received in (1) - there are 3 inputs then used to generate the Master Secret: -- the NONCE_CLIENT, NONCE_SERVER, and the 46 random bytes of the PMS -- the use of both of the nonces prevents replay - these three inputs are fed into a PRF to obtain the key material, which is 48 bytes == 384 bits long -- divide those 384 bits into 3 128-bit long keys - one of which is used as the HMAC key - one of these is used as the RC4 key - and one is used is used as the IV for the symmetric algo as needed (7) then both the client and server generate session keys (in parallel) from the Master Secret; which in this case: - a key for RC4 (the stream cipher) which can be between 40 and 256 bits (5 bytes to 32 bytes) - a key for HMAC-MD5 should be between 128 and 512 bits --------------------------------------------------- Generating session keys from the Master Secret (DH) --------------------------------------------------- If the Master Secret is obtained via Diffie Hellman, i.e. g^ab then we might obtain the session keys via: K_BC = block cipher key = SHA-1( "1" || DH-secret ) K_MAC = MAC key = SHA-1( "2" || DH-secret ) SHA-1 output is 160 bits so truncate as necessary/desired... ===================== HMAC-MD5 construction ===================== The length of output for HMAC-MD5 is 16 bytes == 128 bits The length of output for HMAC-SHA is 20 bytes == 160 bits and the block byte length (in both cases) is 64 bytes. So the HMAC-MD5 key should be between 16 and 64 bytes. Calculating HMAC-MD5: HMAC_k( M ) = h( ( k || PAD_1 ) || h( k || PAD_2 || m ) ) ================= SSL communication ================= A = H_k1( m ) // using above, HMAC-MD5 C = E_k2( m || A ) // using RC4 (stream cipher) send C. ================================================ Notes about SSL regarding use w/mail sessions... ================================================ (1) If use RSA as pubkey algo instead of DH, then don't have perfect forward secrecy... that is, with RSA, if server's private key exposed, then one can review the logs of this SSL exchange and determine the master secret... thus being able to decrypt all communications Using Diffie Hellman, OTOH, means that even if server's private key exposed, observer still has to compute discrete logs modulo X ... in order to learn the master secret. I.e. computationally hard. (2) Entire SMTP session encrypted; that is, the MAIL From: RCPT To: etc. are ALL encrypted... vs. protocols that would only encrypt the body of the message (i.e. that sent via the DATA cmd). (3) But security is not end-to-end: that is, if I create a TLS session with my mail server, then the mail I send over that connection (and all details about it) are kept secret. However, if my mail server connects to the target domain's mail server and *does not use TLS for this connection*, then the contents of my mail may be learned by a passive observer. Similarly if that mail server doesn't perform TLS for the POP connection the recipient makes to that mail server, also exposed. Me +++ TLS conn +++ my SMTP Server X X X (SMTP conn) X X relay MTA for destination domain X X X (SMTP conn) X X local MTA for destination domain X X X (POP conn probably) X X target recipient Where the +++ denote protected connections and the XXX denote connections that I have no control over... if that relay MTA (for the destination domain) doesn't support TLS, the contents sent over that connection may be sent in the clear. Likewise for the connection between the recipient and his local MTA etc. ===================================== Key Exchange VARIATIONS and Specifics ===================================== (1) RSA, as above: client sends PreMaster Secret encrypted with server's pub key (2) RSA, with temp RSA pair (presumably provides forward secrecy, assuming temp pair discarded immediately) - server generates temp RSA (pubKey,privKey) pair; sends temp pubKey to client - signed using server's long-term RSA (priv) key - client sends PMS encrypted using server's *temp* pub key (3) Fixed Diffie Hellman (4) Anonymouse Diffie Hellman (5) Ephemeral Diffie Hellman ++++++++++ References ++++++++++ (1) Description of SSL Handshake http://support.microsoft.com/kb/257591 (2) [RFC 2104] HMAC: Keyed-Hashing for Message Authentication http://www.ietf.org/rfc/rfc2104.txt (3) [RFC 2246] The TLS Protocol, Version 1.0 http://www.rfc-editor.org/rfc/rfc2246.txt (4) An Introduction to OpenSSL, Part Four: The SSL and TLS Protocols http://www.securityfocus.com/infocus/1486 (5) Chapter 14, TLS http://www.montefiore.ulg.ac.be/~leduc/cours/ISIR/ISIR-chap14.pdf (6) SSL: Foundation for Web Security, by William Stallings http://www.cisco.com/web/about/ac123/ac147/archived_issues/ipj_1-1/ssl.html (7) RSALabs: What is Diffie Hellman? http://www.rsasecurity.com/rsalabs/node.asp?id=2248