This document specifies an optional behavior of TLS implementations, dubbed False Start. It affects only protocol timing, not on-the-wire protocol data, and can be implemented unilaterally. The TLS False Start feature leads to a latency reduction of one round trip for certain handshakes.
A full TLS handshake as specified in RFC5246 requires two full protocol rounds (four flights) before the handshake is complete and the protocol parties may begin to send application data. Thus, using TLS can add a latency penalty of two network round-trip times for application protocols in which the client sends data first, such as HTTP. An abbreviated handshake (resuming an earlier TLS session) is complete after three flights, thus adding just one round- trip time if the client sends application data first.
This document describes a technique that alleviates the latency burden imposed by TLS: the TLS False Start. If certain conditions are met, application data can be sent when the handshake is only partially complete — i.e., when the sender has sent its own ChangeCipherSpec and Finished messages (thus having updated its TLS Record Protocol write state as negotiated in the handshake), but has yet to receive the other side's ChangeCipherSpec and Finished messages. (By section 7.4.9 of RFC5246, each party would have to delay sending application data until it has received and validated the other side's Finished message.) This achieves an improvement of one round-trip time
Accordingly, the latency penalty for using TLS with HTTP can be kept at one round-trip time regardless of whether a full handshake or an abbreviated handshake takes place.
In a False Start, when a party sends application data before it has received and verified the other party's Finished message, there are two possible outcomes:
The latter scenario makes it necessary to restrict when a False Start is allowed, as described in this document.
TLS False Start as described in detail in the subsequent sections, if implemented, is an optional feature.
A TLS implementation (not necessarily offering the False Start option itself) is defined to be “False Start compatible” if it tolerates receiving TLS records on the transport connection early, before the protocol has reached the state to process these. To successfully use False Start in a TLS connection, the other side has to be False Start compatible. Out-of-band knowledge that the peer is False Start compatible may be available, e.g. if this is mandated by specific application profile standards. As discussed in Appendix A, the requirement for False Start compatibility does not pose a hindrance in practice.
This section specifies a change to the behavior of TLS client implementations in full TLS handshakes.
When the client has sent its ChangeCipherSpec and Finished messages, its default behavior following RFC5246 is not to send application data until it has received the server's ChangeCipherSpec and Finished messages, which completes the handshake. With the False Start protocol modification, the client MAY send application data earlier (under the new Cipher Spec) if each of the following conditions is satisfied:
The rules for receiving application data from the server remain unchanged.
Note that the TLS client cannot infer the presence of an authenticated server until all handshake messages have been received. With False Start, unlike with the default handshake behavior, applications are able to send data before this point has been reached: from an application point of view, being able to send data does not imply that an authenticated peer is present. Accordingly, it is recommended that TLS implementations allow the application layer to query whether the handshake has completed.
This section specifies a change to the behavior of TLS server implementations in abbreviated TLS handshakes.
When the server has sent its ChangeCipherSpec and Finished messages, its default behavior following RFC5246 is not to send application data until it has received the client's ChangeCipherSpec and Finished messages, which completes the handshake. With the False Start protocol modification, the server MAY send application data earlier (under the new Cipher Spec) if each of the following conditions is satisfied:
The rules for receiving application data from the client remain unchanged.
Note that the TLS server cannot infer the presence of an authenticated client until all handshake messages have been received. With False Start, unlike with the default handshake behavior, applications are able to send data before this point has been reached: from an application point of view, being able to send data does not imply that an authenticated peer is present. Accordingly, it is recommended that TLS implementations allow the application layer to query whether the handshake has completed.
In a TLS handshake, the Finished messages serve to validate the entire handshake. These messages are based on a hash of the handshake so far processed by a PRF keyed with the new master secret (serving as a MAC), and are also sent under the new Cipher Spec with its keyed MAC, where the MAC key again is derived from the master secret. The protocol design relies on the assumption that any server and/or client authentication done during the handshake carries over to this. While an attacker could, for example, have changed the cipher suite list sent by the client to the server and thus influenced cipher suite selection (presumably towards a less secure choice) or could have made other modifications to handshake messages in transmission, the attacker would not be able to round off the modified handshake with a valid Finished message: every TLS cipher suite is presumed to key the PRF appropriately to ensure unforgeability. Once the handshake has been validated by verifying the Finished messages, this confirms that the handshake has not been tampered with, thus bootstrapping secure encryption (using algorithms as negotiated) from secure authentication.
Using False Start interferes with this approach of bootstrapping secure encryption from secure authentication, as application data may have already been sent before Finished validation confirms that the handshake has not been tampered with -- so there is generally no hope to be sure that communication with the expected peer is indeed taking place during the False Start. Instead, the security goal is to ensure that if anyone at all can decrypt the application data sent in a False Start, this must be the legitimate peer: while an attacker could be influencing the handshake (restricting cipher suite selection, modifying key exchange messages, etc.), the attacker should not be able to benefit from this. The TLS protocol already relies on such a security property for authentication -- with False Start, the same is needed for encryption. This motivates the following rules.
Clients and servers MUST NOT use the False Start protocol modification in a handshake unless the cipher suite uses a symmetric cipher that is considered cryptographically strong.
Implementations may have their own classification of ciphers (and may additionally allow the application layer to provide a classification), but generally symmetric ciphers with an effective key length of 128 bits or more can be considered strong. In RFC5246, this allows all cipher suites except those using the NULL or 3DES_EDE_CBC ciphers (specifically, it allows the cipher suites using RC4_128, AES_128_CBC, or AES_256_CBC). Implementations that support additional cipher suites have to be careful to whitelist only suitable symmetric ciphers; if in doubt, False Start should not be used with a given symmetric cipher.
While an attacker can change handshake messages to force a downgrade to a less secure symmetric cipher than otherwise would have been chosen, this rule ensures that in such a downgrade attack no application data will be sent under an insecure symmetric cipher. With respect to server-side False Start, if a client has negotiated a TLS session using weak symmetric cryptography, this rule prevents attackers from seeing the server encrypt more data under this session than normally (if an attacker makes up a ClientHello message asking to resume such a session, no False Start will happen).
Clients MUST NOT use the False Start protocol modification in a handshake unless the cipher suite uses a key exchange method that has been whitelisted for this use. Furthermore, when using client authentication, clients MUST NOT use the False Start protocol modification unless the client certificate type has been whitelisted for this use.
Implementations may have their own whitelists of key exchange methods and client certificate types (and may additionally allow the application layer to specify whitelists). Generally, out of the options from RFC5246 and RFC4492, the following whitelists are recommended:
However, if an implementation that supports only key exchange methods from [RFC5246] and [RFC4492] does not support any of the above key exchange methods, all of its supported key exchange methods can be whitelisted for False Start use. Care is required with any additional key exchange methods or client certificate types, as these may not have similar properties.
The recommended whitelists are such that if cryptographic algorithms suitable for forward secrecy would possibly be negotiated, no False Start will take place if the current handshake fails to provide forward secrecy. (Forward secrecy can be achieved using ephemeral Diffie-Hellman or ephemeral Elliptic-Curve Diffie-Hellman; there is no forward secrecy when a using key exchange method of RSA, RSA_PSK, DH_DSS, DH_RSA, ECDH_ECDSA, or ECDH_RSA, or a client certificate type of rsa_fixed_dh, dss_fixed_dh, rsa_fixed_ecdh, or ecdsa_fixed_ecdh.) As usual, the benefits of forward secrecy may need to be balanced against efficiency, and accordingly even implementations that support the above key exchange methods might whitelist further key exchange methods and client certificate types from [RFC5246] and [RFC4492].
False Start is implemented in NSS 3.12.9. A patch is available for OpenSSL. It is enabled by default in Google Chrome.
The following TLS implementations are know to be False Start incompatible:
In practice, this is not a significant problem. Google Chrome uses a blocklist of sites known to be incompatible in order to give them time to upgrade. This list is being slowly eliminated with the aim of having only a handful of entries by the end of 2011.
Wan-Teh Chang and Ben Laurie have contributed to this document.
The authors wish to thank Eric Rescorla for his comments on an earlier draft.