diff options
Diffstat (limited to 'doc/ssl/SSL_shutdown.pod')
| -rw-r--r-- | doc/ssl/SSL_shutdown.pod | 125 |
1 files changed, 0 insertions, 125 deletions
diff --git a/doc/ssl/SSL_shutdown.pod b/doc/ssl/SSL_shutdown.pod deleted file mode 100644 index efbff5a0a323..000000000000 --- a/doc/ssl/SSL_shutdown.pod +++ /dev/null @@ -1,125 +0,0 @@ -=pod - -=head1 NAME - -SSL_shutdown - shut down a TLS/SSL connection - -=head1 SYNOPSIS - - #include <openssl/ssl.h> - - int SSL_shutdown(SSL *ssl); - -=head1 DESCRIPTION - -SSL_shutdown() shuts down an active TLS/SSL connection. It sends the -"close notify" shutdown alert to the peer. - -=head1 NOTES - -SSL_shutdown() tries to send the "close notify" shutdown alert to the peer. -Whether the operation succeeds or not, the SSL_SENT_SHUTDOWN flag is set and -a currently open session is considered closed and good and will be kept in the -session cache for further reuse. - -The shutdown procedure consists of 2 steps: the sending of the "close notify" -shutdown alert and the reception of the peer's "close notify" shutdown -alert. According to the TLS standard, it is acceptable for an application -to only send its shutdown alert and then close the underlying connection -without waiting for the peer's response (this way resources can be saved, -as the process can already terminate or serve another connection). -When the underlying connection shall be used for more communications, the -complete shutdown procedure (bidirectional "close notify" alerts) must be -performed, so that the peers stay synchronized. - -SSL_shutdown() supports both uni- and bidirectional shutdown by its 2 step -behaviour. - -=over 4 - -=item When the application is the first party to send the "close notify" -alert, SSL_shutdown() will only send the alert and then set the -SSL_SENT_SHUTDOWN flag (so that the session is considered good and will -be kept in cache). SSL_shutdown() will then return with 0. If a unidirectional -shutdown is enough (the underlying connection shall be closed anyway), this -first call to SSL_shutdown() is sufficient. In order to complete the -bidirectional shutdown handshake, SSL_shutdown() must be called again. -The second call will make SSL_shutdown() wait for the peer's "close notify" -shutdown alert. On success, the second call to SSL_shutdown() will return -with 1. - -=item If the peer already sent the "close notify" alert B<and> it was -already processed implicitly inside another function -(L<SSL_read(3)|SSL_read(3)>), the SSL_RECEIVED_SHUTDOWN flag is set. -SSL_shutdown() will send the "close notify" alert, set the SSL_SENT_SHUTDOWN -flag and will immediately return with 1. -Whether SSL_RECEIVED_SHUTDOWN is already set can be checked using the -SSL_get_shutdown() (see also L<SSL_set_shutdown(3)|SSL_set_shutdown(3)> call. - -=back - -It is therefore recommended, to check the return value of SSL_shutdown() -and call SSL_shutdown() again, if the bidirectional shutdown is not yet -complete (return value of the first call is 0). As the shutdown is not -specially handled in the SSLv2 protocol, SSL_shutdown() will succeed on -the first call. - -The behaviour of SSL_shutdown() additionally depends on the underlying BIO. - -If the underlying BIO is B<blocking>, SSL_shutdown() will only return once the -handshake step has been finished or an error occurred. - -If the underlying BIO is B<non-blocking>, SSL_shutdown() will also return -when the underlying BIO could not satisfy the needs of SSL_shutdown() -to continue the handshake. In this case a call to SSL_get_error() with the -return value of SSL_shutdown() will yield B<SSL_ERROR_WANT_READ> or -B<SSL_ERROR_WANT_WRITE>. The calling process then must repeat the call after -taking appropriate action to satisfy the needs of SSL_shutdown(). -The action depends on the underlying BIO. When using a non-blocking socket, -nothing is to be done, but select() can be used to check for the required -condition. When using a buffering BIO, like a BIO pair, data must be written -into or retrieved out of the BIO before being able to continue. - -SSL_shutdown() can be modified to only set the connection to "shutdown" -state but not actually send the "close notify" alert messages, -see L<SSL_CTX_set_quiet_shutdown(3)|SSL_CTX_set_quiet_shutdown(3)>. -When "quiet shutdown" is enabled, SSL_shutdown() will always succeed -and return 1. - -=head1 RETURN VALUES - -The following return values can occur: - -=over 4 - -=item Z<>0 - -The shutdown is not yet finished. Call SSL_shutdown() for a second time, -if a bidirectional shutdown shall be performed. -The output of L<SSL_get_error(3)|SSL_get_error(3)> may be misleading, as an -erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred. - -=item Z<>1 - -The shutdown was successfully completed. The "close notify" alert was sent -and the peer's "close notify" alert was received. - -=item E<lt>0 - -The shutdown was not successful because a fatal error occurred either -at the protocol level or a connection failure occurred. It can also occur if -action is need to continue the operation for non-blocking BIOs. -Call L<SSL_get_error(3)|SSL_get_error(3)> with the return value B<ret> -to find out the reason. - -=back - -=head1 SEE ALSO - -L<SSL_get_error(3)|SSL_get_error(3)>, L<SSL_connect(3)|SSL_connect(3)>, -L<SSL_accept(3)|SSL_accept(3)>, L<SSL_set_shutdown(3)|SSL_set_shutdown(3)>, -L<SSL_CTX_set_quiet_shutdown(3)|SSL_CTX_set_quiet_shutdown(3)>, -L<SSL_clear(3)|SSL_clear(3)>, L<SSL_free(3)|SSL_free(3)>, -L<ssl(3)|ssl(3)>, L<bio(3)|bio(3)> - -=cut |