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
270 SECURESOCKETSLAYER(SSL)may respond with aFatalHandshakeFailurealert if client
authentication is required.
Step 6is theClientKeyExchangemessage. The con-
tent of the message will be based on the type of key ex-
change negotiated during the first phase of the handshak-
ing process. The key exchange method is determined by
the cipher suite selected and server certificate type. For
example if the client and server agree upon the RSA key
exchange method then the client generates a 48-bytepre-
mastersecretand encrypts it with the public key from the
server’s certificate or uses the temporary public key from
the server’sServerKeyExchangemessage.
If the server has requested a client certificate and it
requires verification then the client will send aCertificat-
eVerifymessage to provide explicit verification of its client
certificate.
InStep 8the client sends aChangeCipherSpecmessage
that indicates the client has switched to the negotiated ci-
pher suit. All subsequent messages will be sent using those
encryption algorithms and appropriate keys. It should
be noted that theChangeCipherSpecmessage is a sepa-
rate protocol and not part of the Handshake protocol.
The purpose of this is to make SSL and TLS more effi-
cient. TheChangeCipherSpecmessage consists of only one
byte.
InStep 9the client sends the handshake messageFin-
ish. The message is a concatenation of two message digest
values. Each value is computed using a different message
digest algorithm—MD5 and SHA—on the same data. The
data are the master secret (see below) and the set of hand-
shake messages sent up to this point.
In response to these two client messages the server
sends its version of theChangeCipherSpecand aFinished
message computer using that same data as the client. If
thisFinishedmessage value differs from theFinishedmes-
sage value sent by the client then this indicates that the
handshake has been modified and secure channel my not
be setup. When the client receives thefinishmessage from
the server it does a comparison with its locally computed
finishmessage value. If they match then all is well; other-
wise the secure channel may not be established.Cipher Suites and Master Secrets
There are two more concepts that need to be presented to
complete this discussion. In Step 1 above the client sends
a list of cipher suites to the server that the client is able to
use. In Step 6 the client sends a premastersecret that will
be used to compute the master secret. This master secret is
then used to compute the keyblock. This keyblock is used
to derive the keys that will be used with the algorithms
specified in the cipher suites. The details of each of these
need to presented.Cipher Suites
A cipher suite is a list of key exchange techniques and cryp-
tographic algorithms supported by the client and server.
Theciphersuiteparameter of theClientHellomessage
provides a set of key exchange techniques, server authen-
tication algorithms, bulk encryption algorithms, and mes-
sage digest algorithms the client can support. The client
lists these sets in order of the client’s preference. Forexample, one of the entries of this set may beTLSDHERSAWITH3DESEDECBCSHAIn this example the key exchange technique is DHE,
where DHE denotes ephemeral Diffie–Hellman. The
Diffie–Hellman parameters are signed by a DSS or RSA
certificate, which has been signed by the certificate au-
thority (CA). The signing algorithm used is specified after
the DHE parameter. In this case the signing algorithm is
the RSA (Rivest, Shamir, Adelman) algorithm.
The bulk encryption and message digest algorithms fol-
low the WITH delimiter. In this the bulk encryption is
performed by 3DESEDECBC, where 3DESEDECBD
denotes 3DES encryption using the encrypt–decrypt–
encrypt mode in the cipher block chaining mode, and the
message digest algorithm is SHA, where SHA denotes the
secure hash algorithm.Master Secret
The master secret creation is the vital component in set-
ting up the secure channel. The master secret is used to
compute the keyblock. Once the keyblock computed it
is partitioned into six keys that are used by the client and
server in their communications. The computation of the
keyblock is as follows.
TheClientKeyExchangemessage provides the server
with the premastersecret. The client and server use this
48-byte value along with theClientHellorandom param-
eter value andServerHellorandom parameter value (they
both have copies of these) to create a hash value by us-
ing the MD5 and SHA algorithms in the same sequence
on this common set of values. They will both compute
the identical hash value. This value is the master secret
that is shared (computed) by both. A similar process is
used to compute the keyblock but instead of using the
premastersecret in the computation the mastersecret
is used. This results in a keyblock that is “shared,” com-
puted independently but to the same value, by the client
and server.
The size of the keyblock is determined by the cipher
specifications. These specifications give the number of
bytes required for the bulk encryption keys (i.e., one for
the client to use and one for the server to use), MAC keys,
and if necessary initialization vector keys. Initialization
vectors (IV) are necessary if a bulk encryption algorithm
will be using the cipher block chaining mode.
This “shared” keyblock is partitioned in the same
sequence by the client and server. The first set of bytes
are used in the client MAC secret, the next set are used
for the server MAC secret, the next set are used for the
client bulk encryption key, the next set for the server bulk
encryption key, the next set of bytes for the client initial-
ization vector, and finally the last set of bytes will be used
as the server’s initialization vector.STATUS OF SSL
SSLv3 and TLS 1.0 and Commercial Use
SSL and TLS are primarily used to protect Web traffic that
is using HTTP. In order for this to occur both the client
and the server need to be SSL- and /or TLS-enabled.