The Internet Encyclopedia (Volume 3)

P1: IML/FFX P2: IML/FFX QC: IML/FFX T1: IML

WL040C-21 WL040/Bidgolio-Vol I WL040-Sample.cls August 13, 2003 17:16 Char Count= 0

SSL ARCHITECTURE 267

Once a secure channel has been established the SSL

takes messages to be transmitted, fragments the message

into manageable blocks, optionally compresses the data,

applies a message authentication code (MAC), encrypts,

prefixes the SSL record header, and sends the result to

the TCP layer. Ultimately these data blocks are received

and the data are decrypted, verified, decompressed, re-

assembled in the receiver’s SSL layer, and then delivered

to higher level clients.

The technical details of these protocols are discussed

in a number of places. The primary document is the Web

page http://wp.netscape.com/eng/ssl3/ssl-toc.html.

There are a number of excellent secondary sources

that provide more background information as well as the

specifications of the protocols. The interested reader is

directed to Rescorla (2001) and Stallings (2000). The

protocols used to establish a secure channel give SSL its

flexibility for client/server communication.

SSL is flexible in the choice of which symmetric en-

cryption, message digest, and authentication algorithms

can be used. When an SSL client makes contact with

an SSL server, they agree upon the strongest encryption

methods they have in common. Also, SSL provides built-in

data compression. Data compression must be done before

encryption.

When an SSL connection is established, browser-to-

server and server-to-browser communications are en-

crypted. Encryption includes

URL of requested document

Contents of the document

Contents of browser forms

Cookies sent from browser to server

Cookies sent from server to browser

Contents of HTTP header, butnotparticular browser to

particular server.

In particular, socket addresses—IP address and port

number—are not encrypted; however, a proxy server can

be used if this type of privacy is required.

Connection Process

The connection process is shown in Figure 7. To establish

an SSL connection, the client (browser) opens a connec-

tion to a server port. The browser sends a “client hello”

message—Step 1. A client hello message contains the

version number of SSL the browser uses, the ciphers and

data compression methods it supports, and a random

number to be used as input to the key generation process.

The server responds with a “server hello” message—

Step 2. The server hello message contains a session ID

and the chosen versions for ciphers and data compres-

sion methods the client and server have in common.

The server sends its digital certificate—Step 3—which

is used to authenticate the server to the client and con-

tains the server’s public key. Optionally, the server may re-

quest a client’s certificate—Step 4. If requested, the client

will send its certificate of authentication—Step 5. If the

client has no certificate, then connection failure results.

Assuming a successful connection, the client sends a

1. Client sends ClientHello message


2. Server acknowledges with ServerHello message


3. Server sends its certificate


4. Server requests client's certificate (Optional)


5. Client sends its certificate (Optional)
   Client
   Certificate
   6. Client sends
   "ClientkeyExchange" message

Client

(Browser)

Server's

public key

Digital envelope

7. Client sends a "Certificate Verify" (Optional)

Digital signature

X

8. Both send "ChangeCiperSpec" messages
   9. Both send "Finished" messages

Session key

Server's private key

Server

Certificate

Server

Session Key

Figure 7: SSL connection process.

“ClientKeyExchange” message—Step 6. This message is a

digital envelope created using the server’s public key and

contains the session key chosen by the client. Optionally,

if client authentication is used, the client will send a cer-

tificate verify message—Step 7. The server and client send

a “ChangeCipherSpec” message—Step 8—indicating they

are ready to begin encrypted transmission. The client and

server send finished messages to each other—Step 9. The

finished messages are MACs of their entire conversation

up to this point. (Note: a MAC, message authentication

code, is a key-dependent one-way hash function. It has

the same properties as the one-way hash functions called

message digests but they have a key. Only someone with

the identical key can verify the hash value derived from

the message.) Accordingly, if the MACs match, then mes-

sages were exchanged without interference and, hence,

the connection is legitimate.

Once the secure channel is established, application-

level data can be transmitted between the client and server

using the SSL Record Protocol.

Record Protocol

The SSL Record Protocol provides two of the three es-

sential requirements for secure transmission of data:

confidentiality and message integrity. Confidentiality is

provided by symmetric encryption that uses the shared

session key exchanged between the client and server dur-

ing the handshake protocol. This handshake protocol also

defines a shared secret key that can be used to create a

message authentication code (MAC), which can be used