diff options
author | Kurt Roeckx <kurt@roeckx.be> | 2018-03-31 14:43:01 +0200 |
---|---|---|
committer | Kurt Roeckx <kurt@roeckx.be> | 2018-04-01 21:07:06 +0200 |
commit | 2f6f913e9e02441245c974d7c5abe57f37c0420e (patch) | |
tree | 494f4addef322ea11a0d84eb46290d635da5a3f9 /doc | |
parent | 094925de1ecfcfb8019b21994c45f3dc00ab4e2c (diff) |
Update documentation on how to close a connection
Reviewed-by: Bernd Edlinger <bernd.edlinger@hotmail.de>
GH: #5823
Diffstat (limited to 'doc')
-rw-r--r-- | doc/man3/SSL_get_error.pod | 9 | ||||
-rw-r--r-- | doc/man3/SSL_shutdown.pod | 65 |
2 files changed, 46 insertions, 28 deletions
diff --git a/doc/man3/SSL_get_error.pod b/doc/man3/SSL_get_error.pod index 4e26514a22..688f772afa 100644 --- a/doc/man3/SSL_get_error.pod +++ b/doc/man3/SSL_get_error.pod @@ -38,11 +38,10 @@ if and only if B<ret E<gt> 0>. =item SSL_ERROR_ZERO_RETURN -The TLS/SSL connection has been closed. -If the protocol version is SSL 3.0 or higher, this result code is returned only -if a closure alert has occurred in the protocol, i.e. if the connection has been -closed cleanly. -Note that in this case B<SSL_ERROR_ZERO_RETURN> does not necessarily +The TLS/SSL peer has closed the connection for writing by sending the +"close notify" alert. +No more data can be read. +Note that B<SSL_ERROR_ZERO_RETURN> does not necessarily indicate that the underlying transport has been closed. =item SSL_ERROR_WANT_READ, SSL_ERROR_WANT_WRITE diff --git a/doc/man3/SSL_shutdown.pod b/doc/man3/SSL_shutdown.pod index c40956c211..5d467c88bf 100644 --- a/doc/man3/SSL_shutdown.pod +++ b/doc/man3/SSL_shutdown.pod @@ -35,35 +35,52 @@ performed, so that the peers stay synchronized. SSL_shutdown() supports both uni- and bidirectional shutdown by its 2 step behaviour. -=over 4 +SSL_shutdown() only closes the write direction. +It is not possible to call SSL_write() after calling SSL_shutdown(). +The read direction is closed by the peer. + +=head2 First to close the connection -=item When the application is the first party to send the "close notify" +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 +be kept in the 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, the peer needs +to send back a "close notify" alert. +The SSL_RECEIVED_SHUTDOWN flag will be set after receiving and processing +it. +SSL_shutdown() will return 1 when it has been received. + +The peer is still allowed to send data after receiving the "close notify" +event. +If the peer did send data it needs to be processed by calling SSL_read() +before calling SSL_shutdown() a second time. +SSL_read() will indicate the end of the peer data by returning <= 0 +and SSL_get_error() returning SSL_ERROR_ZERO_RETURN. +It is recommended to call SSL_read() between SSL_shutdown() calls. + +=head2 Peer closes the connection + +If the peer already sent the "close notify" alert B<and> it was already processed implicitly inside another function (L<SSL_read(3)>), the SSL_RECEIVED_SHUTDOWN flag is set. +SSL_read() will return <= 0 in that case, and SSL_get_error() will return +SSL_ERROR_ZERO_RETURN. 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)> call. -=back +=head1 NOTES -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). +It is recommended to do a bidirectional shutdown by checking the return value +of SSL_shutdown() and call it again until it returns 1 or a fatal error. 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. @@ -92,8 +109,9 @@ The following return values can occur: =item Z<>0 -The shutdown is not yet finished. Call SSL_shutdown() for a second time, -if a bidirectional shutdown shall be performed. +The shutdown is not yet finished: the "close notify" was send but the peer +did not send it back yet. +Call SSL_shutdown() again to do a bidirectional shutdown. The output of L<SSL_get_error(3)> may be misleading, as an erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred. @@ -104,11 +122,12 @@ 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)> with the return value B<ret> -to find out the reason. +The shutdown was not successful. +Call L<SSL_get_error(3)> with the return value B<ret> to find out the reason. +It can occur if an action is needed to continue the operation for non-blocking +BIOs. + +It can also occur when not all data was read using SSL_read(). =back |