In TLS there is no distinction between rekey, re-authentication, and re-negotiation.
All of these use cases are handled by the TLS’ rehandshake process. For that reason
in GnuTLS rehandshake is not transparent to the application, and the application
must explicitly take control of that process. In addition GnuTLS since version 3.5.0 will not
allow the peer to switch identities during a rehandshake.
The threat addressed by that behavior depends on the application protocol,
but primarily it protects applications from being misled
by a rehandshake which switches the peer’s identity. Applications can
disable this protection by using the
GNUTLS_ALLOW_ID_CHANGE flag in
The following paragraphs explain how to safely use the rehandshake process.
According to the TLS specification a client may initiate a rehandshake at any time. That can be achieved by calling gnutls_handshake and rely on its return value for the outcome of the handshake (the server may deny a rehandshake). If a server requests a re-handshake, then a call to gnutls_record_recv will return GNUTLS_E_REHANDSHAKE in the client, instructing it to call gnutls_handshake. To deny a rehandshake request by the server it is recommended to send a warning alert of type GNUTLS_A_NO_RENEGOTIATION.
Due to limitations of early protocol versions, it is required to check whether safe renegotiation is in place, i.e., using gnutls_safe_renegotiation_status, which ensures that the server remains the same as the initial.
session: is a
Can be used to check whether safe renegotiation is being used in the current session.
Returns: 0 when safe renegotiation is not used and non (0) when safe renegotiation is used.
A server which wants to instruct the client to re-authenticate, should call gnutls_rehandshake and wait for the client to re-authenticate. It is recommended to only request re-handshake when safe renegotiation is enabled for that session (see gnutls_safe_renegotiation_status and the discussion in Safe renegotiation).
session: is a
This function will renegotiate security parameters with the client. This should only be called in case of a server.
This message informs the peer that we want to renegotiate parameters (perform a handshake).
If this function succeeds (returns 0), you must call the
gnutls_handshake() function in order to negotiate the new
Since TLS is full duplex some application data might have been
sent during peer’s processing of this message. In that case
one should call
gnutls_record_recv() until GNUTLS_E_REHANDSHAKE
is returned to clear any pending data. Care must be taken, if
rehandshake is mandatory, to terminate if it does not start after
If the client does not wish to renegotiate parameters he
should reply with an alert message, thus the return code will be
GNUTLS_E_WARNING_ALERT_RECEIVED and the alert will be
GNUTLS_A_NO_RENEGOTIATION . A client may also choose to ignore
GNUTLS_E_SUCCESS on success, otherwise a negative error code.