The SSL Handshake Approach for Internet Security

February 12, 2019

The SSL protocol uses a combination of public-key and symmetric key encryption. Symmetric key encryption is much faster than public-key encryption, but public-key encryption provides better authentication techniques.

An SSL session always begins with an exchange of messages called the SSL handshake.

The handshake allows the server to authenticate itself to the client using public-key techniques, then allows the client and the server to cooperate in the creation of symmetric keys used for rapid encryption,

decryption, and tamper detection during the session that follows. Optionally,

the handshake also allows the client to authenticate itself to the server.

The exact programmatic details of the messages exchanged during the SSL handshake are beyond the scope of this document.

However, the steps involved can be summarized as follows (assuming the use of the cipher suites listed in Cipher Suites with RSA Key Exchange):

The client sends the server the client’s SSL version number, cipher settings, randomly generated data, and other information the server needs to communicate with the client using SSL.

The server sends the client the server’s SSL version number, cipher settings, randomly generated data, and other information the client needs to communicate with the server over SSL. The server also sends its own certificate and, if the client is requesting a server resource that requires client authentication, requests the client’s certificate.

The client uses some of the information sent by the server to authenticate the server (see Server Authentication for details). If the server cannot be authenticated, the user is warned of the problem and informed that an encrypted and authenticated connection cannot be established. If the server can be successfully authenticated, the client goes on to StepĀ 4.

Using all data generated in the handshake so far, the client (with the cooperation of the server, depending on the cipher being used) creates the premaster secret for the session, encrypts it with the server’s public key (obtained from the server’s certificate, sent in StepĀ 2), and sends the encrypted premaster secret to the server.

If the server has requested client authentication (an optional step in the handshake), the client also signs another piece of data that is unique to this handshake and known by both the client and server. In this case the client sends both the signed data and

the client’s own certificate to the server along with the encrypted premaster secret.

If the server has requested client authentication, the server attempts to authenticate the client (see Client Authentication for details). If the client cannot be authenticate, the session is terminate. Then If the client can be successfully authenticate,
the server uses its private key to decrypt the premaster secret, then performs a series of steps
(which the client also performs, starting from the same premaster secret) to generate the master secret.

Both the client and the server use the master secret to generate the session keys, which are symmetric keys used to encrypt and decrypt information exchanged during the SSL session and to verify its integrity–that is, to detect any changes in the data between the time it was sent and the time it is received over the SSL connection.

The client sends a message to the server informing it that future messages from the client will be encrypted with the session key. It then sends a separate (encrypt) message indicating that the client portion of the handshake is finish.

The server sends a message to the client informing it that future messages from the server will be encrypted with the session key. It then sends a separate (encrypt) message indicating that the server portion of the handshake is finish.

The SSL handshake is now complete, and the SSL session has begun. The client and the server use the session keys to encrypt and decrypt the data they send to each other

and to validate its integrity.

Before continuing with the session, Netscape servers can be configured to check that the client’s certificate is present in the user’s entry in an LDAP directory. This configuration option provides one way of ensuring that the client’s certificate has not been revoked.

It’s important to note that both client and server authentication involve encrypting some piece of data

with one key of a public-private key pair and decrypting it with the other key:

In the case of server authentication, the client encrypts the premaster secret with the server’s public key. Only the corresponding private key can correctly decrypt the secret,

so the client has some assurance that the identity associated

with the public key is in fact the server with which the client is connecting. Otherwise,

the server cannot decrypt the premaster secret and cannot generate the symmetric keys required for the session,

and the session will be terminate.

In the case of client authentication,

the client encrypts some random data with the client’s private key–that is,

it creates a digital signature. The public key in the client’s certificate can correctly validate

the digital signature only if the corresponding private key is using. Otherwise,

the server cannot validate the digital signature and the session is terminate.