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

2. Course Admin Mid-term HW/Lab 3 posted Labs active this Friday
Graded; scores posted; to be returned today
Solution was provided ( ed)
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

3. 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

4. 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., (IMAP, SMTP), FTP
12/5/2018
Lecture 7 - SSL/TLS

5. 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

6. 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

7. 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

8. 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

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

10. 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

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

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

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

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

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

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

17. Secure channel established17

18. 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

19. 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

20. 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

21. 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

22. ChangeCipherSpec 22

23. 23

24. 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

25. 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

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

27. 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

28. 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

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

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

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

32. 32

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

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

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

36. 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

37. Alert Protocol Description37

38. 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

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

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

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

42. Record Layer Header protocol = 22 ClientHello42

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

44. 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, :54:
random_bytes:
751AB9DCEBF3014D799038D27E24E6409C8397FE6E1A
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

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

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

47. 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, :00:
random_bytes:
C7B2A2F58454A2C2A0DE667781E C86C8FF724069E...
Session ID Length: 32
Session ID: 77987B601B5544C111C3FCB1DF96F7A8970D1EFD39630F3F...
Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)
Compression Method: null (0) 47

48. Certificate 48

49. 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=
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

50. Example
“Certificate” message from Amazon.com contains a chain of public key certificates:
Certificate #1:
Issued to:
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

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

52. 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

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

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

55. 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

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

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

58. We need this secret information

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

61. 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

62. 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

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

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

65. 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

66. 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

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

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