in Index   Prev   Next

RFC 2246

The TLS Protocol Version 1.0

Pages: 80
Obsoleted by:  4346
Updated by:  354657466176746575077919
Part 2 of 3 – Pages 23 to 48
First   Prev   Next

ToP   noToC   RFC2246 - Page 23   prevText
7. The TLS Handshake Protocol

   The TLS Handshake Protocol consists of a suite of three sub-protocols
   which are used to allow peers to agree upon security parameters for
   the record layer, authenticate themselves, instantiate negotiated
   security parameters, and report error conditions to each other.

   The Handshake Protocol is responsible for negotiating a session,
   which consists of the following items:

   session identifier
       An arbitrary byte sequence chosen by the server to identify an
       active or resumable session state.

   peer certificate
       X509v3 [X509] certificate of the peer. This element of the state
       may be null.

   compression method
       The algorithm used to compress data prior to encryption.

   cipher spec
       Specifies the bulk data encryption algorithm (such as null, DES,
       etc.) and a MAC algorithm (such as MD5 or SHA). It also defines
       cryptographic attributes such as the hash_size. (See Appendix A.6
       for formal definition)

   master secret
       48-byte secret shared between the client and server.

   is resumable
       A flag indicating whether the session can be used to initiate new
ToP   noToC   RFC2246 - Page 24
   These items are then used to create security parameters for use by
   the Record Layer when protecting application data. Many connections
   can be instantiated using the same session through the resumption
   feature of the TLS Handshake Protocol.

