1. Transport Level Security
Chapter 5
Transport Level Security 1

2. 5.1 Web Security Considerations Web presents new challenges:
► Web is two-way, so servers can be attacked
► Organizations use Web as "store-front"
if compromised, money can be lost and reputation damaged
► Underlying software is complex,
and may hide many potential security flaws
► Subverting a Web server may provide
a launching pad into the intranet (next slide)
► Users are untrained and unaware of security risks 2

3. ► Subverting a Web server may provide
a launching pad into the intranet
“Three-tier system” 3

4. Web Security Threats - omit
Web Traffic Security Approaches
Figure 5.1 Relative Location of Security Facilities in the TCP/IP Protocol Stack 4

5. 5.2 Secure Socket Layer and Transport Layer Security
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
I did not find Stallings’ description of SSL easy to follow, so I am using the treatment by Stephen Thomas. 5

6. “SSL and TLS Essentials” by Stephen Thomas
Chapter 3: SSL Operation
3.1 SSL roles SKIM
3.2 SSL Messages SKIM
3.3 Establishing Encrypted Communications
3.3.1 ClientHello – OMIT compression methods p43
3.3.2 ServerHello
3.3.3 ServerKeyExchange
3.3.4 ServerHelloDone
3.3.5 ClientKeyExchange
3.3.6 ChangeCipherSpec
3.3.7 Finished
3.5 Authenticating the Server’s Identity
3.5.1 Certificate
3.5.2 ClientKeyExchange
omit rest of chapter
Start here 6

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

8. 8

9. 9

10. 10

11. 11

12. 12

13. 13

14. Secure channel established14

15. Current versions: SSL 3.3, TLS 1.2
3.3.1 ClientHello
Current versions: SSL 3.3, TLS 1.2
“Cookie”
Also used as a nonce to repel replay attacks 15

16. Server selects from menu submitted by client
3.3.2 ServerHello
Server decides
Server selects from menu submitted by client 16

17. Server has completed initial negotiation.
3.3.3 ServerKeyExchange
Server sends its public key; in section 3.5 this will be replaced by server sending its public-key certificate
3.3.4 ServerHelloDone
Server has completed initial negotiation.
3.3.5 ClientKeyExchange
Client generates “premaster secret,” and sends it encrypted with the server’s public key. Decrypting the premaster secret will verify that the server possesses the corresponding private key. Both sides can compute necessary keys.
3.3.6 Change Cipher Spec
Preliminary negotiations are complete and client tells server “I’m going to begin using the agreed cipher suite.” 17

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

19. 3.3.6 ChangeCipherSpec 19

20. 20

21. 3.3.7 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 hash 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.” 21

22. 3.5 Authenticating the Server’s Identity
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.
But just receiving a valid certificate is not enough -
It must be the right certificate!
The browser will also check this. 22

23. 3.5 Authenticating the Server’s Identity – continued
New: replaces ServerKeyExchange 23

24. Sends amazon.com certificate
Darth
Sends amazon.com certificate
3.5.2 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. 24

25. Chapter 4: Message Formats
4.1 Transport Requirements
4.2 Record Layer
4.3 ChangeCipherSpec Protocol
4.4 Alert Protocol
4.4.1 Severity Level
4.4.2 Alert Description
4.5 Handshake Protocol
4.5.2 ClientHello
4.5.3 ServerHello
4.5.4 Certificate
4.5.7 ServerHelloDone
4.5.8 ClientKeyExchange- include RSA only
Finished
4.6 Securing Messages
4.6.1 Message Authentication Code
4.6.2 Encryption
4.6.3 Creating Cryptographic Parameters3 25

26. 443
SSL Record Layer 26

27. Figure 5.2 SSL Protocol Stack27

28. 4.1 Transport Requirements28

29. 4.2 Record Layer 29

30. 30

31. Figure 5.3 SSL Record Protocol Operations31

32. HTTP 32

33. 4.3 ChangeCipherSpec Protocol
Record Layer Header 33

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

35. Table 4.3 Alert Protocol Description35

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

37. Format of Handshake message
Record Layer Header protocol = 22 decimal
In practice they are not! 37

38. 38

39. 39

40. Record Layer Header protocol = 22 4.5.2 ClientHello40

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

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

43. Client to server: 43

44. 44

45. 4.5.3 ServerHello 45

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, :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) 46

47. Server to client: 47

48. 4.5.4 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. CS 336/536 Lab #3: SSL/TLS
“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

51. 4.5.7 ServerHelloDone 51

52. Server to client:
The ServerHelloDone message is tacked on the end of the Certificate message. 52

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

54. 4.5.8 ClientKeyExchange
Chronologically, ChangeCipherSpec comes here, but it’s not part of the Handshake Protocol. 54

55. Finished 55

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

57. Client to server:

58. 58

59. Server to client:

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

61. We need this secret information61

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

63. 63

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

