multiple of 8 bytes (the block length). The padding length
can be 6, 14, 22, and so on, through 254. If the padding
length were the minimum necessary, 6, the padding would be 6
bytes, each containing the value 6. Thus, the last 8 octets
of the GenericBlockCipher before block encryption would be
xx 06 06 06 06 06 06 06, where xx is the last octet of the
MAC.
Note: With block ciphers in CBC mode (Cipher Block Chaining), it is
critical that the entire plaintext of the record be known
before any ciphertext is transmitted. Otherwise, it is
possible for the attacker to mount the attack described in
[CBCATT].
Implementation Note: Canvel et al. [CBCTIME] have demonstrated a
timing attack on CBC padding based on the time
required to compute the MAC. In order to defend
against this attack, implementations MUST ensure
that record processing time is essentially the
same whether or not the padding is correct. In
general, the best way to do this is to compute
the MAC even if the padding is incorrect, and
only then reject the packet. For instance, if
the pad appears to be incorrect, the
implementation might assume a zero-length pad
and then compute the MAC. This leaves a small
timing channel, since MAC performance depends to
some extent on the size of the data fragment,
but it is not believed to be large enough to be
exploitable, due to the large block size of
existing MACs and the small size of the timing
signal.
6.3. Key Calculation
The Record Protocol requires an algorithm to generate keys, and MAC
secrets from the security parameters provided by the handshake
protocol.
The master secret is hashed into a sequence of secure bytes, which
are assigned to the MAC secrets and keys required by the current
connection state (see Appendix A.6). CipherSpecs require a client
write MAC secret, a server write MAC secret, a client write key, and
a server write key, each of which is generated from the master secret
in that order. Unused values are empty.
When keys and MAC secrets are generated, the master secret is used as
an entropy source.
To generate the key material, compute
key_block = PRF(SecurityParameters.master_secret,
"key expansion",
SecurityParameters.server_random +
SecurityParameters.client_random);
until enough output has been generated. Then the key_block is
partitioned as follows:
client_write_MAC_secret[SecurityParameters.hash_size]
server_write_MAC_secret[SecurityParameters.hash_size]
client_write_key[SecurityParameters.key_material_length]
server_write_key[SecurityParameters.key_material_length]
Implementation note: The currently defined cipher suite that requires
the most material is AES_256_CBC_SHA, defined in [TLSAES]. It
requires 2 x 32 byte keys, 2 x 20 byte MAC secrets, and 2 x 16 byte
Initialization Vectors, for a total of 136 bytes of key material.
7. The TLS Handshaking Protocols
TLS has three subprotocols that are used to allow peers to agree upon
security parameters for the record layer, to authenticate themselves,
to instantiate negotiated security parameters, and to 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 the
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 MUST 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).
Note: If a rehandshake occurs while data is flowing on a connection,
the communicating parties may continue to send data using the
old CipherSpec. However, once the ChangeCipherSpec has been
sent, the new CipherSpec MUST be used. The first side to send
the ChangeCipherSpec does not know that the other side has
finished computing the new keying material (e.g., if it has to
perform a time consuming public key operation). Thus, a small
window of time, during which the recipient must buffer the
data, MAY exist. In practice, with modern machines this
interval is likely to be fairly short.
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),
no_certificate_RESERVED (41),
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_RESERVED(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. Note that as of TLS 1.1,
failure to properly close a connection no longer requires that a
session not be resumed. This is a change from TLS 1.0 to conform
with widespread implementation practice.
Either party may initiate a close by sending a close_notify alert.
Any data received after a closure alert is ignored.
Unless some other fatal alert has been transmitted, each party is
required to send a close_notify alert before closing the write side
of the connection. The other party MUST 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.
Note: 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 a fatal alert message, both
parties immediately close the connection. Servers and clients MUST
forget any session-identifiers, keys, and secrets associated with a
failed connection. Thus, any connection terminated with a fatal
alert MUST NOT be resumed. 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 alert also MUST be returned if an alert is sent because
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.
decryption_failed
This alert MAY be returned if 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.
Note: Differentiating between bad_record_mac and decryption_failed
alerts may permit certain attacks against CBC mode as used in
TLS [CBCATT]. It is preferable to uniformly use the
bad_record_mac alert to hide the specific type of the error.
record_overflow
A TLSCiphertext record was received that 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.
no_certificate_RESERVED
This alert was used in SSLv3 but not in TLS. It should not be
sent by compliant implementations.
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_RESERVED
This alert was used in TLS 1.0 but not TLS 1.1.
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 (such as a memory allocation failure) makes it
impossible to continue. 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 is 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 that are transmitted
with a level of fatal MUST be treated as fatal messages.
New alert values MUST be defined by RFC 2434 Standards Action. See
Section 11 for IANA Considerations for alert values.
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 whether TLS
always negotiates the strongest possible connection between two
peers. There are a number of ways in which 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, one SHOULD never send data over a link encrypted with 40-bit
security unless one feels 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 by defining the use of the
messages to allow the client and server to agree upon a shared
secret. This secret MUST be quite long; currently defined key
exchange methods exchange secrets that 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 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 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.) Application data MUST NOT be sent prior to the