PrepAway - Latest Free Exam Questions & Answers

In an SSL session between a client and a server, who is…

In an SSL session between a client and a server, who is responsible for generating the master secret that will
be used as a seed to generate the symmetric keys that will be used during the session?

PrepAway - Latest Free Exam Questions & Answers

A.
Both client and server

B.
The client’s browser

C.
The web server

D.
The merchant’s Certificate Server

Explanation:
This is a tricky question. The client generates the “pre-master” secret. See step 4 of the process below.
However, the master secret that will be used as a seed to generate the symmetric keys is generated (from the
pre-master secret) by both the client and server. See step 6 below.
The steps involved in the SSL handshake are as follows (note that the following steps assume the use of the
cipher suites listed in Cipher Suites with RSA Key Exchange: Triple DES, RC4, RC2, DES):
1. The client sends the server the client’s SSL version number, cipher settings, session-specific data, and
other information that the server needs to communicate with the client using SSL.
2. The server sends the client the server’s SSL version number, cipher settings, session-specific data, and
other information that 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, the server
requests the client’s certificate.
3. The client uses 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 proceeds to step 4.
4. Using all data generated in the handshake thus far, the client (with the cooperation of the server, depending
on the cipher being used) creates the pre-master secret for the session, encrypts it with the server’s publickey (obtained from the server’s certificate, sent in step 2), and then sends the encrypted pre-master secret
to the server.
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
pre-master secret.
6. If the server has requested client authentication, the server attempts to authenticate the client (see Client
Authentication for details). If the client cannot be authenticated, the session ends. If the client can be
successfully authenticated, the server uses its private key to decrypt the pre-master secret, and then
performs a series of steps (which the client also performs, starting from the same pre-master 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 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 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 with 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 session begins. 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.
11.This is the normal operation condition of the secure channel. At any time, due to internal or external stimulus
(either automation or user intervention), either side may renegotiate the connection, in which case, the
process repeats itself.
Incorrect Answers:
B: The client generates the “pre-master” secret, not the “master secret”. The master secret that will be used as
a seed to generate the symmetric keys is generated (from the pre-master secret) by both the client and server.
C: The master certificate is not generated by the web server alone; the client also generates the master secret.
D: The merchant’s Certificate Server does not generate the master secret.

https://support.microsoft.com/en-us/kb/257591


Leave a Reply