SSL_CTX_SET_...TE_SESSION_ID(3ossl)
π SSL_CTX_SET_...TE_SESSION_ID π
okay so bestie, this one is from the OpenSSL manual, section 3ossl β like ssl(3), you know the vibe. it's giving "server side only, no clients allowed" energy and honestly? iconic of it. π
β¨ NAME β¨
SSL_CTX_set_generate_session_id, SSL_set_generate_session_id, SSL_has_matching_session_id, GEN_SESSION_CB β these are the girls that manipulate generation of SSL session IDs (server only, so don't come in here if you're a client, periodt).
πΈ SYNOPSIS πΈ
#include <openssl/ssl.h>
typedef int (*GEN_SESSION_CB)(SSL *ssl, unsigned char *id,
unsigned int *id_len);
int SSL_CTX_set_generate_session_id(SSL_CTX *ctx, GEN_SESSION_CB cb);
int SSL_set_generate_session_id(SSL *ssl, GEN_SESSION_CB, cb);
int SSL_has_matching_session_id(const SSL *ssl, const unsigned char *id,
unsigned int id_len);
yes bestie the typedef is right there in the synopsis, we love a callback type reveal π
π¦ DESCRIPTION π¦
SSL_CTX_set_generate_session_id()β sets the callback function for generating new session ids for SSL/TLS sessions, forctx, to becb. so like, the whole context gets a new little session-id-making bestie. π«ΆSSL_set_generate_session_id()β sets the callback function for generating new session ids for SSL/TLS sessions, forssl, to becb. just for that onesslthough. one-on-one time. β¨SSL_has_matching_session_id()β checks whether a session with idid(of lengthid_len) is already contained in the internal session cache of the parent context ofssl. it's the vibe check, basically. is this id already taken? π
π₯ NOTES π₯
okay this is the part where you actually read, bestie, no skimming. π€
when a new session is established between client and server, the server generates a session id. the session id is an arbitrary sequence of bytes. the length of the session id is between 1 and 32 bytes. the session id is not security critical but must be unique for the server. and also β listen β the session id is transmitted in the clear when reusing the session, so it must not contain sensitive information. not the place to hide your secrets, gorgeous. π«π
without a callback being set, an OpenSSL server will generate a unique session id from pseudo random numbers of the maximum possible length. using the callback function, the session id can be changed to contain additional information like e.g. a host id, in order to improve load balancing or external caching techniques. so like, custom flair but with a purpose. π
the callback function receives a pointer to the memory location to put id into, and a pointer to the maximum allowed length id_len. the buffer at location id is only guaranteed to have the size id_len. the callback is only allowed to generate a shorter id and reduce id_len; the callback must never increase id_len or write to the location id exceeding the given limit. do not test it. it will not go well. π
the location id is filled with 0x00 before the callback is called, so the callback may only fill part of the possible length and leave id_len untouched while maintaining reproducibility. cute and tidy, we stan. π
since the sessions must be distinguished, session ids must be unique. without the callback a random number is used, so that the probability of generating the same session id is extremely small (2^256 for SSLv3/TLSv1). in order to assure the uniqueness of the generated session id, the callback must call SSL_has_matching_session_id() and generate another id if a conflict occurs. if an id conflict is not resolved, the handshake will fail. π so like, handle your conflicts, fr fr.
if the application codes e.g. a unique host id, a unique process number, and a unique sequence number into the session id, uniqueness could easily be achieved without randomness added (it should however be taken care that no confidential information is leaked this way). if the application can not guarantee uniqueness, it is recommended to use the maximum id_len and fill in the bytes not used to code special information with random data to avoid collisions. π§
SSL_has_matching_session_id() will only query the internal session cache, not the external one. since the session id is generated before the handshake is completed, it is not immediately added to the cache. if another thread is using the same internal session cache, a race condition can occur in that another thread generates the same session id. collisions can also occur when using an external session cache, since the external cache is not tested with SSL_has_matching_session_id() and the same race condition applies. so yeah β threads are out here competing, as they do. π
the callback must return 0 if it cannot generate a session id for whatever reason and return 1 on success.
β οΈ real talk: never grow id_len, never write past the limit, and never skip the uniqueness check. the handshake will simply fail and everyone will be sad. π
π RETURN VALUES π
SSL_CTX_set_generate_session_id()andSSL_set_generate_session_id()return1on success and0for failure.SSL_has_matching_session_id()returns1if another session with the same id is already in the cache, or0otherwise.
π EXAMPLES π
the callback function listed will generate a session id with the server id given, and will fill the rest with pseudo random bytes:
const char session_id_prefix = "www-18";
#define MAX_SESSION_ID_ATTEMPTS 10
static int generate_session_id(SSL *ssl, unsigned char *id,
unsigned int *id_len)
{
unsigned int count = 0;
do {
RAND_pseudo_bytes(id, *id_len);
/*
* Prefix the session_id with the required prefix. NB: If our
* prefix is too long, clip it - but there will be worse effects
* anyway, e.g. the server could only possibly create 1 session
* ID (i.e. the prefix!) so all future session negotiations will
* fail due to conflicts.
*/
memcpy(id, session_id_prefix, strlen(session_id_prefix) < *id_len ?
strlen(session_id_prefix) : *id_len);
} while (SSL_has_matching_session_id(ssl, id, *id_len)
&& ++count < MAX_SESSION_ID_ATTEMPTS);
if (count >= MAX_SESSION_ID_ATTEMPTS)
return 0;
return 1;
}
see how it loops with MAX_SESSION_ID_ATTEMPTS and bails with 0 if it runs out of tries? that's the assignment, bestie, and it ate. π₯
π SEE ALSO π
go read those too, iykyk. π
π COPYRIGHT π
Copyright 2001-2020 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, no cap. this was OpenSSL version 3.5.9, dated 2026-09-2, filed under SSL_CTX_SET_...TE_SESSION_ID(3ossl). mwah, take care of your session ids bestie πβ¨π
π¦ 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