Next: TLS 1.3 re-authentication and re-key, Previous: Certificate verification, Up: Advanced topics [Contents][Index]
In TLS 1.2 or earlier there is no distinction between re-key, 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
gnutls_init.
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.
To make re-authentication transparent to the application when requested
by the server, use the GNUTLS_AUTO_REAUTH flag on the
gnutls_init call. In that case the re-authentication will happen
in the call of gnutls_record_recv that received the
reauthentication request.
session: is a gnutls_session_t type.
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.
Since: 2.10.0
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). A server could also encounter the GNUTLS_E_REHANDSHAKE error code while receiving data. That indicates a client-initiated re-handshake request. In that case the server could ignore that request, perform handshake (unsafe when done generally), or even drop the connection.
session: is a gnutls_session_t type.
This function can only be called in server side, and instructs a TLS 1.2 or earlier client to renegotiate parameters (perform a handshake), by sending a hello request message.
If this function succeeds, the calling application
should call gnutls_record_recv() until GNUTLS_E_REHANDSHAKE
is returned to clear any pending data. If the GNUTLS_E_REHANDSHAKE
error code is not seen, then the handshake request was
not followed by the peer (the TLS protocol does not require
the client to do, and such compliance should be handled
by the application protocol).
Once the GNUTLS_E_REHANDSHAKE error code is seen, the
calling application should proceed to calling
gnutls_handshake() to negotiate the new
parameters.
If the client does not wish to renegotiate parameters he
may reply with an alert message, and in that case the return code seen
by subsequent gnutls_record_recv() will be
GNUTLS_E_WARNING_ALERT_RECEIVED with the specific alert being
GNUTLS_A_NO_RENEGOTIATION . A client may also choose to ignore
this request.
Under TLS 1.3 this function is equivalent to gnutls_session_key_update()
with the GNUTLS_KU_PEER flag. In that case subsequent calls to
gnutls_record_recv() will not return GNUTLS_E_REHANDSHAKE , and
calls to gnutls_handshake() in server side are a no-op.
This function always fails with GNUTLS_E_INVALID_REQUEST when
called in client side.
Returns: GNUTLS_E_SUCCESS on success, otherwise a negative error code.
Next: TLS 1.3 re-authentication and re-key, Previous: Certificate verification, Up: Advanced topics [Contents][Index]