]> git.ipfire.org Git - thirdparty/openssl.git/blame - doc/man3/SSL_shutdown.pod
Improve SSL_shutdown() documentation
[thirdparty/openssl.git] / doc / man3 / SSL_shutdown.pod
CommitLineData
cc99526d
RL
1=pod
2
3=head1 NAME
4
1e4e5492 5SSL_shutdown - shut down a TLS/SSL connection
cc99526d
RL
6
7=head1 SYNOPSIS
8
9 #include <openssl/ssl.h>
10
11 int SSL_shutdown(SSL *ssl);
12
13=head1 DESCRIPTION
14
1bc74519 15SSL_shutdown() shuts down an active TLS/SSL connection. It sends the
8e593f0a 16close_notify shutdown alert to the peer.
8e495e4a
LJ
17
18=head1 NOTES
19
8e593f0a 20SSL_shutdown() tries to send the close_notify shutdown alert to the peer.
8e495e4a
LJ
21Whether the operation succeeds or not, the SSL_SENT_SHUTDOWN flag is set and
22a currently open session is considered closed and good and will be kept in the
23session cache for further reuse.
24
8e593f0a
KR
25The shutdown procedure consists of two steps: sending of the close_notify
26shutdown alert, and reception of the peer's close_notify shutdown alert.
27The order of those two steps depends on the application.
28
29It is acceptable for an application to only send its shutdown alert and
30then close the underlying connection without waiting for the peer's response.
31This way resources can be saved, as the process can already terminate or
32serve another connection.
33This should only be done when it is known that the other side will not send more
34data, otherwise there is a risk of a truncation attack.
b2ed4629 35
8e593f0a
KR
36When a client only writes and never reads from the connection, and the server
37has sent a session ticket to establish a session, the client might not be able
38to resume the session because it did not received and process the session ticket
39from the server.
40In case the application wants to be able to resume the session, it is recommended to
41do a complete shutdown procedure (bidirectional close_notify alerts).
42
43When the underlying connection shall be used for more communications, the
44complete shutdown procedure must be performed, so that the peers stay
45synchronized.
9e09eebf 46
2f6f913e
KR
47SSL_shutdown() only closes the write direction.
48It is not possible to call SSL_write() after calling SSL_shutdown().
49The read direction is closed by the peer.
50
51=head2 First to close the connection
9e09eebf 52
8e593f0a 53When the application is the first party to send the close_notify
4a64f3d6 54alert, SSL_shutdown() will only send the alert and then set the
9e09eebf 55SSL_SENT_SHUTDOWN flag (so that the session is considered good and will
2f6f913e 56be kept in the cache).
8e593f0a
KR
57If successful, SSL_shutdown() will return 0.
58
2f6f913e 59If a unidirectional shutdown is enough (the underlying connection shall be
8e593f0a 60closed anyway), this first successful call to SSL_shutdown() is sufficient.
2f6f913e
KR
61
62In order to complete the bidirectional shutdown handshake, the peer needs
8e593f0a 63to send back a close_notify alert.
2f6f913e
KR
64The SSL_RECEIVED_SHUTDOWN flag will be set after receiving and processing
65it.
2f6f913e 66
8e593f0a 67The peer is still allowed to send data after receiving the close_notify
2f6f913e 68event.
8e593f0a
KR
69When it is done sending data, it will send the close_notify alert.
70SSL_read() should be called until all data is received.
2f6f913e
KR
71SSL_read() will indicate the end of the peer data by returning <= 0
72and SSL_get_error() returning SSL_ERROR_ZERO_RETURN.
2f6f913e
KR
73
74=head2 Peer closes the connection
75
8e593f0a 76If the peer already sent the close_notify alert B<and> it was
d93eb21c 77already processed implicitly inside another function
9b86974e 78(L<SSL_read(3)>), the SSL_RECEIVED_SHUTDOWN flag is set.
2f6f913e
KR
79SSL_read() will return <= 0 in that case, and SSL_get_error() will return
80SSL_ERROR_ZERO_RETURN.
8e593f0a
KR
81SSL_shutdown() will send the close_notify alert, set the SSL_SENT_SHUTDOWN
82flag.
83If successful, SSL_shutdown() will return 1.
84
d93eb21c 85Whether SSL_RECEIVED_SHUTDOWN is already set can be checked using the
9b86974e 86SSL_get_shutdown() (see also L<SSL_set_shutdown(3)> call.
9e09eebf 87
2f6f913e 88=head1 NOTES
9e09eebf 89
1bc74519 90The behaviour of SSL_shutdown() additionally depends on the underlying BIO.
1e4e5492 91If the underlying BIO is B<blocking>, SSL_shutdown() will only return once the
9e09eebf 92handshake step has been finished or an error occurred.
cc99526d 93
1e4e5492 94If the underlying BIO is B<non-blocking>, SSL_shutdown() will also return
cc99526d
RL
95when the underlying BIO could not satisfy the needs of SSL_shutdown()
96to continue the handshake. In this case a call to SSL_get_error() with the
1e4e5492
UM
97return value of SSL_shutdown() will yield B<SSL_ERROR_WANT_READ> or
98B<SSL_ERROR_WANT_WRITE>. The calling process then must repeat the call after
cc99526d
RL
99taking appropriate action to satisfy the needs of SSL_shutdown().
100The action depends on the underlying BIO. When using a non-blocking socket,
101nothing is to be done, but select() can be used to check for the required
102condition. When using a buffering BIO, like a BIO pair, data must be written
103into or retrieved out of the BIO before being able to continue.
104
8e593f0a
KR
105After SSL_shutdown() returned 0, it is possible to call SSL_shutdown() again
106to wait for the peer's close_notify alert.
107SSL_shutdown() will return 1 in that case.
108However, it is recommended to wait for it using SSL_read() instead.
109
cdd7c3ce 110SSL_shutdown() can be modified to only set the connection to "shutdown"
8e593f0a 111state but not actually send the close_notify alert messages,
9b86974e 112see L<SSL_CTX_set_quiet_shutdown(3)>.
cdd7c3ce
LJ
113When "quiet shutdown" is enabled, SSL_shutdown() will always succeed
114and return 1.
115
cc99526d
RL
116=head1 RETURN VALUES
117
118The following return values can occur:
119
120=over 4
121
c8919dde 122=item Z<>0
cc99526d 123
8e593f0a 124The shutdown is not yet finished: the close_notify was sent but the peer
2f6f913e 125did not send it back yet.
8e593f0a 126Call SSL_read() to do a bidirectional shutdown.
9b86974e 127The output of L<SSL_get_error(3)> may be misleading, as an
9e09eebf 128erroneous SSL_ERROR_SYSCALL may be flagged even though no error occurred.
cc99526d 129
c8919dde 130=item Z<>1
5cc27077 131
8e593f0a
KR
132The shutdown was successfully completed. The close_notify alert was sent
133and the peer's close_notify alert was received.
5cc27077 134
fe757304 135=item E<lt>0
cc99526d 136
2f6f913e
KR
137The shutdown was not successful.
138Call L<SSL_get_error(3)> with the return value B<ret> to find out the reason.
139It can occur if an action is needed to continue the operation for non-blocking
140BIOs.
141
142It can also occur when not all data was read using SSL_read().
cc99526d
RL
143
144=back
145
146=head1 SEE ALSO
147
9b86974e
RS
148L<SSL_get_error(3)>, L<SSL_connect(3)>,
149L<SSL_accept(3)>, L<SSL_set_shutdown(3)>,
150L<SSL_CTX_set_quiet_shutdown(3)>,
151L<SSL_clear(3)>, L<SSL_free(3)>,
b97fdb57 152L<ssl(7)>, L<bio(7)>
cc99526d 153
e2f92610
RS
154=head1 COPYRIGHT
155
c4d3c19b 156Copyright 2000-2018 The OpenSSL Project Authors. All Rights Reserved.
e2f92610
RS
157
158Licensed under the OpenSSL license (the "License"). You may not use
159this file except in compliance with the License. You can obtain a copy
160in the file LICENSE in the source distribution or at
161L<https://www.openssl.org/source/license.html>.
162
163=cut