3.6.8 False Start

The TLS protocol was extended in [RFC7918] to allow the client to send data to server in a single round trip. This change however operates on the borderline of the TLS protocol security guarantees and should be used for the cases where the reduced latency outperforms the risk of an adversary intercepting the transferred data. In GnuTLS applications can use the GNUTLS_ENABLE_FALSE_START as option to gnutls_init to request an early return of the gnutls_handshake function. After that early return the application is expected to transfer any data to be piggybacked on the last handshake message.

After handshake’s early termination, the application is expected to transmit data using gnutls_record_send, and call gnutls_record_recv on any received data as soon, to ensure that handshake completes timely. That is, especially relevant for applications which set an explicit time limit for the handshake process via gnutls_handshake_set_timeout.

Note however, that the API ensures that the early return will not happen if the false start requirements are not satisfied. That is, on ciphersuites which are not enabled for false start or on insufficient key sizes, the handshake process will complete properly (i.e., no early return). To verify that false start was used you may use gnutls_session_get_flags and check for the GNUTLS_SFLAGS_FALSE_START flag. For GnuTLS the false start is enabled for the following key exchange methods (see [RFC7918] for rationale)

• DHE
• ECDHE

but only when the negotiated parameters exceed GNUTLS_SEC_PARAM_HIGH –see Table 6.7, and when under (D)TLS 1.2 or later.