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 269

Table 1Handshake Protocol Messages

Message Type Parameters

HelloRequest Null

ClientHello Version, random,

sessionid, ciphersuite,

compressionmethod

Serverhello Version, random, sessionid,

ciphersuite,

compressionmethod

Certificate Chain of X.509v3 certificates

ServerKeyExchange Parameters, signatures

CertificateRequest Type, authorities

ServerDone Null

CertificateVerify Signature

ClientKeyExchange Parameters, signatures

Finished Hashvalue

of day the message was generated and the remaining

28 bytes are created using a secure random number

generator. This 32-byte value will be used as one of the

inputs to the key generation procedure. The time stamp

(first four bytes) prevents a possible man-in-the-middle

attack.

sessionidThe ID of a session the client wishes to use

for this connection. This parameter will beemptyif no

sessionid is available or the client wishes to generate

new security parameters.

ciphersuitesA list of the cryptographic options sup-

ported by the client, sorted descending preferences. If

the sessionid field is notempty(implying a session re-

sumption request) this vector must include at least the

ciphersuite from that session.

compressionmethodsA list of the compression meth-

ods supported by the client, sorted by client prefer-

ence. If the sessionid field is notempty(implying a

session resumption request) this vector must include

at least the compression method from that session.

All implementations must support a. null compression

method (i.e., no data compression is used).

After sending theClientHellomessage, the client waits

for aServerHellomessage. Any other handshake message

returned by the server except for aHelloRequestis treated

as a fatal error.

Step 2is theServerHellomessage. The server pro-

cesses theClientHellomessage and responds with either

a handshakefailurealertor aServerHellomessage. The

ServerHellomessage parameters are

serverversionThis field will contain the lower of that

suggested by the client in the ClientHellomessage and

the highest supported by the server.

randomThis structure is generated by the server and

mustbe different from (and independent of ) theClient-

Hellorandom structure.

sessionidThis is the identity of the session correspond-

ing to this connection. If theClientHellomessage ses-

sionid parameter was nonempty, the server will look

in its session cache for a match. If a match is found

and the server is willing to establish the new con-

nection using the specified session state, the server

will respond with the same value as was supplied by

the client. This indicates aresumedsession and dic-

tates that the partiesmustproceed directly to thefin-

ishedmessages. Otherwise this field will contain a dif-

ferent value identifying the new session. The server

may return anemptysessionid to indicate that the

session will not be cached and therefore cannot be

resumed.

ciphersuiteThe single cipher suite selected by the server

from the list in theClientHellomessage ciphersuites

parameter. Forresumedsessions this field is the value

from the state of the session being resumed.

compressionmethodThe single compression algorithm

selected by the server from the list in the Client-

Hellomessage compressionmethods parameter. For

resumedsessions this field is the value from the re-

sumed session state.

Step 3is theCertificatemessage. If the server is to

be authenticated (which is generally the case), the server

sends its certificate immediately following the ServerHello

message. The certificate type must be appropriate for the

selected cipher suite’s key exchange algorithm, and is gen-

erally an X.509.v3 certificate. The same message type is

also used for the client’s response to a server’sCertifi-

cateRequestmessage.

If the server has no certificate or if a key exchange tech-

nique other than RSA or fixed Diffie–Hellman is used the

server will sendServerKeyExchangemessage. In this case

the parameters for this message will contain the values ap-

propriate for the key exchange technique, see (Stallings,

2000) for these details.

InStep 4(optional), a nonanonymous server can op-

tionally request a certificate from the client, if appropriate

for the selected cipher suite. TheCertificateRequestmas-

sage has two parameters. These are

typesA list of the types of certificates requested, sorted in

order of the server’s preference.

authoritiesA list of the distinguished names of acceptable

certificate authorities.

AfterStep 3(or optionalStep 4) the server will send

aServerHelloDonemessage to indicate that the server has

sent all the handshake messages necessary for the server

hello phase. After sending this message the server will wait

for a client response. When the client receives theServer-

HelloDonemessage the client will determine the validity of

the server’s certificate and the acceptability of theServer-

Hellomessage parameters. If the parameters and certifi-

cate are valid then the client will one or two messages.

Step 5(optional) is theCertificatemessage. This is

the first message the client can send after receiving a

ServerHelloDonemessage. This message is only sent if

the server requests a certificate. If no suitable certificate

is available, the client should send aNoCertificatealert

instead. This error is only a warning, however the server