Java Reference
In-Depth Information
produces a public certiicate. When a user connects to the Web application/Web site, the
public certiicate is provided to the browser during the handshake process. he certiicate
contains details of the Web site/Web application that the certiicate has been issued for, the
organization name, certiicate serial number, the class of certiicate, the certiicate provider,
and the dates of validity of the certiicate.
Step 1—Client initiation:
Client initiates a SSL/TLS request that includes the SSL version
and list of supported cipher suites. his step is usually referred to as
ClientHello
in the SSL/
TLS parlance. he cipher suite information also includes cryptographic algorithms and key
sizes. For instance, TLS_RSA_WITH_RC4_128_MD5 is a cipher suite. he algorithm
used for key exchange and certiicate veriication is the RSA algorithm. he encryption
algorithm used for encrypting messages in this case is the RC4. he MD5 algorithm is used
to verify the contents of message.
Step 2—Server acknowledgment:
Upon the receipt of the client request, the server chooses
the highest version of SSL/TLS and the best-suited cipher suite that both the client and server
support and returns this information to the client. his step is referred to as
ServerHello
in
the SSL/TLS parlance.
Step 3—Send certiicate:
Optionally, the server sends the client a certiicate (or even a cer-
tiicate chain). In case a certiicate chain is being sent, it begins with the server's public
key certiicate and ends with the certiicate authority's root certiicate. his step becomes
essential if the server requires authentication. his step is referred to as
certiicate
in the SSL/
TLS parlance.
Step 4—Request certiicate:
his is an optional step. However, if Step 3 is mandated due
to authentication requirement, then the server needs to authenticate the client and it sends
the client a certiicate request. his step is referred to as
certiicate request
in the SSL/TLS
parlance.
Step5—Server key exchange:
he server sends the client a server key exchange message when
the public key information sent in Step 3 above is not suicient for key exchange.
Step 6—Server ready:
Now the server indicates to the client that its initial negotiation mes-
sages have been successfully completed. his step is referred to as
ServerHello Done
in the
SSL/TLS parlance.
Step 7—Send certiicate:
If the server had requested a certiicate from the client, as in Step 4,
the client sends its certiicate chain, just as the server did in Step 3. his step is referred to as
certiicate
in the SSL/TLS parlance.
Step 8—Client key exchange:
he client will generate information used to create a key to use
for symmetric encryption. For RSA, the client then encrypts this key information with the
server's public key and sends it to the server.
Step 9—Certiicate veriication:
his message is sent when a client presents a certiicate as
described in Step 7, and this is optional, as it depends on Step 3. Its purpose is to allow the
server to complete the process of authenticating the client. When this message is used, the
client sends information that it digitally signs using a cryptographic hash function. When
the server decrypts this information with the client's public key, the server will be able to
authenticate the client.
Step 10—Change cipher spec:
In this step, the client sends a message indicating to the server
to change to an encrypted mode.
Step 11—Handshake establishment on server side:
In this step, the client intimates to the
server that it is ready for secure data communication to begin.
Search WWH ::
Custom Search