error if these eight padding bytes are 0x03. Version 2.0 servers
   receiving blocks padded in this manner will proceed normally.








 
RFC 2246              The TLS Protocol Version 1.0          January 1999


F. Security analysis

   The TLS protocol is designed to establish a secure connection between
   a client and a server communicating over an insecure channel. This
   document makes several traditional assumptions, including that
   attackers have substantial computational resources and cannot obtain
   secret information from sources outside the protocol. Attackers are
   assumed to have the ability to capture, modify, delete, replay, and
   otherwise tamper with messages sent over the communication channel.
   This appendix outlines how TLS has been designed to resist a variety
   of attacks.

F.1. Handshake protocol

   The handshake protocol is responsible for selecting a CipherSpec and
   generating a Master Secret, which together comprise the primary
   cryptographic parameters associated with a secure session. The
   handshake protocol can also optionally authenticate parties who have
   certificates signed by a trusted certificate authority.

F.1.1. Authentication and key exchange

   TLS supports three authentication modes: authentication of both
   parties, server authentication with an unauthenticated client, and
   total anonymity. Whenever the server is authenticated, the channel is
   secure against man-in-the-middle attacks, but completely anonymous
   sessions are inherently vulnerable to such attacks.  Anonymous
   servers cannot authenticate clients. If the server is authenticated,
   its certificate message must provide a valid certificate chain
   leading to an acceptable certificate authority.  Similarly,
   authenticated clients must supply an acceptable certificate to the
   server. Each party is responsible for verifying that the other's
   certificate is valid and has not expired or been revoked.

   The general goal of the key exchange process is to create a
   pre_master_secret known to the communicating parties and not to
   attackers. The pre_master_secret will be used to generate the
   master_secret (see Section 8.1). The master_secret is required to
   generate the certificate verify and finished messages, encryption
   keys, and MAC secrets (see Sections 7.4.8, 7.4.9 and 6.3). By sending
   a correct finished message, parties thus prove that they know the
   correct pre_master_secret.

F.1.1.1. Anonymous key exchange

   Completely anonymous sessions can be established using RSA or
   Diffie-Hellman for key exchange. With anonymous RSA, the client
   encrypts a pre_master_secret with the server's uncertified public key




 
RFC 2246              The TLS Protocol Version 1.0          January 1999


   extracted from the server key exchange message. The result is sent in
   a client key exchange message. Since eavesdroppers do not know the
   server's private key, it will be infeasible for them to decode the
   pre_master_secret. (Note that no anonymous RSA Cipher Suites are
   defined in this document).

   With Diffie-Hellman, the server's public parameters are contained in
   the server key exchange message and the client's are sent in the
   client key exchange message. Eavesdroppers who do not know the
   private values should not be able to find the Diffie-Hellman result
   (i.e. the pre_master_secret).

 Warning: Completely anonymous connections only provide protection
          against passive eavesdropping. Unless an independent tamper-
          proof channel is used to verify that the finished messages
          were not replaced by an attacker, server authentication is
          required in environments where active man-in-the-middle
          attacks are a concern.

F.1.1.2. RSA key exchange and authentication

   With RSA, key exchange and server authentication are combined. The
   public key may be either contained in the server's certificate or may
   be a temporary RSA key sent in a server key exchange message.  When
   temporary RSA keys are used, they are signed by the server's RSA or
   DSS certificate. The signature includes the current
   ClientHello.random, so old signatures and temporary keys cannot be
   replayed. Servers may use a single temporary RSA key for multiple
   negotiation sessions.