Clarify that SSL_shutdown() must not be called after a fatal error

Follow on from CVE-2019-1559

Reviewed-by: Richard Levitte <levitte@openssl.org>
This commit is contained in:
Matt Caswell 2019-02-20 14:21:36 +00:00
parent 72a7a7021f
commit ab874dfd3e
2 changed files with 12 additions and 5 deletions

View file

@ -138,17 +138,20 @@ Details depend on the application.
=item SSL_ERROR_SYSCALL
Some non-recoverable I/O error occurred.
The OpenSSL error queue may contain more information on the error.
For socket I/O on Unix systems, consult B<errno> for details.
Some non-recoverable, fatal I/O error occurred. The OpenSSL error queue may
contain more information on the error. For socket I/O on Unix systems, consult
B<errno> for details. If this error occurs then no further I/O operations should
be performed on the connection and SSL_shutdown() must not be called.
This value can also be returned for other errors, check the error queue for
details.
=item SSL_ERROR_SSL
A failure in the SSL library occurred, usually a protocol error. The
OpenSSL error queue contains more information on the error.
A non-recoverable, fatal error in the SSL library occurred, usually a protocol
error. The OpenSSL error queue contains more information on the error. If this
error occurs then no further I/O operations should be performed on the
connection and SSL_shutdown() must not be called.
=back

View file

@ -22,6 +22,10 @@ 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.