RFC 2246
The TLS Protocol Version 1.0
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 connections.
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.4.9). 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 { close_notify(0), unexpected_message(10), bad_record_mac(20), decryption_failed(21), record_overflow(22),
decompression_failure(30),
handshake_failure(40),
bad_certificate(42),
unsupported_certificate(43),
certificate_revoked(44),
certificate_expired(45),
certificate_unknown(46),
illegal_parameter(47),
unknown_ca(48),
access_denied(49),
decode_error(50),
decrypt_error(51),
export_restriction(60),
protocol_version(70),
insufficient_security(71),
internal_error(80),
user_canceled(90),
no_renegotiation(100),
(255)
} 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.
close_notify
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.
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
defined:
unexpected_message
An inappropriate message was received. This alert is always fatal
and should never be observed in communication between proper
implementations.
bad_record_mac
This alert is returned if a record is received with an incorrect
MAC. This message is always fatal.
decryption_failed
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.
record_overflow
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.
decompression_failure
The decompression function received improper input (e.g. data
that would expand to excessive length). This message is always
fatal.
handshake_failure
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.
bad_certificate
A certificate was corrupt, contained signatures that did not
verify correctly, etc.
unsupported_certificate
A certificate was of an unsupported type.
certificate_revoked
A certificate was revoked by its signer.
certificate_expired
A certificate has expired or is not currently valid.
certificate_unknown
Some other (unspecified) issue arose in processing the
certificate, rendering it unacceptable.
illegal_parameter
A field in the handshake was out of range or inconsistent with
other fields. This is always fatal.
unknown_ca
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.
access_denied
A valid certificate was received, but when access control was
applied, the sender decided not to proceed with negotiation.
This message is always fatal.
decode_error
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.
decrypt_error
A handshake cryptographic operation failed, including being
unable to correctly verify a signature, decrypt a key exchange,
or validate a finished message.
export_restriction
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.
protocol_version
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.
insufficient_security
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
fatal.
internal_error
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.
user_canceled
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.
no_renegotiation
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
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.
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 ServerHello.random. 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 length. 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
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 -------->
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 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. 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 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.
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) 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, 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 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.1 (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 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 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.
7.4.1.3. 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;
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.1 (See
Appendix E for details about backward compatibility).
random
This structure is generated by the server and must be different
from (and independent of) 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 which 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.
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
signing.
DHE_DSS DSS public key.
DHE_DSS_EXPORT DSS public key.
DHE_RSA RSA public key which can be used for
signing.
DHE_RSA_EXPORT RSA public key which can be used for
signing.
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;
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 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)
DHE_DSS
DHE_DSS_EXPORT
DHE_RSA
DHE_RSA_EXPORT
DH_anon
It is not legal to send the server key exchange message for the
following key exchange methods:
RSA
RSA_EXPORT (when the public key in the server certificate is
less than or equal to 512 bits in length)
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 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;
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;
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);
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
message).
Structure of this message:
enum {
rsa_sign(1), dss_sign(2), rsa_fixed_dh(3), dss_fixed_dh(4),
(255)
} ClientCertificateType;
opaque DistinguishedName<1..2^16-1>;
struct {
ClientCertificateType certificate_types<1..2^8-1>;
DistinguishedName certificate_authorities<3..2^16-1>;
} CertificateRequest;
certificate_types
This field is a list of the types of certificates requested,
sorted in order of the server's preference.
certificate_authorities
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;
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 exchange. 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 data. 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. struct { select (KeyExchangeAlgorithm) { case rsa: EncryptedPreMasterSecret; case diffie_hellman: ClientDiffieHellmanPublic;
} exchange_keys;
} ClientKeyExchange;
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 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
itself.
Structure of this message:
struct {
ProtocolVersion client_version;
opaque random[46];
} PreMasterSecret;
client_version
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.
random
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.
pre_master_secret
This random value is generated by the client and is used to
generate the master secret, as specified in Section 8.1.
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, not a message in itself.
Structure of this message:
enum { implicit, explicit } PublicValueEncoding;
implicit
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.
explicit
Yc needs to be sent.
struct {
select (PublicValueEncoding) {
case implicit: struct { };
case explicit: opaque dh_Yc<1..2^16-1>;
} dh_public;
} ClientDiffieHellmanPublic;
dh_Yc
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;
The Signature type is defined in 7.4.3.
CertificateVerify.signature.md5_hash
MD5(handshake_messages);
Certificate.signature.sha_hash
SHA(handshake_messages);
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;
verify_data
PRF(master_secret, finished_label, MD5(handshake_messages) +
SHA-1(handshake_messages)) [0..11];
finished_label
For Finished messages sent by the client, the string "client
finished". For Finished messages sent by the server, the
string "server finished".
handshake_messages
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.
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
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.
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 above. 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 suite TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA. 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 layer.
(next page on part 3)
