SSL_CTX_SET_...IENT_CALLBACK(3SSL)
π NAME π
okay bestie, welcome to the PSK client callback page π
this is the OpenSSL 3SSL manual for SSL_psk_client_cb_func, SSL_psk_use_session_cb_func, SSL_CTX_set_psk_client_callback, SSL_set_psk_client_callback, SSL_CTX_set_psk_use_session_callback, and SSL_set_psk_use_session_callback β aka the whole girlboss squad whose job is to set the PSK client callback. π
β¨ SYNOPSIS β¨
#include <openssl/ssl.h>
typedef int (*SSL_psk_use_session_cb_func)(SSL *ssl, const EVP_MD *md,
const unsigned char **id,
size_t *idlen,
SSL_SESSION **sess);
void SSL_CTX_set_psk_use_session_callback(SSL_CTX *ctx,
SSL_psk_use_session_cb_func cb);
void SSL_set_psk_use_session_callback(SSL *s, SSL_psk_use_session_cb_func cb);
typedef unsigned int (*SSL_psk_client_cb_func)(SSL *ssl,
const char *hint,
char *identity,
unsigned int max_identity_len,
unsigned char *psk,
unsigned int max_psk_len);
void SSL_CTX_set_psk_client_callback(SSL_CTX *ctx, SSL_psk_client_cb_func cb);
void SSL_set_psk_client_callback(SSL *ssl, SSL_psk_client_cb_func cb);
π¦ DESCRIPTION π¦
So here's the tea β β if your client app wants to use TLSv1.3 PSKs, you use either SSL_CTX_set_psk_use_session_callback() or SSL_set_psk_use_session_callback(), whichever fits your setup. And no, these functions literally cannot be used for TLSv1.2 and below PSKs. That's just not their era, iykyk. π«
The callback function gets handed a pointer to the SSL connection in ssl.
The very first time the callback gets called for a connection, the md parameter is NULL. In some circumstances the callback will get called a second time. When that happens, the server will have already specified a ciphersuite to use, and the PSK has to be compatible with the digest for that ciphersuite. That digest shows up in md. And the PSK your callback returns is allowed to be different between the first and second call. no cap. β¨
When it completes successfully, the callback must store a pointer to an identifier for the PSK in *id. The identifier length in bytes goes in *idlen. The memory that *id points to stays owned by the application, and the app should free it as required at any point after the handshake is complete. π«Ά
On top of that, the callback should stash a pointer to an SSL_SESSION object in *sess. This is used as the basis for the PSK, and it should have, at a minimum, these fields set π
- The master key β set it with a call to
SSL_SESSION_set1_master_key(3). - A ciphersuite β only the handshake digest associated with the ciphersuite is relevant for the PSK (the server may go on to negotiate any ciphersuite that's compatible with the digest). The application can use any TLSv1.3 ciphersuite. If
mdis not NULL, the handshake digest for the ciphersuite should be the same. You set the ciphersuite via a call to<SSL_SESSION_set_cipher(3)>. And you can check the handshake digest of anSSL_CIPHERobject using<SSL_CIPHER_get_handshake_digest(3)>. π - The protocol version β set it via a call to
SSL_SESSION_set_protocol_version(3), and it should beTLS1_3_VERSION.
Also β the maximum early data value should be set via a call to SSL_SESSION_set_max_early_data(3) if the PSK is going to be used for sending early data. πΈ
Alternatively, an SSL_SESSION created from a previous non-PSK handshake may also be used as the basis for a PSK. Recycle, reuse, it's giving sustainable queen. β»οΈ
Ownership of the SSL_SESSION object is passed to the OpenSSL library, so the application should not free it. Periodt.
Now, remember how we said above that the callback may be called a second time during a handshake? Since ownership of the SSL_SESSION gets transferred to OpenSSL on each call, if the callback wants to return the same SSL_SESSION pointer on a subsequent invocation, it must first call SSL_SESSION_up_ref(3) to increment the reference count. Fail to do that and you get a use-after-free error. π Dramatic but real. Alternatively, the callback may return a different SSL_SESSION object on each call (e.g., by calling SSL_SESSION_dup(3)).
It's also possible for the callback to succeed but not supply a PSK at all. In that case no PSK will be sent to the server, but the handshake will continue. To do this, the callback should return successfully and make sure that *sess is NULL. The contents of *id and *idlen will be ignored. π«₯
A client application that wants to use PSK ciphersuites for TLSv1.2 and below must provide a different callback function. This one gets called when the client is sending the ClientKeyExchange message to the server.
The purpose of the callback function is to select the PSK identity and the pre-shared key to use during the connection setup phase. Main character behavior honestly. π
The callback is set using SSL_CTX_set_psk_client_callback() or SSL_set_psk_client_callback(). The callback function is given:
- the connection in parameter
ssl, - a NUL-terminated PSK identity hint sent by the server in parameter
hint, - a buffer
identityof lengthmax_identity_lenbytes (including the NUL-terminator) where the resulting NUL-terminated identity is to be stored, - and a buffer
pskof lengthmax_psk_lenbytes where the resulting pre-shared key is to be stored.
The callback for use in TLSv1.2 will also work in TLSv1.3, although it is recommended to use SSL_CTX_set_psk_use_session_callback() or SSL_set_psk_use_session_callback() for that purpose instead. If TLSv1.3 has been negotiated, then OpenSSL will first check to see if a callback has been set via SSL_CTX_set_psk_use_session_callback() or SSL_set_psk_use_session_callback() and it will use that in preference. If no such callback is present, then it will check whether a callback has been set via SSL_CTX_set_psk_client_callback() or SSL_set_psk_client_callback() and use that. In that case the hint value will always be NULL and the handshake digest will default to SHA-256 for any returned PSK. And heads up: TLSv1.3 early data exchanges are possible in PSK connections only with the SSL_psk_use_session_cb_func callback, and are not possible with the SSL_psk_client_cb_func callback. π¨
π NOTES π
- Note that the parameter
hintgiven to the callback may be NULL. - A connection established via a TLSv1.3 PSK will appear as if session resumption has occurred, so that
SSL_session_reused(3)will return true. - There are no known security issues with sharing the same PSK between TLSv1.2 (or below) and TLSv1.3. However, the RFC has this note of caution:
"While there is no known way in which the same PSK might produce related output in both versions, only limited analysis has been done. Implementations can ensure safety from cross-protocol related output by not reusing PSKs between TLS 1.3 and TLS 1.2."
π₯ RETURN VALUES π₯
Return values from the SSL_psk_client_cb_func callback are interpreted like this:
- On success (callback found a PSK identity and a pre-shared key to use) the length (
> 0) ofpskin bytes is returned. - Otherwise, or on errors, the callback should return
0. In this case the connection setup fails. π
The SSL_psk_use_session_cb_func callback should return 1 on success or 0 on failure. In the event of failure the connection setup fails.
π SEE ALSO π
ssl(7), SSL_CTX_set_psk_find_session_callback(3), SSL_set_psk_find_session_callback(3)
β HISTORY β
SSL_CTX_set_psk_use_session_callback() and SSL_set_psk_use_session_callback() were added in OpenSSL 1.1.1. throwback fr fr π°οΈ
π COPYRIGHT π
Copyright 2006-2026 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>.
okay that's the whole page bestie, you ate that π
β¨ this was OpenSSL 4.0.3, dated 2026-09-29, from the SSL_CTX_SET_...IENT_CALLBACK(3SSL) manual β go set those callbacks, you've got this, mwah ππ¦
π¦ where this page comes from
- ubuntu stonking: libssl-doc 4.0.3-1ubuntu1 Β· Apache-2.0
- π girlified by deepseek-ai/DeepSeek-V4.1-Flash on : a language model's rewrite of the original, under its terms