7.1. Change cipher spec protocol

   The change cipher spec protocol exists to signal transitions in
   ciphering strategies. The protocol consists of a single message,
   which is encrypted and compressed under the current (not the pending)
   connection state. The message consists of a single byte of value 1.

       struct {
           enum { change_cipher_spec(1), (255) } type;
       } ChangeCipherSpec;

   The change cipher spec message is sent by both the client and server
   to notify the receiving party that subsequent records will be
   protected under the newly negotiated CipherSpec and keys. Reception
   of this message causes the receiver to instruct the Record Layer to
   immediately copy the read pending state into the read current state.
   Immediately after sending this message, the sender should instruct
   the record layer to make the write pending state the write active
   state. (See section 6.1.) The change cipher spec message is sent
   during the handshake after the security parameters have been agreed
   upon, but before the verifying finished message is sent (see section

7.2. Alert protocol

   One of the content types supported by the TLS Record layer is the
   alert type. Alert messages convey the severity of the message and a
   description of the alert. Alert messages with a level of fatal result
   in the immediate termination of the connection. In this case, other
   connections corresponding to the session may continue, but the
   session identifier must be invalidated, preventing the failed session
   from being used to establish new connections. Like other messages,
   alert messages are encrypted and compressed, as specified by the
   current connection state.

       enum { warning(1), fatal(2), (255) } AlertLevel;

       enum {
ToP   noToC   RFC2246 - Page 25
       } AlertDescription;

       struct {
           AlertLevel level;
           AlertDescription description;
       } Alert;

7.2.1. Closure alerts

   The client and the server must share knowledge that the connection is
   ending in order to avoid a truncation attack. Either party may
   initiate the exchange of closing messages.

       This message notifies the recipient that the sender will not send
       any more messages on this connection. The session becomes
       unresumable if any connection is terminated without proper
       close_notify messages with level equal to warning.

   Either party may initiate a close by sending a close_notify alert.
   Any data received after a closure alert is ignored.

   Each party is required to send a close_notify alert before closing
   the write side of the connection. It is required that the other party
   respond with a close_notify alert of its own and close down the
   connection immediately, discarding any pending writes. It is not
   required for the initiator of the close to wait for the responding
   close_notify alert before closing the read side of the connection.
ToP   noToC   RFC2246 - Page 26
   If the application protocol using TLS provides that any data may be
   carried over the underlying transport after the TLS connection is
   closed, the TLS implementation must receive the responding
   close_notify alert before indicating to the application layer that
   the TLS connection has ended. If the application protocol will not
   transfer any additional data, but will only close the underlying
   transport connection, then the implementation may choose to close the
   transport without waiting for the responding close_notify. No part of
   this standard should be taken to dictate the manner in which a usage
   profile for TLS manages its data transport, including when
   connections are opened or closed.

   NB: It is assumed that closing a connection reliably delivers
       pending data before destroying the transport.

7.2.2. Error alerts

   Error handling in the TLS Handshake protocol is very simple. When an
   error is detected, the detecting party sends a message to the other
   party. Upon transmission or receipt of an fatal alert message, both
   parties immediately close the connection. Servers and clients are
   required to forget any session-identifiers, keys, and secrets
   associated with a failed connection. The following error alerts are

       An inappropriate message was received. This alert is always fatal
       and should never be observed in communication between proper

       This alert is returned if a record is received with an incorrect
       MAC. This message is always fatal.

       A TLSCiphertext decrypted in an invalid way: either it wasn`t an
       even multiple of the block length or its padding values, when
       checked, weren`t correct. This message is always fatal.

       A TLSCiphertext record was received which had a length more than
       2^14+2048 bytes, or a record decrypted to a TLSCompressed record
       with more than 2^14+1024 bytes. This message is always fatal.

       The decompression function received improper input (e.g. data
       that would expand to excessive length). This message is always
ToP   noToC   RFC2246 - Page 27
       Reception of a handshake_failure alert message indicates that the
       sender was unable to negotiate an acceptable set of security
       parameters given the options available. This is a fatal error.

       A certificate was corrupt, contained signatures that did not
       verify correctly, etc.

       A certificate was of an unsupported type.

       A certificate was revoked by its signer.

       A certificate has expired or is not currently valid.

       Some other (unspecified) issue arose in processing the
       certificate, rendering it unacceptable.

       A field in the handshake was out of range or inconsistent with
       other fields. This is always fatal.

       A valid certificate chain or partial chain was received, but the
       certificate was not accepted because the CA certificate could not
       be located or couldn`t be matched with a known, trusted CA.  This
       message is always fatal.

       A valid certificate was received, but when access control was
       applied, the sender decided not to proceed with negotiation.
       This message is always fatal.

       A message could not be decoded because some field was out of the
       specified range or the length of the message was incorrect. This
       message is always fatal.

       A handshake cryptographic operation failed, including being
       unable to correctly verify a signature, decrypt a key exchange,
       or validate a finished message.
ToP   noToC   RFC2246 - Page 28
       A negotiation not in compliance with export restrictions was
       detected; for example, attempting to transfer a 1024 bit
       ephemeral RSA key for the RSA_EXPORT handshake method. This
       message is always fatal.

       The protocol version the client has attempted to negotiate is
       recognized, but not supported. (For example, old protocol
       versions might be avoided for security reasons). This message is
       always fatal.

       Returned instead of handshake_failure when a negotiation has
       failed specifically because the server requires ciphers more
       secure than those supported by the client. This message is always

       An internal error unrelated to the peer or the correctness of the
       protocol makes it impossible to continue (such as a memory
       allocation failure). This message is always fatal.

       This handshake is being canceled for some reason unrelated to a
       protocol failure. If the user cancels an operation after the
       handshake is complete, just closing the connection by sending a
       close_notify is more appropriate. This alert should be followed
       by a close_notify. This message is generally a warning.

       Sent by the client in response to a hello request or by the
       server in response to a client hello after initial handshaking.
       Either of these would normally lead to renegotiation; when that
       is not appropriate, the recipient should respond with this alert;
       at that point, the original requester can decide whether to
       proceed with the connection. One case where this would be
       appropriate would be where a server has spawned a process to
       satisfy a request; the process might receive security parameters
       (key length, authentication, etc.) at startup and it might be
       difficult to communicate changes to these parameters after that
       point. This message is always a warning.

   For all errors where an alert level is not explicitly specified, the
   sending party may determine at its discretion whether this is a fatal
   error or not; if an alert with a level of warning is received, the
ToP   noToC   RFC2246 - Page 29
   receiving party may decide at its discretion whether to treat this as
   a fatal error or not. However, all messages which are transmitted
   with a level of fatal must be treated as fatal messages.

7.3. Handshake Protocol overview

   The cryptographic parameters of the session state are produced by the
   TLS Handshake Protocol, which operates on top of the TLS Record
   Layer. When a TLS client and server first start communicating, they
   agree on a protocol version, select cryptographic algorithms,
   optionally authenticate each other, and use public-key encryption
   techniques to generate shared secrets.

   The TLS Handshake Protocol involves the following steps:

     - Exchange hello messages to agree on algorithms, exchange random
       values, and check for session resumption.

     - Exchange the necessary cryptographic parameters to allow the
       client and server to agree on a premaster secret.

     - Exchange certificates and cryptographic information to allow the
       client and server to authenticate themselves.

     - Generate a master secret from the premaster secret and exchanged
       random values.

     - 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.
ToP   noToC   RFC2246 - Page 30
   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

   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

   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
ToP   noToC   RFC2246 - Page 31
   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                  -------->
                                   <--------      ServerHelloDone
      Finished                     -------->
                                   <--------             Finished
      Application Data             <------->     Application Data

             Fig. 1 - Message flow for a full handshake

   * Indicates optional or situation-dependent messages that are not
   always sent.

  Note: To help avoid pipeline stalls, ChangeCipherSpec is an
       independent TLS Protocol content type, and is not actually a TLS
       handshake message.

   When the client and server decide to resume a previous session or
   duplicate an existing session (instead of negotiating new security
   parameters) the message flow is as follows:

   The client sends a ClientHello using the Session ID of the session to
   be resumed. The server then checks its session cache for a match.  If
   a match is found, and the server is willing to re-establish the
   connection under the specified session state, it will send a
   ServerHello with the same Session ID value. At this point, both
   client and server must send change cipher spec messages and proceed
   directly to finished messages. Once the re-establishment is complete,
   the client and server may begin to exchange application layer data.
   (See flow chart below.) If a Session ID match is not found, the
   server generates a new session ID and the TLS client and server
   perform a full handshake.
ToP   noToC   RFC2246 - Page 32
      Client                                                Server

      ClientHello                   -------->
                                    <--------             Finished
      Finished                      -------->
      Application Data              <------->     Application Data

          Fig. 2 - Message flow for an abbreviated handshake

   The contents and significance of each message will be presented in
   detail in the following sections.

7.4. Handshake protocol

   The TLS Handshake Protocol is one of the defined higher level clients
   of the TLS Record Protocol. This protocol is used to negotiate the
   secure attributes of a session. Handshake messages are supplied to
   the TLS Record Layer, where they are encapsulated within one or more
   TLSPlaintext structures, which are processed and transmitted as
   specified by the current active session state.

       enum {
           hello_request(0), client_hello(1), server_hello(2),
           certificate(11), server_key_exchange (12),
           certificate_request(13), server_hello_done(14),
           certificate_verify(15), client_key_exchange(16),
           finished(20), (255)
       } HandshakeType;

       struct {
           HandshakeType msg_type;    /* handshake type */
           uint24 length;             /* bytes in message */
           select (HandshakeType) {
               case hello_request:       HelloRequest;
               case client_hello:        ClientHello;
               case server_hello:        ServerHello;
               case certificate:         Certificate;
               case server_key_exchange: ServerKeyExchange;
               case certificate_request: CertificateRequest;
               case server_hello_done:   ServerHelloDone;
               case certificate_verify:  CertificateVerify;
               case client_key_exchange: ClientKeyExchange;
               case finished:            Finished;
           } body;
       } Handshake;
ToP   noToC   RFC2246 - Page 33
   The handshake protocol messages are presented below in the order they
   must be sent; sending handshake messages in an unexpected order
   results in a fatal error. Unneeded handshake messages can be omitted,
   however. Note one exception to the ordering: the Certificate message
   is used twice in the handshake (from server to client, then from
   client to server), but described only in its first position. The one
   message which is not bound by these ordering rules in the Hello
   Request message, which can be sent at any time, but which should be
   ignored by the client if it arrives in the middle of a handshake.

7.4.1. Hello messages

   The hello phase messages are used to exchange security enhancement
   capabilities between the client and server. When a new session
   begins, the Record Layer's connection state encryption, hash, and
   compression algorithms are initialized to null. The current
   connection state is used for renegotiation messages. Hello request

   When this message will be sent:
       The hello request message may be sent by the server at any time.

   Meaning of this message:
       Hello request is a simple notification that the client should
       begin the negotiation process anew by sending a client hello
       message when convenient. This message will be ignored by the
       client if the client is currently negotiating a session. This
       message may be ignored by the client if it does not wish to
       renegotiate a session, or the client may, if it wishes, respond
       with a no_renegotiation alert. Since handshake messages are
       intended to have transmission precedence over application data,
       it is expected that the negotiation will begin before no more
       than a few records are received from the client. If the server
       sends a hello request but does not receive a client hello in
       response, it may close the connection with a fatal alert.

   After sending a hello request, servers should not repeat the request
   until the subsequent handshake negotiation is complete.

   Structure of this message:
       struct { } HelloRequest;

 Note: This message should never be included in the message hashes which
       are maintained throughout the handshake and used in the finished
       messages and the certificate verify message.
ToP   noToC   RFC2246 - Page 34 Client hello

   When this message will be sent:
       When a client first connects to a server it is required to send
       the client hello as its first message. The client can also send a
       client hello in response to a hello request or on its own
       initiative in order to renegotiate the security parameters in an
       existing connection.

       Structure of this message:
           The client hello message includes a random structure, which is
           used later in the protocol.

           struct {
              uint32 gmt_unix_time;
              opaque random_bytes[28];
           } Random;

       The current time and date in standard UNIX 32-bit format (seconds
       since the midnight starting Jan 1, 1970, GMT) according to the
       sender's internal clock. Clocks are not required to be set
       correctly by the basic TLS Protocol; higher level or application
       protocols may define additional requirements.

       28 bytes generated by a secure random number generator.

   The client hello message includes a variable length session
   identifier. If not empty, the value identifies a session between the
   same client and server whose security parameters the client wishes to
   reuse. The session identifier may be from an earlier connection, this
   connection, or another currently active connection. The second option
   is useful if the client only wishes to update the random structures
   and derived values of a connection, while the third option makes it
   possible to establish several independent secure connections without
   repeating the full handshake protocol. These independent connections
   may occur sequentially or simultaneously; a SessionID becomes valid
   when the handshake negotiating it completes with the exchange of
   Finished messages and persists until removed due to aging or because
   a fatal error was encountered on a connection associated with the
   session. The actual contents of the SessionID are defined by the

       opaque SessionID<0..32>;
ToP   noToC   RFC2246 - Page 35
       Because the SessionID is transmitted without encryption or
       immediate MAC protection, servers must not place confidential
       information in session identifiers or let the contents of fake
       session identifiers cause any breach of security. (Note that the
       content of the handshake as a whole, including the SessionID, is
       protected by the Finished messages exchanged at the end of the

   The CipherSuite list, passed from the client to the server in the
   client hello message, contains the combinations of cryptographic
   algorithms supported by the client in order of the client's
   preference (favorite choice first). Each CipherSuite defines a key
   exchange algorithm, a bulk encryption algorithm (including secret key
   length) and a MAC algorithm. The server will select a cipher suite
   or, if no acceptable choices are presented, return a handshake
   failure alert and close the connection.

       uint8 CipherSuite[2];    /* Cryptographic suite selector */

   The client hello includes a list of compression algorithms supported
   by the client, ordered according to the client's preference.

       enum { null(0), (255) } CompressionMethod;

       struct {
           ProtocolVersion client_version;
           Random random;
           SessionID session_id;
           CipherSuite cipher_suites<2..2^16-1>;
           CompressionMethod compression_methods<1..2^8-1>;
       } ClientHello;

       The version of the TLS protocol by which the client wishes to
       communicate during this session. This should be the latest
       (highest valued) version supported by the client. For this
       version of the specification, the version will be 3.1 (See
       Appendix E for details about backward compatibility).

       A client-generated random structure.

       The ID of a session the client wishes to use for this connection.
       This field should be empty if no session_id is available or the
       client wishes to generate new security parameters.
ToP   noToC   RFC2246 - Page 36
       This is a list of the cryptographic options supported by the
       client, with the client's first preference first. If the
       session_id field is not empty (implying a session resumption
       request) this vector must include at least the cipher_suite from
       that session. Values are defined in Appendix A.5.

       This is a list of the compression methods supported by the
       client, sorted by client preference. If the session_id field is
       not empty (implying a session resumption request) it must include
       the compression_method from that session. This vector must
       contain, and all implementations must support,
       CompressionMethod.null. Thus, a client and server will always be
       able to agree on a compression method.

   After sending the client hello message, the client waits for a server
   hello message. Any other handshake message returned by the server
   except for a hello request is treated as a fatal error.

   Forward compatibility note:
       In the interests of forward compatibility, it is permitted for a
       client hello message to include extra data after the compression
       methods. This data must be included in the handshake hashes, but
       must otherwise be ignored. This is the only handshake message for
       which this is legal; for all other messages, the amount of data
       in the message must match the description of the message
       precisely. Server hello

   When this message will be sent:
       The server will send this message in response to a client hello
       message when it was able to find an acceptable set of algorithms.
       If it cannot find such a match, it will respond with a handshake
       failure alert.

   Structure of this message:
       struct {
           ProtocolVersion server_version;
           Random random;
           SessionID session_id;
           CipherSuite cipher_suite;
           CompressionMethod compression_method;
       } ServerHello;
ToP   noToC   RFC2246 - Page 37
       This field will contain the lower of that suggested by the client
       in the client hello and the highest supported by the server. For
       this version of the specification, the version is 3.1 (See
       Appendix E for details about backward compatibility).

       This structure is generated by the server and must be different
       from (and independent of) ClientHello.random.

       This is the identity of the session corresponding to this
       connection. If the ClientHello.session_id was non-empty, the
       server will look in its session cache for a match. If a match is
       found and the server is willing to establish the new connection
       using the specified session state, the server will respond with
       the same value as was supplied by the client. This indicates a
       resumed session and dictates that the parties must proceed
       directly to the finished messages. Otherwise this field will
       contain a different value identifying the new session. The server
       may return an empty session_id to indicate that the session will
       not be cached and therefore cannot be resumed. If a session is
       resumed, it must be resumed using the same cipher suite it was
       originally negotiated with.

       The single cipher suite selected by the server from the list in
       ClientHello.cipher_suites. For resumed sessions this field is the
       value from the state of the session being resumed.

       The single compression algorithm selected by the server from the
       list in ClientHello.compression_methods. For resumed sessions
       this field is the value from the resumed session state.

7.4.2. Server certificate

   When this message will be sent:
       The server must send a certificate whenever the agreed-upon key
       exchange method is not an anonymous one. This message will always
       immediately follow the server hello message.

   Meaning of this message:
       The certificate type must be appropriate for the selected cipher
       suite's key exchange algorithm, and is generally an X.509v3
       certificate. It must contain a key which matches the key exchange
       method, as follows. Unless otherwise specified, the signing
ToP   noToC   RFC2246 - Page 38
       algorithm for the certificate must be the same as the algorithm
       for the certificate key. Unless otherwise specified, the public
       key may be of any length.

       Key Exchange Algorithm  Certificate Key Type

       RSA                     RSA public key; the certificate must
                               allow the key to be used for encryption.

       RSA_EXPORT              RSA public key of length greater than
                               512 bits which can be used for signing,
                               or a key of 512 bits or shorter which
                               can be used for either encryption or

       DHE_DSS                 DSS public key.

       DHE_DSS_EXPORT          DSS public key.

       DHE_RSA                 RSA public key which can be used for

       DHE_RSA_EXPORT          RSA public key which can be used for

       DH_DSS                  Diffie-Hellman key. The algorithm used
                               to sign the certificate should be DSS.

       DH_RSA                  Diffie-Hellman key. The algorithm used
                               to sign the certificate should be RSA.

   All certificate profiles, key and cryptographic formats are defined
   by the IETF PKIX working group [PKIX]. When a key usage extension is
   present, the digitalSignature bit must be set for the key to be
   eligible for signing, as described above, and the keyEncipherment bit
   must be present to allow encryption, as described above. The
   keyAgreement bit must be set on Diffie-Hellman certificates.

   As CipherSuites which specify new key exchange methods are specified
   for the TLS Protocol, they will imply certificate format and the
   required encoded keying information.

   Structure of this message:
       opaque ASN.1Cert<1..2^24-1>;

       struct {
           ASN.1Cert certificate_list<0..2^24-1>;
       } Certificate;
ToP   noToC   RFC2246 - Page 39
       This is a sequence (chain) of X.509v3 certificates. The sender's
       certificate must come first in the list. Each following
       certificate must directly certify the one preceding it. Because
       certificate validation requires that root keys be distributed
       independently, the self-signed certificate which specifies the
       root certificate authority may optionally be omitted from the
       chain, under the assumption that the remote end must already
       possess it in order to validate it in any case.

   The same message type and structure will be used for the client's
   response to a certificate request message. Note that a client may
   send no certificates if it does not have an appropriate certificate
   to send in response to the server's authentication request.

 Note: PKCS #7 [PKCS7] is not used as the format for the certificate
       vector because PKCS #6 [PKCS6] extended certificates are not
       used. Also PKCS #7 defines a SET rather than a SEQUENCE, making
       the task of parsing the list more difficult.

7.4.3. Server key exchange message

   When this message will be sent:
       This message will be sent immediately after the server
       certificate message (or the server hello message, if this is an
       anonymous negotiation).

       The server key exchange message is sent by the server only when
       the server certificate message (if sent) does not contain enough
       data to allow the client to exchange a premaster secret. This is
       true for the following key exchange methods:

           RSA_EXPORT (if the public key in the server certificate is
           longer than 512 bits)

       It is not legal to send the server key exchange message for the
       following key exchange methods:

           RSA_EXPORT (when the public key in the server certificate is
           less than or equal to 512 bits in length)
ToP   noToC   RFC2246 - Page 40
   Meaning of this message:
       This message conveys cryptographic information to allow the
       client to communicate the premaster secret: either an RSA public
       key to encrypt the premaster secret with, or a Diffie-Hellman
       public key with which the client can complete a key exchange
       (with the result being the premaster secret.)

   As additional CipherSuites are defined for TLS which include new key
   exchange algorithms, the server key exchange message will be sent if
   and only if the certificate type associated with the key exchange
   algorithm does not provide enough information for the client to
   exchange a premaster secret.

 Note: According to current US export law, RSA moduli larger than 512
       bits may not be used for key exchange in software exported from
       the US. With this message, the larger RSA keys encoded in
       certificates may be used to sign temporary shorter RSA keys for
       the RSA_EXPORT key exchange method.

   Structure of this message:
       enum { rsa, diffie_hellman } KeyExchangeAlgorithm;

       struct {
           opaque rsa_modulus<1..2^16-1>;
           opaque rsa_exponent<1..2^16-1>;
       } ServerRSAParams;

           The modulus of the server's temporary RSA key.

           The public exponent of the server's temporary RSA key.

       struct {
           opaque dh_p<1..2^16-1>;
           opaque dh_g<1..2^16-1>;
           opaque dh_Ys<1..2^16-1>;
       } ServerDHParams;     /* Ephemeral DH parameters */

           The prime modulus used for the Diffie-Hellman operation.

           The generator used for the Diffie-Hellman operation.

           The server's Diffie-Hellman public value (g^X mod p).
ToP   noToC   RFC2246 - Page 41
       struct {
           select (KeyExchangeAlgorithm) {
               case diffie_hellman:
                   ServerDHParams params;
                   Signature signed_params;
               case rsa:
                   ServerRSAParams params;
                   Signature signed_params;
       } ServerKeyExchange;

           The server's key exchange parameters.

           For non-anonymous key exchanges, a hash of the corresponding
           params value, with the signature appropriate to that hash

           MD5(ClientHello.random + ServerHello.random + ServerParams);

           SHA(ClientHello.random + ServerHello.random + ServerParams);

       enum { anonymous, rsa, dsa } SignatureAlgorithm;

       select (SignatureAlgorithm)
       {   case anonymous: struct { };
           case rsa:
               digitally-signed struct {
                   opaque md5_hash[16];
                   opaque sha_hash[20];
           case dsa:
               digitally-signed struct {
                   opaque sha_hash[20];
       } Signature;

7.4.4. Certificate request

   When this message will be sent:
       A non-anonymous server can optionally request a certificate from
       the client, if appropriate for the selected cipher suite. This
       message, if sent, will immediately follow the Server Key Exchange
       message (if it is sent; otherwise, the Server Certificate
ToP   noToC   RFC2246 - Page 42
   Structure of this message:
       enum {
           rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
       } ClientCertificateType;

       opaque DistinguishedName<1..2^16-1>;

       struct {
           ClientCertificateType certificate_types<1..2^8-1>;
           DistinguishedName certificate_authorities<3..2^16-1>;
       } CertificateRequest;

              This field is a list of the types of certificates requested,
              sorted in order of the server's preference.

           A list of the distinguished names of acceptable certificate
           authorities. These distinguished names may specify a desired
           distinguished name for a root CA or for a subordinate CA;
           thus, this message can be used both to describe known roots
           and a desired authorization space.

 Note: DistinguishedName is derived from [X509].

 Note: It is a fatal handshake_failure alert for an anonymous server to
       request client identification.

7.4.5. Server hello done

   When this message will be sent:
       The server hello done message is sent by the server to indicate
       the end of the server hello and associated messages. After
       sending this message the server will wait for a client response.

   Meaning of this message:
       This message means that the server is done sending messages to
       support the key exchange, and the client can proceed with its
       phase of the key exchange.

       Upon receipt of the server hello done message the client should
       verify that the server provided a valid certificate if required
       and check that the server hello parameters are acceptable.

   Structure of this message:
       struct { } ServerHelloDone;
ToP   noToC   RFC2246 - Page 43
7.4.6. Client certificate

   When this message will be sent:
       This is the first message the client can send after receiving a
       server hello done message. This message is only sent if the
       server requests a certificate. If no suitable certificate is
       available, the client should send a certificate message
       containing no certificates. If client authentication is required
       by the server for the handshake to continue, it may respond with
       a fatal handshake failure alert. Client certificates are sent
       using the Certificate structure defined in Section 7.4.2.

 Note: When using a static Diffie-Hellman based key exchange method
       (DH_DSS or DH_RSA), if client authentication is requested, the
       Diffie-Hellman group and generator encoded in the client's
       certificate must match the server specified Diffie-Hellman
       parameters if the client's parameters are to be used for the key

7.4.7. Client key exchange message

   When this message will be sent:
       This message is always sent by the client. It will immediately
       follow the client certificate message, if it is sent. Otherwise
       it will be the first message sent by the client after it receives
       the server hello done message.

   Meaning of this message:
       With this message, the premaster secret is set, either though
       direct transmission of the RSA-encrypted secret, or by the
       transmission of Diffie-Hellman parameters which will allow each
       side to agree upon the same premaster secret. When the key
       exchange method is DH_RSA or DH_DSS, client certification has
       been requested, and the client was able to respond with a
       certificate which contained a Diffie-Hellman public key whose
       parameters (group and generator) matched those specified by the
       server in its certificate, this message will not contain any

   Structure of this message:
       The choice of messages depends on which key exchange method has
       been selected. See Section 7.4.3 for the KeyExchangeAlgorithm

       struct {
           select (KeyExchangeAlgorithm) {
               case rsa: EncryptedPreMasterSecret;
               case diffie_hellman: ClientDiffieHellmanPublic;
ToP   noToC   RFC2246 - Page 44
           } exchange_keys;
       } ClientKeyExchange; RSA encrypted premaster secret message

   Meaning of this message:
       If RSA is being used for key agreement and authentication, the
       client generates a 48-byte premaster secret, encrypts it using
       the public key from the server's certificate or the temporary RSA
       key provided in a server key exchange message, and sends the
       result in an encrypted premaster secret message. This structure
       is a variant of the client key exchange message, not a message in

   Structure of this message:
       struct {
           ProtocolVersion client_version;
           opaque random[46];
       } PreMasterSecret;

           The latest (newest) version supported by the client. This is
           used to detect version roll-back attacks. Upon receiving the
           premaster secret, the server should check that this value
           matches the value transmitted by the client in the client
           hello message.

           46 securely-generated random bytes.

       struct {
           public-key-encrypted PreMasterSecret pre_master_secret;
       } EncryptedPreMasterSecret;

 Note: An attack discovered by Daniel Bleichenbacher [BLEI] can be used
       to attack a TLS server which is using PKCS#1 encoded RSA. The
       attack takes advantage of the fact that by failing in different
       ways, a TLS server can be coerced into revealing whether a
       particular message, when decrypted, is properly PKCS#1 formatted
       or not.

       The best way to avoid vulnerability to this attack is to treat
       incorrectly formatted messages in a manner indistinguishable from
       correctly formatted RSA blocks. Thus, when it receives an
       incorrectly formatted RSA block, a server should generate a
       random 48-byte value and proceed using it as the premaster
       secret. Thus, the server will act identically whether the
       received RSA block is correctly encoded or not.
ToP   noToC   RFC2246 - Page 45
           This random value is generated by the client and is used to
           generate the master secret, as specified in Section 8.1. Client Diffie-Hellman public value

   Meaning of this message:
       This structure conveys the client's Diffie-Hellman public value
       (Yc) if it was not already included in the client's certificate.
       The encoding used for Yc is determined by the enumerated
       PublicValueEncoding. This structure is a variant of the client
       key exchange message, not a message in itself.

   Structure of this message:
       enum { implicit, explicit } PublicValueEncoding;

           If the client certificate already contains a suitable
           Diffie-Hellman key, then Yc is implicit and does not need to
           be sent again. In this case, the Client Key Exchange message
           will be sent, but will be empty.

           Yc needs to be sent.

       struct {
           select (PublicValueEncoding) {
               case implicit: struct { };
               case explicit: opaque dh_Yc<1..2^16-1>;
           } dh_public;
       } ClientDiffieHellmanPublic;

           The client's Diffie-Hellman public value (Yc).

7.4.8. Certificate verify

   When this message will be sent:
       This message is used to provide explicit verification of a client
       certificate. This message is only sent following a client
       certificate that has signing capability (i.e. all certificates
       except those containing fixed Diffie-Hellman parameters). When
       sent, it will immediately follow the client key exchange message.

   Structure of this message:
       struct {
            Signature signature;
       } CertificateVerify;
ToP   noToC   RFC2246 - Page 46
       The Signature type is defined in 7.4.3.



   Here handshake_messages refers to all handshake messages sent or
   received starting at client hello up to but not including this
   message, including the type and length fields of the handshake
   messages. This is the concatenation of all the Handshake structures
   as defined in 7.4 exchanged thus far.

7.4.9. Finished

   When this message will be sent:
       A finished message is always sent immediately after a change
       cipher spec message to verify that the key exchange and
       authentication processes were successful. It is essential that a
       change cipher spec message be received between the other
       handshake messages and the Finished message.

   Meaning of this message:
       The finished message is the first protected with the just-
       negotiated algorithms, keys, and secrets. Recipients of finished
       messages must verify that the contents are correct.  Once a side
       has sent its Finished message and received and validated the
       Finished message from its peer, it may begin to send and receive
       application data over the connection.

       struct {
           opaque verify_data[12];
       } Finished;

           PRF(master_secret, finished_label, MD5(handshake_messages) +
           SHA-1(handshake_messages)) [0..11];

           For Finished messages sent by the client, the string "client
           finished". For Finished messages sent by the server, the
           string "server finished".

           All of the data from all handshake messages up to but not
           including this message. This is only data visible at the
           handshake layer and does not include record layer headers.
ToP   noToC   RFC2246 - Page 47
           This is the concatenation of all the Handshake structures as
           defined in 7.4 exchanged thus far.

   It is a fatal error if a finished message is not preceded by a change
   cipher spec message at the appropriate point in the handshake.

   The hash contained in finished messages sent by the server
   incorporate Sender.server; those sent by the client incorporate
   Sender.client. The value handshake_messages includes all handshake
   messages starting at client hello up to, but not including, this
   finished message. This may be different from handshake_messages in
   Section 7.4.8 because it would include the certificate verify message
   (if sent). Also, the handshake_messages for the finished message sent
   by the client will be different from that for the finished message
   sent by the server, because the one which is sent second will include
   the prior one.

 Note: Change cipher spec messages, alerts and any other record types
       are not handshake messages and are not included in the hash
       computations. Also, Hello Request messages are omitted from
       handshake hashes.

8. Cryptographic computations

   In order to begin connection protection, the TLS Record Protocol
   requires specification of a suite of algorithms, a master secret, and
   the client and server random values. The authentication, encryption,
   and MAC algorithms are determined by the cipher_suite selected by the
   server and revealed in the server hello message. The compression
   algorithm is negotiated in the hello messages, and the random values
   are exchanged in the hello messages. All that remains is to calculate
   the master secret.

8.1. Computing the master secret

   For all key exchange methods, the same algorithm is used to convert
   the pre_master_secret into the master_secret. The pre_master_secret
   should be deleted from memory once the master_secret has been

       master_secret = PRF(pre_master_secret, "master secret",
                           ClientHello.random + ServerHello.random)

   The master secret is always exactly 48 bytes in length. The length of
   the premaster secret will vary depending on key exchange method.
ToP   noToC   RFC2246 - Page 48
8.1.1. RSA

   When RSA is used for server authentication and key exchange, a 48-
   byte pre_master_secret is generated by the client, encrypted under
   the server's public key, and sent to the server. The server uses its
   private key to decrypt the pre_master_secret. Both parties then
   convert the pre_master_secret into the master_secret, as specified

   RSA digital signatures are performed using PKCS #1 [PKCS1] block type
   1. RSA public key encryption is performed using PKCS #1 block type 2.

8.1.2. Diffie-Hellman

   A conventional Diffie-Hellman computation is performed. The
   negotiated key (Z) is used as the pre_master_secret, and is converted
   into the master_secret, as specified above.

 Note: Diffie-Hellman parameters are specified by the server, and may
       be either ephemeral or contained within the server's certificate.

9. Mandatory Cipher Suites

   In the absence of an application profile standard specifying
   otherwise, a TLS compliant application MUST implement the cipher

10. Application data protocol

   Application data messages are carried by the Record Layer and are
   fragmented, compressed and encrypted based on the current connection
   state. The messages are treated as transparent data to the record

(next page on part 3)

Next Section