diff options
author | Lutz Jänicke <jaenicke@openssl.org> | 2001-08-16 14:27:55 +0000 |
---|---|---|
committer | Lutz Jänicke <jaenicke@openssl.org> | 2001-08-16 14:27:55 +0000 |
commit | 9e09eebf94c933686077a1b1b2d60248acb9ba67 (patch) | |
tree | 173d4f8da3e235a74c0ab70edd38daed9f9b4387 /doc | |
parent | 45a2f9390634d243dfe631e174b1c2accf39ae8d (diff) | |
download | openssl-9e09eebf94c933686077a1b1b2d60248acb9ba67.tar.gz |
Better description of the behaviour of SSL_shutdown() as it is now, broken
or not.
Diffstat (limited to 'doc')
-rw-r--r-- | doc/ssl/SSL_shutdown.pod | 45 |
1 files changed, 38 insertions, 7 deletions
diff --git a/doc/ssl/SSL_shutdown.pod b/doc/ssl/SSL_shutdown.pod index c4ae6704e7..ada25c8cae 100644 --- a/doc/ssl/SSL_shutdown.pod +++ b/doc/ssl/SSL_shutdown.pod @@ -22,10 +22,38 @@ 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 behaviour of SSL_shutdown() depends on the underlying BIO. +The shutdown procedure consists of 2 steps: the sending of the "close notify" +shutdown alert and the receipt ion of the peer's "close notify" shutdown +alert: + +=over 4 + +=item When the application is the first party to send the "close notify" +alert, SSL_shutdown() will only send the alert and the 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. In order to +complete the 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 call of e.g. +B<SSL_read(3)|SSL_read(3)>, SSL_shutdown() will send the "close notify" +alert and will immediately return with 1. + +=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 has been finished or an error occurred. +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() @@ -46,19 +74,22 @@ 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 successful. Call SSL_get_error() with the return -value B<ret> to find out the reason. +The shutdown is not yet finished. Call SSL_shutdown() for a second time. +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 -1 The shutdown was not successful because a fatal error occurred either -at the protocol level or a connection failure occurred. It can also occur of +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<ret> to find out the reason. +Call L<SSL_get_error(3)|SSL_get_error(3)> with the return value B<ret> +to find out the reason. =back |