![]() Note that this is not standard compliant behaviour. When "quiet shutdown" is enabled, SSL_shutdown() will always succeed and return 1. SSL_shutdown() can be modified to only set the connection to "shutdown" state but not actually send the close_notify alert messages, see SSL_CTX_set_quiet_shutdown(3). However, it is recommended to wait for it using SSL_read() instead. SSL_shutdown() will return 1 in that case. 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.Īfter SSL_shutdown() returned 0, it is possible to call SSL_shutdown() again to wait for the peer's close_notify alert. When using a nonblocking socket, nothing is to be done, but select() can be used to check for the required condition. The action depends on the underlying BIO. The calling process then must repeat the call after taking appropriate action to satisfy the needs of SSL_shutdown(). In this case a call to SSL_get_error() with the return value of SSL_shutdown() will yield SSL_ERROR_WANT_READ or SSL_ERROR_WANT_WRITE. If the underlying BIO is nonblocking, SSL_shutdown() will also return when the underlying BIO could not satisfy the needs of SSL_shutdown() to continue the handshake. ![]() If the underlying BIO is blocking, SSL_shutdown() will only return once the handshake step has been finished or an error occurred. The behaviour of SSL_shutdown() additionally depends on the underlying BIO. The read direction is closed by the peer. It is not possible to call SSL_write() after calling SSL_shutdown(). SSL_shutdown() only closes the write direction. When the underlying connection shall be used for more communications, the complete shutdown procedure must be performed, so that the peers stay synchronized. 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 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. 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. ![]() This way resources can be saved, as the process can already terminate or serve another connection. 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. The order of those two steps depends on the application. ![]() The shutdown procedure consists of two steps: sending of the close_notify shutdown alert, and reception of the peer's close_notify shutdown alert. if SSL_get_error() has returned SSL_ERROR_SYSCALL or SSL_ERROR_SSL. Note that SSL_shutdown() must not be called if a previous fatal error has occurred on a connection i.e. 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. SSL_shutdown() tries to send the close_notify shutdown alert to the peer. ![]() It sends the close_notify shutdown alert to the peer. SSL_shutdown() shuts down an active TLS/SSL connection. _owur int SSL_shutdown_ex(SSL *ssl, uint64_t flags, SSL_shutdown, SSL_shutdown_ex - shut down a TLS/SSL or QUIC connection SYNOPSIS #include ![]()
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |