mirror of
https://github.com/openssl/openssl.git
synced 2024-12-27 06:21:43 +08:00
ff6e3a26f9
Reviewed-by: Tomas Mraz <tomas@openssl.org> Reviewed-by: Matt Caswell <matt@openssl.org> (Merged from https://github.com/openssl/openssl/pull/19897)
290 lines
12 KiB
Plaintext
290 lines
12 KiB
Plaintext
=pod
|
|
|
|
=head1 NAME
|
|
|
|
SSL_shutdown, SSL_shutdown_ex - shut down a TLS/SSL or QUIC connection
|
|
|
|
=head1 SYNOPSIS
|
|
|
|
#include <openssl/ssl.h>
|
|
|
|
int SSL_shutdown(SSL *ssl);
|
|
|
|
typedef struct ssl_shutdown_ex_args_st {
|
|
uint64_t quic_error_code;
|
|
const char *quic_reason;
|
|
} SSL_SHUTDOWN_EX_ARGS;
|
|
|
|
__owur int SSL_shutdown_ex(SSL *ssl, uint64_t flags,
|
|
const SSL_SHUTDOWN_EX_ARGS *args,
|
|
size_t args_len);
|
|
|
|
=head1 DESCRIPTION
|
|
|
|
SSL_shutdown() shuts down an active TLS/SSL connection. It sends 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.
|
|
|
|
Note that SSL_shutdown() must not be called if a previous fatal error has
|
|
occurred on a connection i.e. if SSL_get_error() has returned SSL_ERROR_SYSCALL
|
|
or SSL_ERROR_SSL.
|
|
|
|
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 must be performed, so that the peers stay
|
|
synchronized.
|
|
|
|
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.
|
|
|
|
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<nonblocking>, 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 nonblocking 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.
|
|
|
|
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,
|
|
see L<SSL_CTX_set_quiet_shutdown(3)>.
|
|
When "quiet shutdown" is enabled, SSL_shutdown() will always succeed
|
|
and return 1.
|
|
Note that this is not standard compliant behaviour.
|
|
It should only be done when the peer has a way to make sure all
|
|
data has been received and doesn't wait for the close_notify alert
|
|
message, otherwise an unexpected EOF will be reported.
|
|
|
|
There are implementations that do not send the required close_notify alert.
|
|
If there is a need to communicate with such an implementation, and it's clear
|
|
that all data has been received, do not wait for the peer's close_notify alert.
|
|
Waiting for the close_notify alert when the peer just closes the connection
|
|
will result in an error being generated.
|
|
The error can be ignored using the B<SSL_OP_IGNORE_UNEXPECTED_EOF>.
|
|
For more information see L<SSL_CTX_set_options(3)>.
|
|
|
|
SSL_shutdown_ex() is an extended version of SSL_shutdown(). If non-NULL, I<args>
|
|
must point to a B<SSL_SHUTDOWN_EX_ARGS> structure and I<args_len> must be set to
|
|
C<sizeof(SSL_SHUTDOWN_EX_ARGS)>. The B<SSL_SHUTDOWN_EX_ARGS> structure must be
|
|
zero-initialized. If I<args> is NULL, the behaviour is the same as passing a
|
|
zero-initialised B<SSL_SHUTDOWN_EX_ARGS> structure. When used with a non-QUIC
|
|
SSL object, the arguments are ignored and the call functions identically to
|
|
SSL_shutdown().
|
|
|
|
=begin comment
|
|
|
|
TODO(QUIC): Once streams are implemented, revise this text
|
|
|
|
=end comment
|
|
|
|
When used with a QUIC connection SSL object, SSL_shutdown_ex() initiates a QUIC
|
|
immediate close. The I<quic_error_code> field can be used to specify a 62-bit
|
|
application error code to be signalled via QUIC. The value specified must be in
|
|
the range [0, 2**62-1], else this call fails. I<quic_reason> may optionally
|
|
specify a zero-terminated reason string to be signalled to the peer. If a reason
|
|
is not specified, a zero-length string is used as the reason. The reason string
|
|
is copied and need not remain allocated after the call to the function returns.
|
|
Reason strings are bounded by the path MTU and may be silently truncated if they
|
|
are too long to fit in a QUIC packet. The arguments are only used on the first
|
|
call to SSL_shutdown_ex() for a given QUIC connection SSL object.
|
|
|
|
When using QUIC, how an application uses SSL_shutdown() or SSL_shutdown_ex() has
|
|
implications for whether QUIC closes a connection in an RFC-compliant manner.
|
|
For discussion of these issues, and for discussion of the I<flags> argument, see
|
|
B<QUIC-SPECIFIC SHUTDOWN CONSIDERATIONS> below.
|
|
|
|
=head2 First to close the connection
|
|
|
|
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 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_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.
|
|
|
|
=head1 QUIC-SPECIFIC SHUTDOWN CONSIDERATIONS
|
|
|
|
When using QUIC, SSL_shutdown() or SSL_shutdown_ex() causes any data written to
|
|
a stream which has not yet been sent to the peer to be written before the
|
|
shutdown process is considered complete. An exception to this is streams which
|
|
terminated in a non-normal fashion, for example due to a stream reset; only
|
|
streams which are non-terminated or which terminated in a normal fashion have
|
|
their pending send buffers flushed in this manner. This behaviour can be skipped
|
|
by setting the B<SSL_SHUTDOWN_FLAG_NO_STREAM_FLUSH> flag; in this case, data
|
|
remaining in stream send buffers may not be transmitted to the peer. This flag
|
|
may be used when a non-normal application condition has occurred and the
|
|
delivery of data written to streams via L<SSL_write(3)> is no longer relevant.
|
|
|
|
Aspects of how QUIC handles connection closure must be taken into account by
|
|
applications. Ordinarily, QUIC expects a connection to continue to be serviced
|
|
for a substantial period of time after it is nominally closed. This is necessary
|
|
to ensure that any connection closure notification sent to the peer was
|
|
successfully received. However, a consequence of this is that a fully
|
|
RFC-compliant QUIC connection closure process could take of the order of
|
|
seconds. This may be unsuitable for some applications, such as short-lived
|
|
processes which need to exit immediately after completing an application-layer
|
|
transaction.
|
|
|
|
As such, there are two shutdown modes available to users of QUIC connection SSL
|
|
objects:
|
|
|
|
=over 4
|
|
|
|
=item RFC compliant shutdown mode
|
|
|
|
This is the default behaviour. The shutdown process may take a period of time up
|
|
to three times the current estimated RTT to the peer. It is possible for the
|
|
closure process to complete much faster in some circumstances but this cannot be
|
|
relied upon.
|
|
|
|
In blocking mode, the function will return once the closure process is complete.
|
|
In nonblocking mode, SSL_shutdown_ex() should be called until it returns 1,
|
|
indicating the closure process is complete and the connection is now fully shut
|
|
down.
|
|
|
|
=item Rapid shutdown mode
|
|
|
|
In this mode, the peer is notified of connection closure on a best effort basis
|
|
by sending a single QUIC packet. If that QUIC packet is lost, the peer will not
|
|
know that the connection has terminated until the negotiated idle timeout (if
|
|
any) expires.
|
|
|
|
This will generally return 0 on success, indicating that the connection has not
|
|
yet been fully shut down (unless it has already done so, in which case it will
|
|
return 1).
|
|
|
|
=back
|
|
|
|
If B<SSL_SHUTDOWN_FLAG_RAPID> is specified in I<flags>, a rapid shutdown is
|
|
performed, otherwise an RFC-compliant shutdown is performed.
|
|
|
|
If an application calls SSL_shutdown_ex() with B<SSL_SHUTDOWN_FLAG_RAPID>, an
|
|
application can subsequently change its mind about performing a rapid shutdown
|
|
by making a subsequent call to SSL_shutdown_ex() without the flag set.
|
|
|
|
=head1 RETURN VALUES
|
|
|
|
For both SSL_shutdown() and SSL_shutdown_ex() the following return values can occur:
|
|
|
|
=over 4
|
|
|
|
=item Z<>0
|
|
|
|
The shutdown process is ongoing and has not yet completed.
|
|
|
|
For TLS and DTLS, this means that a close_notify alert has been sent but the
|
|
peer has not yet replied in turn with its own close_notify.
|
|
|
|
For QUIC connection SSL objects, a CONNECTION_CLOSE frame may have been
|
|
sent but the connection closure process has not yet completed.
|
|
|
|
Unlike most other functions, returning 0 does not indicate an error.
|
|
L<SSL_get_error(3)> should not be called; it may misleadingly indicate an error
|
|
even though no error occurred.
|
|
|
|
=item Z<>1
|
|
|
|
The shutdown was successfully completed.
|
|
|
|
For TLS and DTLS, this means that a close_notify alert was sent and the peer's
|
|
close_notify alert was received.
|
|
|
|
For QUIC connection SSL objects, this means that the connection closure process
|
|
has completed.
|
|
|
|
=item E<lt>0
|
|
|
|
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 nonblocking
|
|
BIOs.
|
|
|
|
It can also occur when not all data was read using SSL_read().
|
|
|
|
=back
|
|
|
|
=head1 SEE ALSO
|
|
|
|
L<SSL_get_error(3)>, L<SSL_connect(3)>,
|
|
L<SSL_accept(3)>, L<SSL_set_shutdown(3)>,
|
|
L<SSL_CTX_set_quiet_shutdown(3)>, L<SSL_CTX_set_options(3)>
|
|
L<SSL_clear(3)>, L<SSL_free(3)>,
|
|
L<ssl(7)>, L<bio(7)>
|
|
|
|
=head1 HISTORY
|
|
|
|
The SSL_shutdown_ex() function was added in OpenSSL 3.2.
|
|
|
|
=head1 COPYRIGHT
|
|
|
|
Copyright 2000-2020 The OpenSSL Project Authors. All Rights Reserved.
|
|
|
|
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>.
|
|
|
|
=cut
|