chapter 5 n.
Skip this Video
Loading SlideShow in 5 Seconds..
Chapter 5 PowerPoint Presentation
Download Presentation
Chapter 5

Loading in 2 Seconds...

play fullscreen
1 / 104

Chapter 5 - PowerPoint PPT Presentation

  • Uploaded on

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.

I am the owner, or an agent authorized to act on behalf of the owner, of the copyrighted work described.
Download Presentation

PowerPoint Slideshow about 'Chapter 5' - britanni-oliver

An Image/Link below is provided (as is) to download presentation

Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author.While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server.

- - - - - - - - - - - - - - - - - - - - - - - - - - E N D - - - - - - - - - - - - - - - - - - - - - - - - - -
Presentation Transcript
chapter 5

Chapter 5

Transport Level Security



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



► Subverting a Web server may provide

a launching pad into the intranet

“Three-tier system”



Web Security Threats - omit

Web Traffic Security Approaches

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



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.



“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



3.3 Establishing Encrypted Communications

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

Secure channel established – proceed to use



3.3.1 ClientHello

Current versions: SSL 3.3, TLS 1.2


Also used as a nonce to repel replay attacks



3.3.2 ServerHello

Server decides

Server selects from menu submitted by client



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



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



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



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



3.5 Authenticating the Server’s Identity –


New: replaces ServerKeyExchange




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



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

4.5.10 Finished

4.6 Securing Messages

4.6.1 Message Authentication Code

4.6.2 Encryption

4.6.3 Creating Cryptographic Parameters3




SSL Record Layer



4.3 ChangeCipherSpec Protocol

Record Layer Header



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.



4.5 Handshake Protocol


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




Format of Handshake message

Record Layer Header protocol = 22 decimal

In practice they are not!



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)


gmt_unix_time: Oct 10, 2008 10:54:18.000000000



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!



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

Version: TLS 1.0 (0x0301)


gmt_unix_time: Oct 10, 2008 11:00:13.000000000



Session ID Length: 32

Session ID: 77987B601B5544C111C3FCB1DF96F7A8970D1EFD39630F3F...

Cipher Suite: TLS_RSA_WITH_RC4_128_MD5 (0x0004)

Compression Method: null (0)



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 (,

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



CS 336/536 Lab #3: SSL/TLS

“Certificate” message from 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


Server to client:

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



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.



4.5.8 ClientKeyExchange

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



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)

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



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

Calculation of the Master Secret:

48 bytes



Creation of the secret information (key material)

TLS does this somewhat differently



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.



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



Handshake finally over! Ready to do useful work.

4.6 Securing Messages (Application)

Figure 4-31 shows use of SHA as hash



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



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.



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



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)



2. Environments of SSH and SSL

Authentication of human user unnecessary.

User may not always use same client machine.

Authentication of human user vital.



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)



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



Both sides know algorithms

At this point both sides compute keys



Both sides know algorithms

Both sides compute keys

Service: User Authentication Protocol



SSH Protocol

SSH Version 2

Packet Length: 788

Padding Length: 8

Key Exchange

Msg code: Key Exchange Init (20)


Cookie: 8B21EDD188AFED7EC7FC499F65CD84C7

kex_algorithms length: 126

kex_algorithms string: diffie-hellman-group-exchange-sha256,




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,


encryption_algorithms_server_to_client length: 157

encryption_algorithms_server_to_client string:



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: 0000000000

Padding String:


Menu of cipher suites



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



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.



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:

Much more on next slide!



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



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



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



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



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



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.



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:


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



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.



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.



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.



ssh -L2001:localhost:80 <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.



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



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



End of SSH material

End of Stallings’ Chapter 5