Lecture 8: Transport Level Security – SSL/TLS CS 336/536: Computer Network Security Fall 2015 Nitesh Saxena Adopted from previous lecture by Tony Barnard

Course Admin Mid-term HW/Lab 3 posted Labs active this Friday Graded; scores posted; to be returned today Solution was provided (emailed) HW/Lab 3 posted Covers Lecture 8 (SSL/TLS) Due Nov 16 Lab exercise involves capturing SSL/TLS packets using Wireshark Labs active this Friday Questions? 12/5/2018 Lecture 7 - SSL/TLS

Outline SSL/TLS Protocol Messages and Message Formats Secure Data Exchange Exposition borrowed from Stephen Thomas (a book solely focusing on SSL) 12/5/2018 Lecture 7 - SSL/TLS

SSL: Secure Sockets Layer Widely deployed security protocol Supported by almost all browsers and web servers https Tens of billions $ spent per year over SSL Originally designed by Netscape in 1993 Number of variations: TLS: transport layer security, RFC 2246 Provides Confidentiality Integrity Authentication Original goals: Had web e-commerce transactions in mind Encryption (especially credit-card numbers) Web-server authentication Optional client authentication Minimum hassle in doing business with new merchant Available to all TCP applications Not just web e.g., email (IMAP, SMTP), FTP 12/5/2018 Lecture 7 - SSL/TLS

SSL in Action Let us see some examples… HTTPS: HTTP over SSL (or TLS) Gmail (uses SSL) Wells fargo (uses SSL) Blazernet (uses SSL) Uab (no SSL) HTTPS: HTTP over SSL (or TLS) Typically on port 443 (regular http on port 80) 12/5/2018 Lecture 7 - SSL/TLS

Relative Location of Security Facilities in the TCP/IP Protocol Stack Which Layer to Add Security to? Relative Location of Security Facilities in the TCP/IP Protocol Stack 12/5/2018 Lecture 7 - SSL/TLS 6

SSL and TLS SSL 2.0 was developed and patented by Netscape in 1994. TLS is the non-proprietary Internet standard development (RFC 2246, 1999) TLS 1.0 was an upgrade of SSL 3.0, so TLS 1.0 is sometimes referred to as SSL 3.1 Latest standard is TLS 1.2, sometimes referred to as SSL 3.3 12/5/2018 Lecture 7 - SSL/TLS 7

SSL Main Components Handshake Negotiation of protocol algorithms, versions and parameters Authentication of communicating parties Agreement of session keys Secure Session Communication 12/5/2018 Lecture 7 - SSL/TLS 8

1 or more SSL Record Layer units 443 1 or more SSL Record Layer units 12/5/2018 Lecture 7 - SSL/TLS 9

Secure channel established – proceed to use Establishing Secure Communications First, establish TCP connection from client to port 443 on server Secure channel established – proceed to use 10

12/5/2018 Lecture 7 - SSL/TLS 11

12/5/2018 Lecture 7 - SSL/TLS 12

12/5/2018 Lecture 7 - SSL/TLS 13

12/5/2018 Lecture 7 - SSL/TLS 14

12/5/2018 Lecture 7 - SSL/TLS 15

12/5/2018 Lecture 7 - SSL/TLS 16

Secure channel established 17

Current versions: SSL 3.3, TLS 1.2 ClientHello Current versions: SSL 3.3, TLS 1.2 Also used as a nonce to repel replay attacks 12/5/2018 Lecture 7 - SSL/TLS 18

Server selects from menu submitted by client ServerHello Server decides Server selects from menu submitted by client 12/5/2018 Lecture 7 - SSL/TLS 19

Server sends its public key certificate ServerKeyExchange Server sends its public key certificate ServerHelloDone Server has completed initial negotiation. ClientKeyExchange Client generates “premaster secret,” and sends it encrypted with the server’s public key. Server decrypts the premaster secret using the corresponding private key. Both sides can compute necessary keys. Change Cipher Spec Preliminary negotiations are complete and client tells server “I’m going to begin using the agreed cipher suite.” 20

ChangeCipherSpec “Since the transition to secured communication is critical, and both sides have to get it exactly right, the SSL specification is very precise in describing the process.” “The SSL specification also recognizes that some of the information (in particular, the key material) will be different for each direction of communication. In other words, one set of keys will secure data the client sends to the server, and a different set of keys will secure data the server sends to the client.” “For a given system, whether it is a client or a server, SSL defines a write state and a read state. The write state defines the security information for data that the system sends, and the read state defines the security information for data that the system receives.” 12/5/2018 Lecture 7 - SSL/TLS 21

ChangeCipherSpec 22

23

