=head1 DESCRIPTION
SSL_shutdown() shuts down an active TLS/SSL connection. It sends the
-"close notify" shutdown alert to the peer.
+close_notify shutdown alert to the peer.
=head1 NOTES
-SSL_shutdown() tries to send the "close notify" shutdown alert to the peer.
+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).
+The shutdown procedure consists of two steps: sending of the close_notify
+shutdown alert, and reception of the peer's close_notify shutdown alert.
+The order of those two steps depends on the application.
+
+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.
+This should only be done when it is known that the other side will not send more
+data, otherwise there is a risk of a truncation attack.
+
+When a client only writes and never reads from the connection, and the server
+has sent a session ticket to establish a session, the client might not be able
+to resume the session because it did not received and process the session ticket
+from the server.
+In case the application wants to be able to resume the session, it is recommended to
+do a complete shutdown procedure (bidirectional close_notify alerts).
+
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.
+complete shutdown procedure must be performed, so that the peers stay
+synchronized.
-SSL_shutdown() supports both uni- and bidirectional shutdown by its 2 step
-behaviour.
+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.
-=over 4
+=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).
+If successful, SSL_shutdown() will return 0.
+
+If a unidirectional shutdown is enough (the underlying connection shall be
+closed anyway), this first successful 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.
+
+The peer is still allowed to send data after receiving the close_notify
+event.
+When it is done sending data, it will send the close_notify alert.
+SSL_read() should be called until all data is received.
+SSL_read() will indicate the end of the peer data by returning <= 0
+and SSL_get_error() returning SSL_ERROR_ZERO_RETURN.
+
+=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_shutdown() will send the "close notify" alert, set the SSL_SENT_SHUTDOWN
-flag and will immediately return with 1.
+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.
+If successful, SSL_shutdown() will return 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
-
-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).
+=head1 NOTES
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.
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.
+After SSL_shutdown() returned 0, it is possible to call SSL_shutdown() again
+to wait for the peer's close_notify alert.
+SSL_shutdown() will return 1 in that case.
+However, it is recommended to wait for it using SSL_read() instead.
+
SSL_shutdown() can be modified to only set the connection to "shutdown"
-state but not actually send the "close notify" alert messages,
+state but not actually send the close_notify alert messages,
see L<SSL_CTX_set_quiet_shutdown(3)>.
When "quiet shutdown" is enabled, SSL_shutdown() will always succeed
and return 1.
=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 sent but the peer
+did not send it back yet.
+Call SSL_read() 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.
=item Z<>1
-The shutdown was successfully completed. The "close notify" alert was sent
-and the peer's "close notify" alert was received.
+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)> 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
=head1 COPYRIGHT
-Copyright 2000-2016 The OpenSSL Project Authors. All Rights Reserved.
+Copyright 2000-2018 The OpenSSL Project Authors. All Rights Reserved.
-Licensed under the OpenSSL license (the "License"). You may not use
+Licensed under the Apache License 2.0 (the "License"). You may not use
this file except in compliance with the License. You can obtain a copy
in the file LICENSE in the source distribution or at
L<https://www.openssl.org/source/license.html>.
projects / openssl.git / blobdiff