SSL_SET_SHUTDOWN(3SSL)

πŸ’… SSL_SET_SHUTDOWN πŸ’…

okay bestie, so this is the page about SSL_set_shutdown and SSL_get_shutdown β€” they live in the OpenSSL manual, section 3SSL. that's the ✨vibe✨. these two functions manipulate the shutdown state of an SSL connection. yes. that's literally the whole thing. let's get into it 🫢


✨ SYNOPSIS ✨

#include <openssl/ssl.h>

void SSL_set_shutdown(SSL *ssl, int mode);

int SSL_get_shutdown(const SSL *ssl);

🌸 DESCRIPTION 🌸

  • SSL_set_shutdown() β€” sets the shutdown state of ssl to mode. that's it. you hand it a mode, it makes it so πŸ’…
  • SSL_get_shutdown() β€” returns the shutdown mode of ssl. reads it back out for you, no cap.

πŸŽ€ NOTES πŸŽ€

okay so the shutdown state of an ssl connection is a bit-mask of these, listen closely:

  • 0 β€” no shutdown setting, yet. baby's first state. nothing happened 🌱
  • SSL_SENT_SHUTDOWN β€” a close_notify shutdown alert was sent to the peer, the connection is being considered closed and the session is closed and correct. iconic behavior, honestly πŸ‘‘
  • SSL_RECEIVED_SHUTDOWN β€” a shutdown alert was received form the peer, either a normal close_notify or a fatal error. (yes that's how it's spelled up in here, we keep it exactly as-is fr fr)

and the tea is: SSL_SENT_SHUTDOWN and SSL_RECEIVED_SHUTDOWN can be set at the same time. they're not mutually exclusive, they're besties 🫢


the shutdown state of the connection is used to determine the state of the ssl session. so if the session is still open when SSL_clear(3) or SSL_free(3) gets called, it is considered bad and removed according to RFC2246. πŸ’€

the actual condition for a correctly closed session is SSL_SENT_SHUTDOWN. and per the TLS RFC, it is acceptable to only send the close_notify alert but to not wait for the peer's answer, when the underlying connection is closed. so like, you can dip without waiting for the reply. main character energy πŸ¦‹

SSL_set_shutdown() can be used to set this state without sending a close alert to the peer (see SSL_shutdown(3)). sneaky. love that for you.

if a close_notify was received, SSL_RECEIVED_SHUTDOWN will be set. but for setting SSL_SENT_SHUTDOWN, the application must however still call SSL_shutdown(3) or SSL_set_shutdown() itself. nobody's doing it for you, bestie 😭

🚨 heads up: SSL_set_shutdown() is not supported for QUIC SSL objects. not a thing. don't try it.

🌈 RETURN VALUES 🌈

  • SSL_set_shutdown() does not return diagnostic information. it just does the thing and leaves. respectful honestly πŸ’…
  • SSL_get_shutdown() returns the current shutdown state as set, or based on the actual connection state. lowkey both.
  • SSL_get_shutdown() returns 0 if called on a QUIC stream SSL object. but if it's called on a QUIC connection SSL object, it returns a value with SSL_SENT_SHUTDOWN set if CONNECTION_CLOSE has been sent to the peer, and it returns a value with SSL_RECEIVED_SHUTDOWN set if CONNECTION_CLOSE has been received from the peer or the QUIC connection is fully terminated for other reasons. ✨ QUIC lore ✨

πŸ”₯ SEE ALSO πŸ”₯


Copyright 2001-2023 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 <https://www.openssl.org/source/license.html>. πŸŽ€


and that's the whole page, periodt πŸ’– this was version 4.0.3, dated 2026-09-29, from the SSL_SET_SHUTDOWN(3SSL) era of the OpenSSL manual. slay, go close your connections properly bestie πŸŒΈπŸ¦‹βœ¨

πŸ“¦ where this page comes from