Understanding SSL/TLS: Architecture, Handshake Protocol, and Key Negotiation

1. SSL/TLS (ch 19) IT443 – Network Security Administration Instructor: Bo Sheng

2. What Layer? Application Application Appl. SSL TCP TCP IPSec OS IP IP LAN layer LAN layer

3. History • SSLv2 proposed and deployed in Netscape 1.1 (1995) • PCT (Private Communications Technology) by Microsoft • SSLv3: most commonly used (1995) • was developed with public review • TLS proposed by the IETF based on SSLv3 but not compatible (1996) • Uses patent free DH and DSS instead of RSA which patent didn’t expire yet

4. SSL vs. IPsec • SSL: • Avoids modifying “TCP stack” and requires minimum changes to the application • Mostly used to authenticate servers • IPsec • Transparent to the application and requires modification of the network stack • Authenticates network nodes and establishes a secure channel between nodes • Application still needs to authenticate the users

5. SSL Architecture HTTP and other applications SSLHandshakeProtocol SSLChange CipherProtocol SSLAlertProtocol SSLAPI SSL Record Protocol TCP IP … Relies on TCP for reliable communication

6. SSL Architecture • Handshake protocol: establishment of a session key • Change Cipher protocol: start using the previously-negotiated encryption / message authentication • Alert protocol: notification (warnings or fatal exceptions) • Record protocol: protected (encrypted, authenticated) communication between client and server

7. Connections and Sessions • SSL Session • an association between peers • created through a handshake, negotiates security parameters, can be long-lasting • SSL Connection • a type of service (i.e., an application) between a client and a server • transient • Multiple connections can be part of a single session

8. Basic Protocols • Goal: application independent security • Originally for HTTP, but now used for many applications • Each application has an assigned TCP port, e.g., https (HTTP over SSL) uses port 443 • Messages • A -> B: I want to talk, ciphers I support, RA • B -> A: certificates, cipher I choose, RB • A -> B: {S}B, {keyed hash of handshake msgs} • B -> A: {keyed hash of handshake msgs} • A <-> B: data encrypted and integrity checked with keys derived from K • Keyed hashes use K = f(S, RA, RB)

9. Basic Protocols • How do you make sure that keyed hash in message 3 is different from B’s response? • Include a constant CLNT/client finished (in SSL/TLS) for A and SRVR/server finished for B • Keyed hash is sent encrypted and integrity protected for no real reason • Keys: derived by hashing K and RAand RB • 3 keys in each direction: encryption, integrity and IV • Write keys (to send: encrypt, integrity protect) • Read keys (to receive: decrypt, integrity check)

10. Session Resumption • Many secure connections can be derived from the session • Cheap: how? • Session initiation: modify message 2 • B -> A: session_id, certificate, cipher, RB • Aand B remember: (session_id, master key) • To resume a session: A presents the session_id in message 1 • A -> B: session_id, ciphers I support, RA • B -> A: session_id, cipher I choose, RB, {keyed hash of handshake msgs} • A -> B: {keyed hash of handshake msgs} • A <-> B: data encrypted and integrity checked with keys derived from K

11. Negotiating Cipher Suites • A cipher suite is a complete package: • (encryption algorithm, key length, integrity checksum algorithm, etc.) • Cipher suites are predefined: • Each assigned a unique value (contrast with IKE) • SSLv2: 3 bytes, SSLv3: 2 bytes => up to 65000 combinations • 30 defined, • 256 reserved for private use: FFxx (risk of non-interoperability) • Selection decision: • In v3 A proposes, B chooses • In v2 A proposes, B returns acceptable choices, and A chooses • Suite names examples: • SSL_RSA_EXPORT_WITH_DES40_CBC_SHA • SSL2_RC4_128_WITH_MD5

12. SSL Record Protocol

13. Protocol Steps • Fragment data stream into records • each with a maximum length of 214 (=16K) bytes • Compress each record • Create message authentication code for each record • Encrypt each record

14. Protocol Steps Application Data Fragment Compress Add MAC Encrypt Add SSL Hdr

15. SSL Record Format RecordType SSL Version PayloadLength • There is, unfortunately, some version number silliness between v2 and v3; see text for (ugly) details Application Data(optionally compressed) Encrypted Optional MAC (16 or 20 bytes)

16. SSL Handshake Protocol

17. Phases of Protocol • Establish security capabilities • version of SSL to use • cipher + parameters to use • Authenticate server (optional), and perform key exchange • Authenticate client (optional), and perform key exchange • Finish up

18. All the Messages

19. I. Establish Security Capabilities • Messages marked with * are mandatory Client Server Client_Hello* Server_Hello*

20. Client_Hello Message • Transmitted in plaintext • Contents • highest SSL version understood by client • RC: a 4-byte timestamp + 28-byte random number • session ID: 0 for a new session, non-zero for a previous session • list of supported cryptographic algorithms • list of supported compression methods

21. Server_Hello Message • Also transmitted in plaintext • Contents • minimum of (highest version supported by server, highest version supported by client) • RS: 4-byte timestamp and 28-byte random number • session ID • a cryptographic choice selected from the client’s list • a compression method selected from the client’s list

22. II. Server Auth. / Key Exchange Client Server • The Server_Certificate message is optional, but almost always used in practice Server_Certificate Server_Key_Exchange Client_Certificate_Request Server_Handshake_Done*

23. Server_Certificate Message • Contains a certificate with server’s public key, in X.509 format • or, a chain of certificates if required • The server certificate is necessary for any key exchange method except for anonymous Diffie-Hellman

24. Authenticating the Server • Step #4: Domain name in certificate must match domain name of server (not part of SSL protocol, but clients should check this) source: sun.com

25. Client_Certificate_Request Msg. • Normally not used, because in most applications • only the server is authenticated • client is authenticated at the application layer, if needed • Two parameters • certificate type accepted, e.g., RSA/signature only, DSS/signature only, … • list of certificate authorities recognized (i.e., trusted third parties)

26. III. Client Auth. / Key Exchange Client Server Client_Certificate Client_Key_Exchange* Client_Certificate_Verify

27. Client_Certificate_Verify Msg • Proves the client is the valid owner of a certificate (i.e., knows the corresponding private key) • Only sent following any client certificate that has signing capability

28. IV. Finish Up Client Server Change_Cipher_Spec* Client_Finished* Change_Cipher_Spec* Server_Finished* Switch to the negotiated cipherfor all remaining (application)messages

29. Change_Cipher_Spec Msg • Confirms the change of the current state of the session to a newly-negotiated set of cryptographic parameters • Finished Messages • keyed hash of the previous handshake messages to prevent man-in-the-middle-attacks from succeeding

30. Alert Protocol Examples • Type 1: Warning • ex.: No_Certificate, Close_Notify • Type 2: Fatal_Alert • ex.: Unexpected_Message, Bad_MAC, etc. • connection is immediately terminated

31. Summary • SSL is the de facto authentication/encryption protocol standard for HTTP • becoming popular for many other protocols as well • Allows negotiation of cryptographic methods and parameters