Chapter 5

11

Chapter 5

Transport Level Security

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)

33

► Subverting a Web server may provide a launching pad into the intranet

“Three-tier system”

44

Web Traffic Security Approaches

Web Security Threats - omit

Figure 5.1 Relative Location of Security Facilities in the TCP/IP Protocol Stack

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.

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

77

3.3 Establishing Encrypted Communications

First, establish TCP connection from client to port 443 on server

Secure channel established – proceed to use

88

99

1010

1111

1212

1313

1414Secure channel established

1515

3.3.1 ClientHello

Current versions: SSL 3.3, TLS 1.2

“Cookie”

Also used as a nonce to repel replay

attacks

1616

3.3.2 ServerHello

Server selects from menu

submitted by client

Server decides

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

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

1919

3.3.6 ChangeCipherSpec

2020

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

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.

2323

3.5 Authenticating the Server’s Identity –

continued

New: replaces ServerKeyExchange

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

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

2626

SSL Record Layer

443

2727Figure 5.2 SSL Protocol Stack

2828

4.1 Transport Requirements

2929

4.2 Record Layer

3030

3131

Figure 5.3 SSL Record Protocol Operations

3232

HTTP

3333

4.3 ChangeCipherSpec Protocol

Record Layer Header

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.

3535

Table 4.3 Alert Protocol Description

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

3737

Record Layer Header protocol = 22 decimal

In practice they are not!

Format of Handshake message

3838

3939

4040

4.5.2 ClientHello Record Layer Header protocol = 22

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

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!

4343

Client to server:

4444

4545

4.5.3 ServerHello

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:

4747

Server to client:

4848

4.5.4 Certificate

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:

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:

5151

4.5.7 ServerHelloDone

5252

The ServerHelloDone message is tacked on the end of the Certificate message.

Server to client:

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.

5454

4.5.8 ClientKeyExchange

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

5555

4.5.10 Finished

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:

57

Client to server:

5858

59

Server to client:

6060

4.6.3 Creating Cryptographic Parameters Where did the various keys come from?

Calculation of the Master Secret:

48 bytes

6161

We need this secret information

6262

Creation of the secret information

(key material)

TLS does this somewhat differently

6363

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.

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

6666

4.5.10 Finished

6767

4.6 Securing Messages (Application)

Figure 4-31 shows use of SHA as hash

Handshake finally over! Ready to do useful work.

6868

Application protocol data

(HTTP)

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.

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.

7171

End of SSL/TLS study

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

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)

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.

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)

7676

SSH Transport Layer roughly equivalent to SSL/TLS Record Layer

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

7878

Both sides know algorithms

At this point both sides compute keys

7979

Both sides know algorithms

Both sides compute keys

Service: User Authentication Protocol

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

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:

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

8383

8484

8585

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:

8787

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

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

9090

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!)

9292

9393There will be no authentication of the client host

machine – proceed to authenticate the human user.

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)

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?)

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.

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.

9898

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.

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.

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>

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>

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

104104

End of SSH material

End of Stallings’ Chapter 5