Finished “Immediately after sending their ChangeCipherSpec messages, each system sends a Finished message. The Finished messages allow both systems to verify that negotiation has been successful and that security has not been compromised. Two aspects of the Finished message contribute to this security.” “First … the Finished message itself is subject to the negotiated cipher suite … If the receiving party cannot successfully decrypt and verify the message, then clearly something has gone awry with the security negotiation.” “The contents of the Finished message also serves to protect the security of the SSL negotiation. Each Finished message contains a cryptographic keyed hash (MAC) of important information about the just-finished negotiation … This protects against an attacker who manages to insert fictitious messages into, or remove legitimate messages from, the communication.” 12/5/2018 Lecture 7 - SSL/TLS 24

Authenticating the Server By now in this course we’re familiar with the need to authenticate the server’s identity. In the usual situation in which SSL is deployed (ordering from Amazon.com) we do not need to authenticate the client – SSL has an option to do so, but we will skip this. No surprise: we will insist on the server sending the client an X.509 certificate – browser will automatically check validity, using its library of CA public keys. 12/5/2018 Lecture 7 - SSL/TLS 25

Authenticating the Server’s Identity – continued New: replaces ServerKeyExchange 12/5/2018 Lecture 7 - SSL/TLS 26

Sends amazon.com certificate Darth Sends amazon.com certificate ClientKeyExchange Encryption of the “pre-master secret” with the public key sent in the Certificate message means that the server must actually possess the corresponding private key to decrypt the pre-master secret. Both sides can compute necessary keys. 27

Message Formats Transport Requirements Record Layer ChangeCipherSpec Protocol Alert Protocol Severity Level Alert Description Handshake Protocol ClientHello ServerHello Certificate ServerHelloDone ClientKeyExchange- include RSA only Finished Securing Messages Message Authentication Code Encryption Creating Cryptographic Keys 28

1 or more SSL Record Layer units 443 1 or more SSL Record Layer units 12/5/2018 Lecture 7 - SSL/TLS 29

Transport Requirements 12/5/2018 Lecture 7 - SSL/TLS 30

Record Layer 12/5/2018 Lecture 7 - SSL/TLS 31

32

Figure 5.3 SSL Record Protocol Operations 12/5/2018 Lecture 7 - SSL/TLS 33

HTTP 12/5/2018 Lecture 7 - SSL/TLS 34

ChangeCipherSpec Protocol Record Layer Header 12/5/2018 Lecture 7 - SSL/TLS 35

The Alert Protocol signals an error. Some error messages are cautionary, others fatal. TLS removes some of the error categories in SSL and adds some new ones. 12/5/2018 Lecture 7 - SSL/TLS 36

Alert Protocol Description 37

1. negotiate cipher suite to be used ClientHello message Handshake Protocol Purposes: 1. negotiate cipher suite to be used ClientHello message ServerHello message 2. authenticate I/D of server Certificate message ClientKeyExchange message 3. generate collection of shared secret information Premaster secret (ClientKeyExchange) Master secret Keying material MAC key Encryption key IV 38

Format of Handshake message Record Layer Header protocol = 22 In practice they are not! 12/5/2018 Lecture 7 - SSL/TLS 39

12/5/2018 Lecture 7 - SSL/TLS 40

12/5/2018 Lecture 7 - SSL/TLS 41

Record Layer Header protocol = 22 ClientHello 42

There are more of these in SSL; TLS removes some and adds others. 43

Client can handle up to TLS 1.0 (SSL 3.1) Secure Socket Layer TLSv1 Record Layer: Handshake Protocol: Client Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 92 Handshake Protocol: Client Hello Handshake Type: Client Hello (1) Length: 88 Random gmt_unix_time: Oct 10, 2008 10:54:18.000000000 random_bytes: 751AB9DCEBF3014D799038D27E24E6409C8397FE6E1A7553... Session ID Length: 0 Cipher Suites Length: 24 Cipher Suites (12 suites) Cipher Suite: TLS_DHE_RSA_WITH_AES_256_CBC_SHA (0x0039) Cipher Suite: TLS_DHE_DSS_WITH_AES_256_CBC_SHA (0x0038) Cipher Suite: TLS_RSA_WITH_AES_256_CBC_SHA (0x0035) Cipher Suite: TLS_DHE_RSA_WITH_AES_128_CBC_SHA (0x0033) Cipher Suite: TLS_DHE_DSS_WITH_AES_128_CBC_SHA (0x0032) Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Cipher Suite: TLS_RSA_WITH_RC4_128_SHA (0x0005) Cipher Suite: TLS_RSA_WITH_AES_128_CBC_SHA (0x002f) Cipher Suite: TLS_DHE_RSA_WITH_3DES_EDE_CBC_SHA (0x0016) Cipher Suite: TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (0x0013) Cipher Suite: SSL_RSA_FIPS_WITH_3DES_EDE_CBC_SHA (0xfeff) Cipher Suite: TLS_RSA_WITH_3DES_EDE_CBC_SHA (0x000a) Compression Methods Length: 1 Compression Methods (1 method) Compression Method: null (0) Client can handle up to TLS 1.0 (SSL 3.1) Remarkable range of capabilities in browser! 44

