Stop reporting SSL_R_SHUTDOWN_WHILE_IN_INIT.
This effectively reverts b9824e241746d70d985d1004078b5bad0ad9a75b. This
error seems to have mostly just caused confusion in logs and the
occasional bug around failing to ERR_clear_error. Consumers tend to
blindly call SSL_shutdown when tearing down an SSL (to avoid
invalidating sessions). This means handshake failures trigger two
errors, which is screwy.
Go back to the old behavior where SSL_shutdown while SSL_in_init
silently succeeds.
Change-Id: I1fcfc92d481b97c840847dc39afe59679cd995f2
Reviewed-on: https://boringssl-review.googlesource.com/13909
Commit-Queue: David Benjamin <davidben@google.com>
Commit-Queue: Steven Valdez <svaldez@google.com>
Reviewed-by: Steven Valdez <svaldez@google.com>
CQ-Verified: CQ bot account: commit-bot@chromium.org <commit-bot@chromium.org>
diff --git a/ssl/ssl_lib.c b/ssl/ssl_lib.c
index 9bf09df..57178cf 100644
--- a/ssl/ssl_lib.c
+++ b/ssl/ssl_lib.c
@@ -781,10 +781,11 @@
return -1;
}
- /* We can't shutdown properly if we are in the middle of a handshake. */
+ /* If we are in the middle of a handshake, silently succeed. Consumers often
+ * call this function before |SSL_free|, whether the handshake succeeded or
+ * not. We assume the caller has already handled failed handshakes. */
if (SSL_in_init(ssl)) {
- OPENSSL_PUT_ERROR(SSL, SSL_R_SHUTDOWN_WHILE_IN_INIT);
- return -1;
+ return 1;
}
if (ssl->quiet_shutdown) {
