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