SENA PS810 User Manual
Page 59
59
To initiate SSL sessions, exchange of messages called the SSL handshake is required between two
devices (Server and Client). 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. The handshake allows the server to authenticate
itself to the client using public-key techniques, and 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. The details of handshake process step involved can be summarized as follows:
1.
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.
2.
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.
3.
The client uses some of the information sent by the server to authenticate the server. 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 next 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. SSL differ in the way this “shared” master secret
is created
5.
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.
6.
If the server has requested client authentication, the server attempts to authenticate the client.
If the client cannot be authenticated, the session is terminated. if the client can be successfully
authenticated, 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.
7.
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/TLS
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.
8.
The client sends a message to the server informing it that future messages from the client will