X-Git-Url: https://git.librecmc.org/?a=blobdiff_plain;f=doc%2Fssl%2FSSL_shutdown.pod;h=89911acbcac89a89c8de068297be4b7f7858b4ef;hb=5a84b7fc2db33cdefc5a7b62f0169f2c08fb3d9b;hp=be1166b596078ae8b56735fb9e01f4aa7675e430;hpb=cc99526db1ee5b948736f6b07958a786fec1240b;p=oweals%2Fopenssl.git diff --git a/doc/ssl/SSL_shutdown.pod b/doc/ssl/SSL_shutdown.pod index be1166b596..89911acbca 100644 --- a/doc/ssl/SSL_shutdown.pod +++ b/doc/ssl/SSL_shutdown.pod @@ -2,7 +2,7 @@ =head1 NAME -SSL_shutdown - Shut down a TLS connection +SSL_shutdown - shut down a TLS/SSL connection =head1 SYNOPSIS @@ -12,24 +12,80 @@ SSL_shutdown - Shut down a TLS connection =head1 DESCRIPTION -SSL_shutdown() shuts down an active TLS connection. It sends the shutdown -alert to the peer. The behaviour of SSL_shutdown() depends on the underlying -BIO. +SSL_shutdown() shuts down an active TLS/SSL connection. It sends the +"close notify" shutdown alert to the peer. -If the underlying BIO is B, SSL_shutdown() will only return, once the -handshake has been finished or an error occured. +=head1 NOTES -If the underlying BIO is B, SSL_shutdown() will also return, +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 it was +already processed implicitly inside another function +(L), 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 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, SSL_shutdown() will only return once the +handshake step has been finished or an error occurred. + +If the underlying BIO is B, 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 SSL_ERROR_WANT_READ or -SSL_ERROR_WANT_WRITE. The calling process then must repeat the call after +return value of SSL_shutdown() will yield B or +B. 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. +When "quiet shutdown" is enabled, SSL_shutdown() will always succeed +and return 1. + =head1 RETURN VALUES The following return values can occur: @@ -38,25 +94,32 @@ The following return values can occur: =item 1 -The shutdown was successfully completed. +The shutdown was successfully completed. The "close notify" alert was sent +and the peer's "close notify" alert was received. =item 0 -The shutdown was not successfull. Call SSL_get_error() with the return -value B to find out the reason. +The shutdown is not yet finished. Call SSL_shutdown() for a second time, +if a bidirectional shutdown shall be performed. +The output of L may be misleading, as an +erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred. =item -1 -The shutdown was not successfull, because a fatal error occured either -at the protocol level or a connection failure occured. It can also occure of +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 SSL_get_error() with the return value B to find out the reason. +Call L with the return value B +to find out the reason. =back =head1 SEE ALSO L, L, -L, L, L +L, L, +L, +L, L, +L, L =cut