completion of the first handshake (before a cipher suite other
TLS_NULL_WITH_NULL_NULL is established).
Client Server
ClientHello -------->
ServerHello
Certificate*
ServerKeyExchange*
CertificateRequest*
<-------- ServerHelloDone
Certificate*
ClientKeyExchange
CertificateVerify*
[ChangeCipherSpec]
Finished -------->
[ChangeCipherSpec]
<-------- 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.
Client Server
ClientHello -------->
ServerHello
[ChangeCipherSpec]
<-------- Finished
[ChangeCipherSpec]
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;
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 is described only in its
first position. The one message that is not bound by these ordering
rules is 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.
New Handshake message type values MUST be defined via RFC 2434
Standards Action. See Section 11 for IANA Considerations for these
values.
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.
7.4.1.1. 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 MUST NOT be included in the message hashes that
are maintained throughout the handshake and used in the
finished messages and the certificate verify message.
7.4.1.2. 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;
gmt_unix_time The current time and date in standard UNIX 32-bit
format (seconds since the midnight starting Jan 1, 1970, GMT,
ignoring leap seconds) 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.
random_bytes
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,
from this connection, or from 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, and 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 it is
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 server.
opaque SessionID<0..32>;
Warning: 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 handshake.)
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;
client_version
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.2. (See
Appendix E for details about backward compatibility.)
random
A client-generated random structure.
session_id
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 if the
client wishes to generate new security parameters.
cipher_suites
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.
compression_methods
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 that a client hello message 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.
Note: For the intended use of trailing data in the ClientHello,
see RFC 3546 [TLSEXT].
7.4.1.3. Server Hello
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;
server_version
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.2. (See
Appendix E for details about backward compatibility.)
random
This structure is generated by the server and MUST be
independently generated from the ClientHello.random.
session_id
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.
cipher_suite
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.
compression_method 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 that matches the key exchange
method, as follows. Unless otherwise specified, the signing
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.
DHE_DSS DSS public key.
DHE_RSA RSA public key that can be used for
signing.
DH_DSS Diffie-Hellman key. The algorithm used
to sign the certificate MUST be DSS.
DH_RSA Diffie-Hellman key. The algorithm used
to sign the certificate MUST be RSA.
All certificate profiles and 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 that 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;
certificate_list
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 that 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:
DHE_DSS
DHE_RSA
DH_anon
It is not legal to send the server key exchange message for the
following key exchange methods:
RSA
DH_DSS
DH_RSA
Meaning of this message:
This message conveys cryptographic information to allow the client
to communicate the premaster secret: either an RSA public key with
which to encrypt the premaster secret, 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 that 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.
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;
rsa_modulus
The modulus of the server’s temporary RSA key.
rsa_exponent
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 */
dh_p
The prime modulus used for the Diffie-Hellman operation.
dh_g
The generator used for the Diffie-Hellman operation.
dh_Ys
The server’s Diffie-Hellman public value (g^X mod p).
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
Signature signed_params;
case rsa:
ServerRSAParams params;
Signature signed_params;
};
} ServerKeyExchange;
struct {
select (KeyExchangeAlgorithm) {
case diffie_hellman:
ServerDHParams params;
case rsa:
ServerRSAParams params;
};
} ServerParams;
params
The server’s key exchange parameters.
signed_params
For non-anonymous key exchanges, a hash of the corresponding
params value, with the signature appropriate to that hash
applied.
md5_hash
MD5(ClientHello.random + ServerHello.random + ServerParams);
sha_hash
SHA(ClientHello.random + ServerHello.random + ServerParams);