12/5/2018 Lecture 7 - SSL/TLS 45

ServerHello 12/5/2018 Lecture 7 - SSL/TLS 46

Server to client: Secure Socket Layer TLSv1 Record Layer: Handshake Protocol: Server Hello Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 74 Handshake Protocol: Server Hello Handshake Type: Server Hello (2) Length: 70 Random gmt_unix_time: Oct 10, 2008 11:00:13.000000000 random_bytes: C7B2A2F58454A2C2A0DE667781E2773544C86C8FF724069E... Session ID Length: 32 Session ID: 77987B601B5544C111C3FCB1DF96F7A8970D1EFD39630F3F... Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004) Compression Method: null (0) 47

Certificate 48

Server to client: Secure Socket Layer TLSv1 Record Layer: Handshake Protocol: Certificate Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 2468 Handshake Protocol: Certificate Handshake Type: Certificate (11) Length: 2464 Certificates Length: 2461 Certificates (2461 bytes) Certificate Length: 1271 Certificate (id-at-commonName=www.amazon.com, Certificate Length: 1184 Certificate (id-at-commonName=VeriSign Class 3 Secure Server CA TLSv1 Record Layer: Handshake Protocol: Server Hello Done Length: 4 Handshake Protocol: Server Hello Done Handshake Type: Server Hello Done (14) Length: 0 49

Example “Certificate” message from Amazon.com contains a chain of public key certificates: Certificate #1: Issued to: www.amazon.com Issuer: VeriSign Class 3 Secure Server CA Certificate #2: Issued to: VeriSign Class 3 Secure Server CA Issuer: VeriSign Class 3 Public Primary Certification Authority 12/5/2018 Lecture 7 - SSL/TLS

ServerHelloDone 12/5/2018 Lecture 7 - SSL/TLS 51

Both sides know algorithms, client generates “pre-master secret” and can use it to compute all necessary keys (session key, MAC key). Client encrypts pre-master secret with server public key and sends. Server has received encrypted pre-master secret, decrypts with its private key and uses pre-master secret to compute all necessary keys. Both sides know all keys. 52

ClientKeyExchange Chronologically, ChangeCipherSpec comes here, but it’s not part of the Handshake Protocol. 12/5/2018 Lecture 7 - SSL/TLS 53

Finished 12/5/2018 Lecture 7 - SSL/TLS 54

The 3 messages from the client: Secure Socket Layer TLSv1 Record Layer: Handshake Protocol: Client Key Exchange Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 134 Handshake Protocol: Client Key Exchange Handshake Type: Client Key Exchange (16) Length: 130 TLSv1 Record Layer: Change Cipher Spec Protocol: Change Cipher Spec Content Type: Change Cipher Spec (20) Length: 1 Change Cipher Spec Message TLSv1 Record Layer: Handshake Protocol: Encrypted Handshake Message Length: 32 Handshake Protocol: Encrypted Handshake Message 12/5/2018 Lecture 7 - SSL/TLS 55

12/5/2018 Lecture 7 - SSL/TLS 56

Calculation of the Master Secret: Creating Cryptographic Parameters Where did the various keys come from? Calculation of the Master Secret: 48 bytes 57

We need this secret information

Creation of the secret information (key material) TLS does this somewhat differently

We need to have an agreed test message. Review: repeat of a previous slide: Both sides know algorithms, client generates “pre-master secret” and can use it to compute all necessary keys (session key, IV, MAC key). Client encrypts pre-master secret with server public key and sends. Server receives encrypted pre-master secret, decrypts with its private key and uses pre-master secret to compute all necessary keys. Then both sides have computed identical keys. We need to have an agreed test message. 61

Keyed, not signed Return to Finished “Finished” message carries the agreed test message, MD5 and SHA hashes of the previous handshake messages. Here’s the SHA: Inner and outer hash remind us of HMAC TLS uses a slightly different hash calculation. Keyed, not signed 62

Finished 12/5/2018 Lecture 7 - SSL/TLS 63

Handshake finally over! Ready to do useful work. Securing Messages (Application) 64

The inner and outer hash used here in SSL reminds us of HMAC (RFC 2104). This is slightly different, but TLS uses HMAC exactly. 12/5/2018 Lecture 7 - SSL/TLS 65

Session Resumption Full handshake is expensive: CPU time and amount of communication If the client and server have already communicated once, they can skip handshake and proceed directly to data transfer For a given session, client and server store session_id, master_secret, negotiated ciphers Client sends session_id in ClientHello Server then agrees to resume in ServerHello New key_block computed from master_secret and client and server random numbers

Fun/Info bit: SSL Heartbleed 12/5/2018 Lecture 7 - SSL/TLS

Further Reading SSL and TLS Essentials, Stephen Thomas Stallings Chapter 6 12/5/2018 Lecture 7 - SSL/TLS