blob: 7498d6efac847d1568585ba3e7848aa571256aab (
plain)
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
|
@deftypefun {int} {gnutls_rehandshake} (gnutls_session_t @var{session})
@var{session}: is a @code{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 @code{gnutls_record_recv()} until @code{GNUTLS_E_REHANDSHAKE}
is returned to clear any pending data. If the @code{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 @code{GNUTLS_E_REHANDSHAKE} error code is seen, the
calling application should proceed to calling
@code{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 @code{gnutls_record_recv()} will be
@code{GNUTLS_E_WARNING_ALERT_RECEIVED} with the specific alert being
@code{GNUTLS_A_NO_RENEGOTIATION} . A client may also choose to ignore
this request.
Under TLS 1.3 this function is equivalent to @code{gnutls_session_key_update()}
with the @code{GNUTLS_KU_PEER} flag. In that case subsequent calls to
@code{gnutls_record_recv()} will not return @code{GNUTLS_E_REHANDSHAKE} , and
calls to @code{gnutls_handshake()} in server side are a no-op.
This function always fails with @code{GNUTLS_E_INVALID_REQUEST} when
called in client side.
@strong{Returns:} @code{GNUTLS_E_SUCCESS} on success, otherwise a negative error code.
@end deftypefun
|
