chapter 5
DESCRIPTION
Chapter 5. Transport Level Security. 1. 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. - PowerPoint PPT PresentationTRANSCRIPT
![Page 1: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/1.jpg)
11
Chapter 5
Transport Level Security
![Page 2: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/2.jpg)
22
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
► Users are untrained and unaware of security risks
► Subverting a Web server may provide a launching pad into the intranet (next slide)
![Page 3: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/3.jpg)
33
► Subverting a Web server may provide a launching pad into the intranet
“Three-tier system”
![Page 4: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/4.jpg)
44
Web Traffic Security Approaches
Web Security Threats - omit
Figure 5.1 Relative Location of Security Facilities in the TCP/IP Protocol Stack
![Page 5: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/5.jpg)
55
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.
![Page 6: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/6.jpg)
66
“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 Communications3.3.1 ClientHello – OMIT compression methods p433.3.2 ServerHello3.3.3 ServerKeyExchange3.3.4 ServerHelloDone3.3.5 ClientKeyExchange3.3.6 ChangeCipherSpec3.3.7 Finished
3.5 Authenticating the Server’s Identity3.5.1 Certificate3.5.2 ClientKeyExchange
omit rest of chapter
Start here
![Page 7: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/7.jpg)
77
3.3 Establishing Encrypted Communications
First, establish TCP connection from client to port 443 on server
Secure channel established – proceed to use
![Page 8: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/8.jpg)
88
![Page 9: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/9.jpg)
99
![Page 10: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/10.jpg)
1010
![Page 11: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/11.jpg)
1111
![Page 12: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/12.jpg)
1212
![Page 13: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/13.jpg)
1313
![Page 14: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/14.jpg)
1414Secure channel established
![Page 15: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/15.jpg)
1515
3.3.1 ClientHello
Current versions: SSL 3.3, TLS 1.2
“Cookie”
Also used as a nonce to repel replay
attacks
![Page 16: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/16.jpg)
1616
3.3.2 ServerHello
Server selects from menu
submitted by client
Server decides
![Page 17: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/17.jpg)
1717
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.”
![Page 18: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/18.jpg)
1818
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.”
![Page 19: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/19.jpg)
1919
3.3.6 ChangeCipherSpec
![Page 20: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/20.jpg)
2020
![Page 21: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/21.jpg)
2121
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.”
![Page 22: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/22.jpg)
2222
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.
But just receiving a valid certificate is not enough -
It must be the right certificate!
The browser will also check 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.
![Page 23: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/23.jpg)
2323
3.5 Authenticating the Server’s Identity –
continued
New: replaces ServerKeyExchange
![Page 24: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/24.jpg)
2424
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.
Darth
Sends amazon.com certificate
![Page 25: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/25.jpg)
2525
Chapter 4: Message Formats
4.1 Transport Requirements
4.2 Record Layer
4.3 ChangeCipherSpec Protocol
4.4 Alert Protocol4.4.1 Severity Level4.4.2 Alert Description
4.5 Handshake Protocol4.5.2 ClientHello4.5.3 ServerHello4.5.4 Certificate4.5.7 ServerHelloDone4.5.8 ClientKeyExchange- include RSA only4.5.10 Finished
4.6 Securing Messages4.6.1 Message Authentication Code4.6.2 Encryption4.6.3 Creating Cryptographic Parameters3
![Page 26: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/26.jpg)
2626
SSL Record Layer
443
![Page 27: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/27.jpg)
2727Figure 5.2 SSL Protocol Stack
![Page 28: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/28.jpg)
2828
4.1 Transport Requirements
![Page 29: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/29.jpg)
2929
4.2 Record Layer
![Page 30: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/30.jpg)
3030
![Page 31: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/31.jpg)
3131
Figure 5.3 SSL Record Protocol Operations
![Page 32: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/32.jpg)
3232
HTTP
![Page 33: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/33.jpg)
3333
4.3 ChangeCipherSpec Protocol
Record Layer Header
![Page 34: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/34.jpg)
3434
4.4 Alert Protocol
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.
![Page 35: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/35.jpg)
3535
Table 4.3 Alert Protocol Description
![Page 36: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/36.jpg)
3636
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 keyEncryption keyIV
![Page 37: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/37.jpg)
3737
Record Layer Header protocol = 22 decimal
In practice they are not!
Format of Handshake message
![Page 38: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/38.jpg)
3838
![Page 39: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/39.jpg)
3939
![Page 40: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/40.jpg)
4040
4.5.2 ClientHello Record Layer Header protocol = 22
![Page 41: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/41.jpg)
4141There are more of these in SSL; TLS removes some and adds others.
![Page 42: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/42.jpg)
4242
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 Version: TLS 1.0 (0x0301) 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!
![Page 43: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/43.jpg)
4343
Client to server:
![Page 44: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/44.jpg)
4444
![Page 45: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/45.jpg)
4545
4.5.3 ServerHello
![Page 46: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/46.jpg)
4646
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 Version: TLS 1.0 (0x0301) 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)
Server to client:
![Page 47: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/47.jpg)
4747
Server to client:
![Page 48: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/48.jpg)
4848
4.5.4 Certificate
![Page 49: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/49.jpg)
4949
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
Secure Socket Layer TLSv1 Record Layer: Handshake Protocol: Server Hello Done Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 4 Handshake Protocol: Server Hello Done Handshake Type: Server Hello Done (14) Length: 0
Server to client:
![Page 50: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/50.jpg)
50
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
CS 336/536 Lab #3: SSL/TLS
“Certificate” message from Amazon.com contains a chain of public key certificates:
![Page 51: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/51.jpg)
5151
4.5.7 ServerHelloDone
![Page 52: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/52.jpg)
5252
The ServerHelloDone message is tacked on the end of the Certificate message.
Server to client:
![Page 53: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/53.jpg)
5353
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.
![Page 54: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/54.jpg)
5454
4.5.8 ClientKeyExchange
Chronologically, ChangeCipherSpec comes here, but it’s not part of the Handshake Protocol.
![Page 55: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/55.jpg)
5555
4.5.10 Finished
![Page 56: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/56.jpg)
5656
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) Version: TLS 1.0 (0x0301) Length: 1 Change Cipher Spec Message
TLSv1 Record Layer: Handshake Protocol: Encrypted Handshake Message Content Type: Handshake (22) Version: TLS 1.0 (0x0301) Length: 32 Handshake Protocol: Encrypted Handshake Message
The 3 messages from the client:
![Page 57: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/57.jpg)
57
Client to server:
![Page 58: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/58.jpg)
5858
![Page 59: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/59.jpg)
59
Server to client:
![Page 60: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/60.jpg)
6060
4.6.3 Creating Cryptographic Parameters Where did the various keys come from?
Calculation of the Master Secret:
48 bytes
![Page 61: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/61.jpg)
6161
We need this secret information
![Page 62: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/62.jpg)
6262
Creation of the secret information
(key material)
TLS does this somewhat differently
![Page 63: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/63.jpg)
6363
![Page 64: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/64.jpg)
6464
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.
Review: repeat of a previous slide:
We need to have an agreed test message.
![Page 65: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/65.jpg)
6565
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:
TLS uses a slightly different hash calculation.
Inner and outer hash remind us of HMAC
Keyed, not signed
![Page 66: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/66.jpg)
6666
4.5.10 Finished
![Page 67: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/67.jpg)
6767
4.6 Securing Messages (Application)
Figure 4-31 shows use of SHA as hash
Handshake finally over! Ready to do useful work.
![Page 68: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/68.jpg)
6868
Application protocol data
(HTTP)
![Page 69: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/69.jpg)
6969
The inner and outer hash used here in SSL reminds us of HMAC (RFC 2104).
This is slightly different, but TLS uses HMAC exactly.
![Page 70: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/70.jpg)
7070
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.
![Page 71: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/71.jpg)
7171
End of SSL/TLS study
![Page 72: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/72.jpg)
7272
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).
![Page 73: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/73.jpg)
7373
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 FTPthat protect passwords, and can even avoid use of them.
SSH has many similarities with SSL, also some differences (next slides)
![Page 74: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/74.jpg)
7474
2. Environments of SSH and SSL
Authentication of human user unnecessary.
Authentication of human user
vital.
User may not always use same client machine.
![Page 75: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/75.jpg)
7575
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)
![Page 76: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/76.jpg)
7676
SSH Transport Layer roughly equivalent to SSL/TLS Record Layer
![Page 77: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/77.jpg)
7777
SSH: TCP connection to port 22 established.
SSL: TCP connection to port 443 established.
At this point both sides know algorithms
4. Transport Layer Protocol
![Page 78: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/78.jpg)
7878
Both sides know algorithms
At this point both sides compute keys
![Page 79: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/79.jpg)
7979
Both sides know algorithms
Both sides compute keys
Service: User Authentication Protocol
![Page 80: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/80.jpg)
8080
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,[email protected], 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,arcfour128,arcfour256,arcfour,aes192-cbc,aes256-
cbc,[email protected],aes128-ctr,aes192-
ctr,aes256-ctr mac_algorithms_client_to_server length: 105 mac_algorithms_client_to_server string: hmac-md5,
hmac-sha1,[email protected],hmac-ripemd160,
[email protected],hmac-sha1-96,hmac-md5-96
mac_algorithms_server_to_client length: 105 mac_algorithms_server_to_client string: hmac-md5,
hmac-sha1,[email protected],hmac-ripemd160,
[email protected],hmac-sha1-96,hmac-md5-96
compression_algorithms_client_to_server length: 26 compression_algorithms_client_to_server string:
none,[email protected],zlib compression_algorithms_server_to_client length: 26 compression_algorithms_server_to_client string:
none,[email protected],zlib languages_client_to_server length: 0 languages_server_to_client length: 0 Payload: 0000000000 Padding String:
Cookie
Menu of cipher suites
![Page 81: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/81.jpg)
8181
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.
Key exchange: diffie-hellman-group-exchange-sha256
Symmetric encryption: aes128-cbc
MAC: hmac-md5
Compression: none
Server host key: ssh-rsa
In our lab the algorithms chosen are:
![Page 82: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/82.jpg)
8282
Recall Diffie-Hellman:
DH_GEX_REQUEST – client specifies a range of values for the modulus, q, and asks the server to
choose
Global parameters q, α
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.
Key exchange method chosen: diffie-hellman-group-exchange-sha256
![Page 83: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/83.jpg)
8383
![Page 84: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/84.jpg)
8484
![Page 85: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/85.jpg)
8585
![Page 86: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/86.jpg)
8686
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: 00000115000000077373682D727361000000012300000101... Padding String: MAC String:
![Page 87: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/87.jpg)
8787
![Page 88: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/88.jpg)
8888
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
![Page 89: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/89.jpg)
8989
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
![Page 90: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/90.jpg)
9090
![Page 91: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/91.jpg)
9191
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!)
![Page 92: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/92.jpg)
9292
![Page 93: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/93.jpg)
9393There will be no authentication of the client host
machine – proceed to authenticate the human user.
![Page 94: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/94.jpg)
9494
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
The SSH user authentication protocol runs over the transport layer, making use of the secure tunnel that the transport layer has constructed.
Everything so far in SSH has been part of the Transport Layer (analogous to SSL/TLS Record Layer)
![Page 95: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/95.jpg)
9595
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.
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?)
![Page 96: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/96.jpg)
9696
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.
![Page 97: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/97.jpg)
9797
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.
![Page 98: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/98.jpg)
9898
![Page 99: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/99.jpg)
9999
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.
![Page 100: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/100.jpg)
100100
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.
![Page 101: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/101.jpg)
101101
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.
IP datagrams arriving at port X1:2001 are forwarded to port X2:80
ssh -L2001:localhost:80 <IP address of X2>
![Page 102: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/102.jpg)
102102
Example of SSH Remote Port Forwarding
Traffic between POP3 client and POP3 server travels through the secure port forwarding channel
ssh –R2001:localhost:110
<IP address of user>
![Page 103: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/103.jpg)
103103
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
![Page 104: Chapter 5](https://reader035.vdocuments.mx/reader035/viewer/2022070401/56813660550346895d9dee83/html5/thumbnails/104.jpg)
104104
End of SSH material
End of Stallings’ Chapter 5