Re: At which stage of the SSL handshake client/server 'decides' strenght of encryption ?

2

"Marlon Brown" <nomail@xxxxxxxxx> wrote in message
news:%23va9$6tFGHA.1032@xxxxxxxxxxxxxxxxxxxxxxx
> 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.
>
>


.

Relevant Pages

  • Re: SSL/TLS & renegotiation and Internet Explorer
    ... When IE closes the connection with the server and prompts the user to choose ... recovery logic the SSL session is discarded. ... If the user only has one suitable client certificate, ...
    (microsoft.public.security)
  • Re: RDP Printing by station
    ... flagged as non-printing stations can not print for ANY users. ... multiple NIC's on the terminal server. ... I'd then just have to ensure that the client stations that are ... session is limited to NIC # 1. ...
    (microsoft.public.windows.terminal_services)
  • Re: A cryptography solution for a client/server winforms app
    ... good idea if you want to learn crypto. ... you control both the client and server, you don't even need to use a ... code the client to ignore certificate trust errors. ... encrypt the memory stream. ...
    (microsoft.public.dotnet.security)
  • Re: What doesnt lend itself to OO?
    ... >> proxy and instructs the server to constuct the real object. ... rather than client code. ... If 'clock' is instantiated in the server, ... > for the server interface at the OOA level. ...
    (comp.object)
  • Re: File ENcryption Problem Detail
    ... > In addition, when u encrypt remotely (client to server), which users ... We can encrypt remotely (client to server, ... >>> it is able to encrypt file locally on the DC, ...
    (microsoft.public.win2000.security)