Serial Port Configuration
61
Model 2285 Getting Started Guide
4 • Serial port configuration
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 con-
nection 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 integ-
rity—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 be encrypted
with the session key. It then sends a separate (encrypted) message indicating that the client portion of the
handshake is finished.
9. The server sends a message to the client informing it that future messages from the server will be encrypted
h the session key. It then sends a separate (encrypted) message indicating that the server portion of the
handshake is finished.
10. The SSL handshake is now complete, and the SSL session has begun. The client and the server use the ses-
sion keys to encrypt and decrypt the data they send to each other and to validate its integrity.