65. Keyed, not signed Return to 4.5.10 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 65

66. Finished 66

67. Handshake finally over! Ready to do useful work.
4.6 Securing Messages (Application)
Figure 4-31 shows use of SHA as hash 67

68. Application protocol data (HTTP)68

69. The inner and outer hash used here in SSL reminds us of HMAC (RFC 2104). This is slightly different, but TLS uses HMAC exactly. 69

70. 5.4 Transport Layer Security Protocol
We have been noting the (small) differences from SSL as we went along.
Interoperability of TLS 3.1 with SSL 3.0:
A client with capability for both should send the version 3.0 ClientHello message; if the server “understands” TLS 3.1 it will reply with the protocol version set to 3.1 and the rest of the exchange will be under TLS.
Similarly, if SSL version 2.0 is still a possibility, the client should send the version 2.0 ClientHello message. 70

71. End of SSL/TLS study 71

72. Stallings’ Section 5.5 Secure Shell (SSH)
Again, I did not find Stallings’ description easy to follow, so I am using the my own treatment (handout). 72

73. Secure Shell (SSH) 1. Remote Users
Both Telnet and FTP send passwords across the Internet
“in the clear.”
SSH and SFTP are secure replacements for Telnet and FTP
that protect passwords, and can even avoid use of them.
SSH has many similarities with SSL,
also some differences (next slides) 73

74. 2. Environments of SSH and SSL
Authentication of human user unnecessary.
User may not always use same client machine.
Authentication of human user vital. 74

75. 3. Preview of SSH operation
► limited authentication of server machine
► no authentication of client machine
► server will unquestioningly participate in establishing secure channel to any client machine
► careful human user authentication over secure channel
► several similarities with SSL handshaking (2 slides on) 75

76. SSH Transport Layer roughly equivalent to SSL/TLS Record Layer76

77. At this point both sides know algorithms
4. Transport Layer Protocol
SSH: TCP connection to port 22 established.
SSL: TCP connection to port 443 established.
At this point both sides know algorithms 77

78. At this point both sides compute keys
Both sides know algorithms
At this point both sides compute keys 78

79. Both sides know algorithms
Both sides compute keys
Service: User Authentication Protocol 79

80. Cookie Menu of cipher suites
SSH Protocol
SSH Version 2
Packet Length: 788
Padding Length: 8
Key Exchange
Msg code: Key Exchange Init (20)
Algorithms
Cookie: 8B21EDD188AFED7EC7FC499F65CD84C7
kex_algorithms length: 126
kex_algorithms string: diffie-hellman-group-exchange-sha256,
diffie-hellman-group-exchange-sha1,
diffie-hellman-group14-sha1,
diffie-hellman-group1-sha1
server_host_key_algorithms length: 15
server_host_key_algorithms string: ssh-rsa,ssh-dss
encryption_algorithms_client_to_server length: 157
encryption_algorithms_client_to_server string:
aes128-cbc,3des-cbc,blowfish-cbc, cast128-cbc,
arcfour128,arcfour256,arcfour,aes192-cbc,aes256-cbc,
aes128-ctr,aes192-ctr,
aes256-ctr
encryption_algorithms_server_to_client length: 157
encryption_algorithms_server_to_client string:
aes128-cbc,3des-cbc,blowfish-cbc,cast128-cbc,
mac_algorithms_client_to_server length: 105
mac_algorithms_client_to_server string: hmac-md5,
mac_algorithms_server_to_client length: 105
mac_algorithms_server_to_client string: hmac-md5,
compression_algorithms_client_to_server length: 26
compression_algorithms_client_to_server string:
compression_algorithms_server_to_client length: 26
compression_algorithms_server_to_client string:
languages_client_to_server length: 0
languages_server_to_client length: 0
Payload:
Padding String:
Cookie
Menu of cipher suites 80

81. In our lab the algorithms chosen are:
In the menus, algorithms are listed in order of preference Those chosen are the first ones on the client’s list that are also on the server’s list.
In our lab the algorithms chosen are:
Key exchange: diffie-hellman-group-exchange-sha256
Server host key: ssh-rsa
Symmetric encryption: aes128-cbc
MAC: hmac-md5
Compression: none 81

82. Recall Diffie-Hellman: Global parameters q, α
Key exchange method chosen: diffie-hellman-group-exchange-sha256
DH_GEX_REQUEST – client specifies a range of values for the modulus, q, and asks the server to choose
DH_GEX_GROUP – server responds with q, α to be used.
DH_GEX_INIT – client chooses its DH private key, computes its public key and sends it to server
DH_GEX_REPLY – server sends its DH public key, server’s host public signing key and signed hash of previous handshake messages. 82

83. 83

84. 84

85. 85

86. Much more on next slide! SSH Protocol SSH Version 2 Packet Length: 700
Padding Length: 10
Key Exchange
Msg code: Diffie-Hellman GEX Reply (33)
Payload: D
Padding String:
MAC String:
Much more on next slide! 86

