At which stage of the SSL handshake client/server 'decides' strenght of encryption ?
- From: "Marlon Brown" <nomail@xxxxxxxxx>
- Date: Wed, 11 Jan 2006 10:42:16 -0800
Browsers, web servers and operating systems play in a role in determining
the level of encryption to be used during a session.
Do you know at which stage it is determined whether it is 40 bit, 56 bit or
128-bit ? Reading the the SSL handshake steps from www.microsoft.com that
was not clear to me...
MORE INFORMATION
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
public key (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.
.
- Follow-Ups:
- Prev by Date: Re: User Rights In Active Directory
- Next by Date: Re: Can 128-bit TripleDES encryption be broken ?
- Previous by thread: Re: User Rights In Active Directory
- Next by thread: Re: At which stage of the SSL handshake client/server 'decides' strenght of encryption ?
- Index(es):
Relevant Pages
|
