summaryrefslogtreecommitdiff
diff options
context:
space:
mode:
authorNikos Mavrogiannopoulos <nmav@redhat.com>2018-04-23 10:07:32 +0200
committerNikos Mavrogiannopoulos <nmav@redhat.com>2018-05-03 11:31:48 +0200
commit9789921091b1b94b7facf75c4a9e826459af23c4 (patch)
treeb6759ec43051bd28454bb2b9a13e0945d409a9ea
parent6bea05884b208181883c90460a713c217582057e (diff)
downloadgnutls-9789921091b1b94b7facf75c4a9e826459af23c4.tar.gz
doc: clarified re-handshake details under TLS1.2 server
Signed-off-by: Nikos Mavrogiannopoulos <nmav@redhat.com>
-rw-r--r--doc/cha-gtls-app.texi6
1 files changed, 5 insertions, 1 deletions
diff --git a/doc/cha-gtls-app.texi b/doc/cha-gtls-app.texi
index 811f84db6c..c775f4b2c1 100644
--- a/doc/cha-gtls-app.texi
+++ b/doc/cha-gtls-app.texi
@@ -1788,7 +1788,11 @@ A server which wants to instruct the client to re-authenticate, should call
@funcref{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 @funcref{gnutls_safe_renegotiation_status} and
-the discussion in @ref{Safe renegotiation}).
+the discussion in @ref{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.
@showfuncdesc{gnutls_rehandshake}