initiate a new TLS handshake
When called from the client side, SSL_renegotiate
schedules a completely new handshake over an existing TLS connection. The next
time an I/O operation such as SSL_read
() takes place on the connection, a
check is performed to confirm that it is a suitable time to start a
renegotiation. If so, a new handshake is initiated immediately. An existing
session associated with the connection is not resumed.
This function is automatically called by
renegotiation byte count set by
or the timeout set by
When called from the client side,
() is similar to
() except that resuming the
session associated with the current connection is attempted in the new
When called from the server side, SSL_renegotiate
identically. They both schedule a request for a new handshake to be sent to
the client. The next time an I/O operation is performed, the same checks as on
the client side are performed and then, if appropriate, the request is sent.
The client may or may not respond with a new handshake and it may or may not
attempt to resume an existing session. If a new handshake is started, it is
handled transparently during any I/O function.
If a LibreSSL client receives a renegotiation request from a server, it is also
handled transparently during any I/O function. The client attempts to resume
the current session in the new handshake. For historical reasons, DTLS clients
do not attempt to resume the session in the new handshake.
() return 1 on success
or 0 on error.
() returns 1 if a
renegotiation or renegotiation request has been scheduled but not yet acted
on, or 0 otherwise.
() is available in all versions of