- Provide security parameters to the record layer.

     - Allow the client and server to verify that their peer has
       calculated the same security parameters and that the handshake
       occurred without tampering by an attacker.

   Note that higher layers should not be overly reliant on TLS always
   negotiating the strongest possible connection between two peers:
   there are a number of ways a man in the middle attacker can attempt
   to make two entities drop down to the least secure method they
   support. The protocol has been designed to minimize this risk, but
   there are still attacks available: for example, an attacker could
   block access to the port a secure service runs on, or attempt to get
   the peers to negotiate an unauthenticated connection. The fundamental
   rule is that higher levels must be cognizant of what their security
   requirements are and never transmit information over a channel less
   secure than what they require. The TLS protocol is secure, in that
   any cipher suite offers its promised level of security: if you
   negotiate 3DES with a 1024 bit RSA key exchange with a host whose
   certificate you have verified, you can expect to be that secure.





 
RFC 2246              The TLS Protocol Version 1.0          January 1999


   However, you should never send data over a link encrypted with 40 bit
   security unless you feel that data is worth no more than the effort
   required to break that encryption.

   These goals are achieved by the handshake protocol, which can be
   summarized as follows: The client sends a client hello message to
   which the server must respond with a server hello message, or else a
   fatal error will occur and the connection will fail. The client hello
   and server hello are used to establish security enhancement
   capabilities between client and server. The client hello and server
   hello establish the following attributes: Protocol Version, Session
   ID, Cipher Suite, and Compression Method. Additionally, two random
   values are generated and exchanged: ClientHello.random and
   ServerHello.random.

   The actual key exchange uses up to four messages: the server
   certificate, the server key exchange, the client certificate, and the
   client key exchange. New key exchange methods can be created by
   specifying a format for these messages and defining the use of the
   messages to allow the client and server to agree upon a shared
   secret. This secret should be quite long; currently defined key
   exchange methods exchange secrets which range from 48 to 128 bytes in
   length.

   Following the hello messages, the server will send its certificate,
   if it is to be authenticated. Additionally, a server key exchange
   message may be sent, if it is required (e.g. if their server has no
   certificate, or if its certificate is for signing only). If the
   server is authenticated, it may request a certificate from the
   client, if that is appropriate to the cipher suite selected. Now the
   server will send the server hello done message, indicating that the
   hello-message phase of the handshake is complete. The server will
   then wait for a client response. If the server has sent a certificate
   request message, the client must send the certificate message. The
   client key exchange message is now sent, and the content of that
   message will depend on the public key algorithm selected between the
   client hello and the server hello. If the client has sent a
   certificate with signing ability, a digitally-signed certificate
   verify message is sent to explicitly verify the certificate.

   At this point, a change cipher spec message is sent by the client,
   and the client copies the pending Cipher Spec into the current Cipher
   Spec. The client then immediately sends the finished message under
   the new algorithms, keys, and secrets. In response, the server will
   send its own change cipher spec message, transfer the pending to the
   current Cipher Spec, and send its finished message under the new






 
RFC 2246              The TLS Protocol Version 1.0          January 1999


   Cipher Spec. At this point, the handshake is complete and the client
   and server may begin to exchange application layer data. (See flow
   chart below.)

      Client                                               Server

      ClientHello                  -------->
                                                      ServerHello
                                                     Certificate*
                                               ServerKeyExchange*
                                              CertificateRequest*
                                   <--------      ServerHelloDone
      Certificate*
      ClientKeyExchange