87. 87

88. As seen in the previous slide our DH_GEX_REPLY message contains:
► Server’s DH public key
► Server’s host RSA public key
► SHA-256 hash H of the previous handshake messages,
signed by the server with its private host signing key.
H serves as the session identifier 88

89. This gives limited authentication of the server.
To authenticate the server, the client
► checks server’s public key against key in file known_hosts
(if this is the first contact, user is given option to risk proceeding)
► checks the server’s signature of the hash of previous handshake messages – agreement proves that the server has the RSA private key corresponding to its public host key
This gives limited authentication of the server.
Both participants compute the shared DH secret and combine it with hashes of the previous handshake messages to compute the various necessary keys 89

90. 90

91. ► remote terminal (SSH itself) ► file copy (SFTP) ► port forwarding
At this point the secure tunnel between the client host machine and the server machine has been established. Note again that there has been no authentication of the client host machine, and only limited authentication of the server host machine — no X.509 certificate has been provided and the client has been given the option of proceeding “on faith” during first contact with a particular server.
The above handshaking would be the same no matter what application the user had invoked SSH to execute; in our lab you will see
► remote terminal (SSH itself)
► file copy (SFTP)
► port forwarding
The client now sends the SERVICE_REQUEST message, specifying that it wishes to proceed to the User Authentication Protocol
The server responds with SERVICE_ACCEPT. Of course, these messages are authenticated and encrypted, so are opaque to eavesdroppers (such as you, using Wireshark in the lab!) 91

92. 92

93. There will be no authentication of the client host machine – proceed to authenticate the human user.93

94. 5. SSH User Authentication Three methods:
Everything so far in SSH has been part of the Transport Layer (analogous to SSL/TLS Record Layer)
The SSH user authentication protocol runs over the transport layer, making use of the secure tunnel that the transport layer has constructed.
5. SSH User Authentication
Three methods:
► trusted hosts – server lets client host machine authenticate user
(not an appealing option)
► user passwords – use for traveling salesperson
guesting on different machines
► public-key authentication of user 94

95. Public-key Authentication of User
In advance, a copy of the user’s public key is placed in the user’s home directory on the server (slight problem: how?)
To authenticate the user, the server generates a challenge, encrypts it with user’s public key and sends it to client; client decrypts the challenge with user’s private key, hashes it and returns hash to server, which checks the hash. Agreement proves that client has user’s private key. 95

96. The “public-key” method of user authentication is clearly superior to the password method. If you somehow discover another person’s password, the door is wide open to you. But even if you somehow discover another person’s passphrase, it is useless without the private key; conversely if you accidentally have access to somebody’s (encrypted) private key, it cannot be activated without the passphrase.
The SSH documentation states that the server automatically tries the authentication methods in the order:
►trusted-hosts
► user public-key
► user password.
Thus, if public-key authentication fails, the server should drop back and invite password authentication. You should be able to see this in the lab. 96

97. 6. SSH Connection Protocol
We have been engaged in necessary preliminaries – establishment of the secure tunnel and authentication of the user.
Now it’s time to move to useful work!
The SSH Connection Protocol is used to set up any number of logical channels through the tunnel.
There are various types of channel, the most obvious being one that carries a remote terminal stream.
Other types support port forwarding. 97

98. 98

99. In lab session #4 we’ll see this for Web browser ↔ Web server traffic.
7. “Port Forwarding”
Telnet passes textual information between client and server.
Although we introduced SSH as a secure replacement for telnet, once we have the secure tunnel established between SSH client and server, we can use it to carry any kind of data.
That is, SSH can be used to carry another application’s bidirectional data stream. SSH intercepts the service request and carries it and the response over the secure channel. The other application must be configured to use the SSH client (or server) as a proxy.
In lab session #4 we’ll see this for Web browser ↔ Web server traffic. 99

100. Local Forwarding is where the two clients are running on the same machine and the two servers on another machine. Here, the browser has been configured to use localhost:2001 as proxy; the SSH “forwards” this port, via port 22 on the server, to port 80 on the server.
100

101. IP datagrams arriving at port X1:2001 are forwarded to port X2:80
ssh -L2001:localhost: <IP address of X2>
IP datagrams arriving at port X1:2001 are forwarded to port X2:80
The full range of HTTP traffic (graphical, etc.) will be carried across the channel; a casual user will not be aware that the direct connection was not used.
101

102. Example of SSH Remote Port Forwarding
ssh –R2001:localhost:110
<IP address of user>
Traffic between POP3 client and POP3 server travels through the secure port forwarding channel
102

103. This figure covers both local and remote port forwarding.
Local: “SSH entity” on left is SSH client, on right is SSH server.
Remote: “SSH entity on the left is server, on right is client
103

104. End of Stallings’ Chapter 5
End of SSH material
End of Stallings’ Chapter 5
104