https://datatracker.ietf.org/doc/html/rfc5246

7.3.  Handshake Protocol Overview

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.

Following the hello messages, the server will send its certificate in
   a Certificate message if it is to be authenticated.  Additionally, a
   ServerKeyExchange message may be sent, if it is required (e.g., if
   the 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.
   Next, the server will send the ServerHelloDone 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 CertificateRequest message, the client MUST send the Certificate
   message.  The ClientKeyExchange message is now sent, and the content
   of that message will depend on the public key algorithm selected
   between the ClientHello and the ServerHello.  If the client has sent
   a certificate with signing ability, a digitally-signed
   CertificateVerify message is sent to explicitly verify possession of
   the private key in the certificate.

7.4.6.  Client Certificate

   When this message will be sent:

      This is the first message the client can send after receiving a
      ServerHelloDone message.  This message is only sent if the server
      requests a certificate.  If no suitable certificate is available,
      the client MUST send a certificate message containing no
      certificates.  That is, the certificate_list structure has a
      length of zero.  If the client does not send any certificates, the
      server MAY at its discretion自由裁量权 either continue the handshake without
      client authentication, or respond with a fatal handshake_failure
      alert.  Also, if some aspect of the certificate chain was
      unacceptable (e.g., it was not signed by a known, trusted CA), the
      server MAY at its discretion either continue the handshake
      (considering the client unauthenticated) or send a fatal alert.

      Client certificates are sent using the Certificate structure
      defined in Section 7.4.2.

Meaning of this message:

      This message conveys传送 the client's certificate chain to the server;
      the server will use it when verifying the CertificateVerify
      message (when the client authentication is based on signing) or
      calculating the premaster secret (for non-ephemeral Diffie-
      Hellman).  The certificate MUST be appropriate for the negotiated
      cipher suite's key exchange algorithm, and any negotiated
      extensions.

   In particular:

   -  The certificate type MUST be X.509v3, unless explicitly negotiated
      otherwise (e.g., [TLSPGP]).

   -  The end-entity certificate's public key (and associated
      restrictions) has to be compatible with the certificate types
      listed in CertificateRequest:

      Client Cert. Type   Certificate Key Type

      rsa_sign            RSA public key; the certificate MUST allow the
                          key to be used for signing with the signature
                          scheme and hash algorithm that will be
                          employed in the certificate verify message.

      dss_sign            DSA public key; the certificate MUST allow the
                          key to be used for signing with the hash
                          algorithm that will be employed in the
                          certificate verify message.

      ecdsa_sign          ECDSA-capable public key; the certificate MUST
                          allow the key to be used for signing with the
                          hash algorithm that will be employed in the
                          certificate verify message; the public key
                          MUST use a curve and point format supported by
                          the server.

      rsa_fixed_dh        Diffie-Hellman public key; MUST use the same
      dss_fixed_dh        parameters as server's key.

      rsa_fixed_ecdh      ECDH-capable public key; MUST use the
      ecdsa_fixed_ecdh    same curve as the server's key, and MUST use a
                          point format supported by the server.

   -  If the certificate_authorities list in the certificate request
      message was non-empty, one of the certificates in the certificate
      chain SHOULD be issued by one of the listed CAs.

-  The certificates MUST be signed using an acceptable hash/
      signature algorithm pair, as described in Section 7.4.4.  Note
      that this relaxes the constraints on certificate-signing
      algorithms found in prior versions of TLS.

   Note that, as with the server certificate, there are certificates
   that use algorithms/algorithm combinations that cannot be currently
   used with TLS.

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 MUST immediately follow the client key exchange message.

   Structure of this message:

      struct {
           digitally-signed struct {
               opaque handshake_messages[handshake_messages_length];
           }
      } CertificateVerify;

      Here handshake_messages refers to all handshake messages sent or
      received, starting at client hello and 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 Section 7.4) exchanged thus
      far.  Note that this requires both sides to either buffer the
      messages or compute running hashes for all potential hash
      algorithms up to the time of the CertificateVerify computation.
      Servers can minimize this computation cost by offering a
      restricted set of digest algorithms in the CertificateRequest
      message.

      The hash and signature algorithms used in the signature MUST be
      one of those present in the supported_signature_algorithms field
      of the CertificateRequest message.  In addition, the hash and
      signature algorithms MUST be compatible with the key in the
      client's end-entity certificate.  RSA keys MAY be used with any
      permitted hash algorithm, subject to restrictions in the
      certificate, if any.

      Because DSA signatures do not contain any secure indication of
      hash algorithm, there is a risk of hash substitution if multiple
      hashes may be used with any key.  Currently, DSA [DSS] may only be
      used with SHA-1.  Future revisions of DSS [DSS-3] are expected to
      allow the use of other digest algorithms with DSA, as well as
      guidance as to which digest algorithms should be used with each
      key size.  In addition, future revisions of [PKIX] may specify
      mechanisms for certificates to indicate which digest algorithms
      are to be used with DSA.

SSL/TLS协议运行机制的概述

上面第一项的随机数，是整个握手阶段出现的第三个随机数，又称"pre-master key"。有了它以后，客户端和服务器就同时有了三个随机数，接着双方就用事先商定的加密方法，各自生成本次会话所用的同一把"会话密钥"。

至于为什么一定要用三个随机数，来生成"会话密钥"，dog250解释得很好：

"不管是客户端还是服务器，都需要随机数，这样生成的密钥才不会每次都一样。由于SSL协议中证书是静态的，因此十分有必要引入一种随机因素来保证协商出来的密钥的随机性。

对于RSA密钥交换算法来说，pre-master-key本身就是一个随机数，再加上hello消息中的随机，三个随机数通过一个密钥导出器最终导出一个对称密钥。

pre master的存在在于SSL协议不信任每个主机都能产生完全随机的随机数，如果随机数不随机，那么pre master secret就有可能被猜出来，那么仅适用pre master secret作为密钥就不合适了，因此必须引入新的随机因素，那么客户端和服务器加上pre 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
   computed.

      master_secret = PRF(pre_master_secret, "master secret",
                          ClientHello.random + ServerHello.random)
                          [0..47];

   The master secret is always exactly 48 bytes in length.  The length
   of the premaster secret will vary depending on key exchange method.

ClientHello和ServerHello阶段分别生成了一个随机数，然后Client Key Exchange Message的时候生成了pre-master。用到的三个随机数

Meaning of this message:

      With this message, the premaster secret is set, either by direct
      transmission of the RSA-encrypted secret or by the transmission of
      Diffie-Hellman parameters that will allow each side to agree upon
      the same premaster secret.

      When the client is using an ephemeral Diffie-Hellman exponent,
      then this message contains the client's Diffie-Hellman public
      value.  If the client is sending a certificate containing a static
      DH exponent (i.e., it is doing fixed_dh client authentication),
      then this message MUST be sent but MUST be empty.

   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
      definition.

7.4.7.1.  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, and sends the result in
      an encrypted premaster secret message.  This structure is a
      variant of the ClientKeyExchange message and is not a message in
      itself.

7.4.7.2.  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, and not a message in itself.