SSL_GET_SESSION(3ossl)
β¨ SSL_GET_SESSION β the 3ossl manual, but make it cute β¨
okay bestie, welcome to SSL_GET_SESSION(3ossl), the page where we learn how to retrieve TLS/SSL session data π
πΈ NAME πΈ
SSL_get_session, SSL_get0_session, SSL_get1_session β retrieve TLS/SSL session data π
π¦ SYNOPSIS π¦
#include <openssl/ssl.h>
SSL_SESSION *SSL_get_session(const SSL *ssl);
SSL_SESSION *SSL_get0_session(const SSL *ssl);
SSL_SESSION *SSL_get1_session(SSL *ssl);
π DESCRIPTION π
okay so. SSL_get_session() returns a pointer to the SSL_SESSION that was actually used in ssl. and here's the tea: the reference count of that SSL_SESSION is NOT incremented, which means that pointer can lowkey become invalid the moment other operations happen π like, it's giving "borrowed, not owned."
SSL_get0_session() is literally the same as SSL_get_session(). same function, different name, no notes π
SSL_get1_session() is also the same as SSL_get_session(), but β and this is the important part β the reference count of the SSL_SESSION gets incremented by one. so now you own a piece of it, bestie π«Ά
π NOTES π
okay this is the part where you actually need to pay attention, fr fr.
the ssl session contains all the information required to re-establish the connection without a full handshake β for SSL versions up to and including TLSv1.2 π
in TLSv1.3 the same thing is true, but sessions are established after the main handshake has already occurred. the server will send the session information to the client at a time of its choosing, which may be a while after the initial connection is established β or, like, never π. so if you call these functions on the client side in TLSv1.3 before the session has been established, you'll still get an SSL_SESSION object back, but that object cannot be used for resuming the session π. if you wanna know whether an SSL_SESSION object can be used for resumption or not, go read SSL_SESSION_is_resumable(3) β it's the vibe check you're looking for β¨
additionally, in TLSv1.3, a server can send multiple messages that establish a session for a single connection π. in that case, on the client side, the above functions will only return information on the last session that was received. on the server side they will only return information on the last session that was sent β or, if no session tickets were sent, then the session for the current connection. slay, but also kind of limiting π
the preferred way for applications to obtain a resumable SSL_SESSION object is to use a new session callback, as described in SSL_CTX_sess_set_new_cb(3) π. the new session callback is only invoked when a session is actually established, so this avoids the whole problem described above where an application obtains an SSL_SESSION object that cannot be used for resumption in TLSv1.3. bonus: it also lets applications obtain information about all sessions sent by the server π
a session will be automatically removed from the session cache and marked as non-resumable if the connection is not closed down cleanly π β like, for example, if a fatal error occurs on the connection, or if SSL_shutdown(3) is not called prior to SSL_free(3). so be nice to your connections, bestie.
in TLSv1.3 it is recommended that each SSL_SESSION object is only used for resumption once. one and done, main character energy β
SSL_get0_session() returns a pointer to the actual session. since the reference counter is not incremented, that pointer is only valid while the connection is in use. if SSL_clear(3) or SSL_free(3) is called, the session may be removed completely (if it's considered bad π), and the pointer you obtained will become invalid. and even if the session is valid, it can be removed at any time due to timeout during SSL_CTX_flush_sessions(3) π«
if you want to keep the data, SSL_get1_session() will increment the reference count, so that the session will not be implicitly removed by other operations but stays in memory π§. in order to remove the session, SSL_SESSION_free(3) must be explicitly called once to decrement the reference count again. periodt.
and now for a warning that is genuinely important, no drama:
SSL_SESSIONobjects keep internal link information about the session cache list when being inserted into oneSSL_CTXobject's session cache. oneSSL_SESSIONobject, regardless of its reference count, must therefore only be used with oneSSL_CTXobject (and theSSLobjects created from thisSSL_CTXobject). do not share, bestie. it's not that kind of relationship π
π₯ RETURN VALUES π₯
the following return values can occur:
NULLβ there is no session available insslπ- Pointer to an
SSL_SESSIONβ the return value points to the data of an SSL session β¨
π SEE ALSO π
ssl(7), SSL_free(3), SSL_clear(3), SSL_SESSION_free(3)
π COPYRIGHT π
Copyright 2000-2018 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, bestie π«Ά this was 3.5.9, dated 2026-09-29, and it's the SSL_GET_SESSION(3ossl) manual β now go increment your reference counts responsibly π
β¨π
π¦ where this page comes from
- fedora 43: openssl-devel 1:3.5.9-1.fc43 Β· Apache-2.0
- fedora 43: openssl-devel 1:3.5.9-1.fc43 Β· Apache-2.0
- fedora 44: openssl-devel 1:3.5.9-1.fc44 Β· Apache-2.0
- fedora 44: openssl-devel 1:3.5.9-1.fc44 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms