SSL_CTX_SET_MSG_CALLBACK(3ossl)

πŸ’– SSL_CTX_SET_MSG_CALLBACK(3ossl) πŸ’–

okay so bestie, this is the OpenSSL manual page for SSL_CTX_set_msg_callback, SSL_CTX_set_msg_callback_arg, SSL_set_msg_callback, SSL_set_msg_callback_arg and SSL_trace β€” the 3ossl manual, no less. it's giving "i want to spy on every single protocol message" energy and honestly? iconic. let's get into it 🫢


✨ NAME ✨

SSL_CTX_set_msg_callback, SSL_CTX_set_msg_callback_arg, SSL_set_msg_callback, SSL_set_msg_callback_arg, SSL_trace β€” install callback for observing protocol messages πŸ‘€


🌸 SYNOPSIS 🌸

#include <openssl/ssl.h>

void SSL_CTX_set_msg_callback(SSL_CTX *ctx,
                              void (*cb)(int write_p, int version,
                                         int content_type, const void *buf,
                                         size_t len, SSL *ssl, void *arg));
void SSL_CTX_set_msg_callback_arg(SSL_CTX *ctx, void *arg);

void SSL_set_msg_callback(SSL *ssl,
                          void (*cb)(int write_p, int version,
                                     int content_type, const void *buf,
                                     size_t len, SSL *ssl, void *arg));
void SSL_set_msg_callback_arg(SSL *ssl, void *arg);

void SSL_trace(int write_p, int version, int content_type,
               const void *buf, size_t len, SSL *ssl, void *arg);

πŸ’… DESCRIPTION πŸ’…

so SSL_CTX_set_msg_callback() and SSL_set_msg_callback() are literally your backstage pass πŸŽ€ β€” you use them to define a message callback function cb that lets you observe ALL the SSL/TLS/QUIC protocol messages (handshake messages and friends) that get received or sent, plus other events that happen while stuff is being processed. no cap.

and SSL_CTX_set_msg_callback_arg() and SSL_set_msg_callback_arg() are how you set that arg argument on the callback function β€” it's just sitting there for arbitrary application use, do whatever you want with it bestie ✨

here's the tea on the difference between the two flavors:

  • SSL_CTX_set_msg_callback() and SSL_CTX_set_msg_callback_arg() set up default settings that get copied onto new SSL objects by SSL_new(3). it's giving "template energy" πŸ’…
  • SSL_set_msg_callback() and SSL_set_msg_callback_arg() modify the actual settings of a specific SSL object.

and listen β€” using a NULL pointer for cb disables the message callback. periodt.


🌈 when cb gets called, here's what the args mean 🌈

  • write_p β€” this flag is 0 when a protocol message has been received and 1 when a protocol message has been sent. simple as that.
  • version β€” the protocol version according to which the protocol message is interpreted by the library, like TLS1_3_VERSION, TLS1_2_VERSION, OSSL_QUIC1_VERSION etc. for the SSL3_RT_HEADER pseudo content type (peep the NOTES below) this value will be the decoded version/legacy_version field of the record header.
  • content_type β€” one of the content type values defined in the protocol specification (SSL3_RT_CHANGE_CIPHER_SPEC, SSL3_RT_ALERT, SSL3_RT_HANDSHAKE; but never SSL3_RT_APPLICATION_DATA, because the callback only gets called for protocol messages, bestie). alternatively it may be a "pseudo" content type β€” those are used to signal some other event in the processing of data (again, NOTES below πŸ‘‡).
  • buf, len β€” buf points to a buffer containing the protocol message or other data (in the case of pseudo content types), which consists of len bytes. ⚠️ the buffer is no longer valid after the callback function has returned β€” do NOT hang onto it, i'm serious.
  • ssl β€” the SSL object that received or sent the message. main character energy tbh πŸ‘‘
  • arg β€” the user-defined argument optionally defined by SSL_CTX_set_msg_callback_arg() or SSL_set_msg_callback_arg().

πŸ¦‹ the pre-written callback: SSL_trace() πŸ¦‹

the SSL_trace() function can be used as a pre-written callback in a call to SSL_CTX_set_msg_callback() or SSL_set_msg_callback(). it requires a BIO to be set as the callback argument via SSL_CTX_set_msg_callback_arg() or SSL_set_msg_callback_arg(). setting this callback will cause human readable diagnostic tracing information about an SSL/TLS/QUIC connection to be written to the BIO. it's literally free logging, we love to see it 🌸


πŸ‘‘ NOTES πŸ‘‘

protocol messages are passed to the callback function after decryption and fragment collection where applicable. (so lowkey the record boundaries are not visible, sorry bout it.)

if processing a received protocol message results in an error, the callback function may not be called. for example, the callback function will never see messages that are considered too large to be processed. πŸ’€

due to automatic protocol version negotiation, version is not necessarily the protocol version used by the sender of the message: if a TLS 1.0 ClientHello message is received by an SSL 3.0-only server, version will be SSL3_VERSION. yeah. that's a thing.

pseudo content type values may be sent at various points during the processing of data. the following pseudo content types are currently defined:

  • SSL3_RT_HEADER β€” used when a TLS record is sent or received. the buf contains the record header bytes only.
  • SSL3_RT_INNER_CONTENT_TYPE β€” used when an encrypted TLSv1.3 record is sent or received. in encrypted TLSv1.3 records the content type in the record header is always SSL3_RT_APPLICATION_DATA. the real content type for the record is contained in an "inner" content type. buf contains the encoded "inner" content type byte.
  • SSL3_RT_QUIC_DATAGRAM β€” used when a QUIC datagram is sent or received.
  • SSL3_RT_QUIC_PACKET β€” used when a QUIC packet is sent or received.
  • SSL3_RT_QUIC_FRAME_FULL β€” used when a QUIC frame is sent or received. this is only used for non-crypto and stream data related frames. the full QUIC frame data is supplied.
  • SSL3_RT_QUIC_FRAME_HEADER β€” used when a QUIC stream data or crypto frame is sent or received. only the QUIC frame header data is supplied.
  • SSL3_RT_QUIC_FRAME_PADDING β€” used when a sequence of one or more QUIC padding frames is sent or received. a padding frame consists of a single byte and it is common to have multiple such frames in a sequence. rather than supplying each frame individually the callback will supply all the padding frames in one go via this pseudo content type. efficiency slay ✨

⭐ RETURN VALUES ⭐

SSL_CTX_set_msg_callback(), SSL_CTX_set_msg_callback_arg(), SSL_set_msg_callback() and SSL_set_msg_callback_arg() do not return values. nothing to return, nothing to worry about, it's giving void πŸ’…


πŸŽ€ SEE ALSO πŸŽ€

ssl(7), SSL_new(3)


🌈 HISTORY 🌈

  • the pseudo content type SSL3_RT_INNER_CONTENT_TYPE was added in OpenSSL 1.1.1.
  • the pseudo content types SSL3_RT_QUIC_DATAGRAM, SSL3_RT_QUIC_PACKET, SSL3_RT_QUIC_FRAME_FULL, SSL3_RT_QUIC_FRAME_HEADER and SSL3_RT_QUIC_FRAME_PADDING were added in OpenSSL 3.2.
  • in versions previous to OpenSSL 3.0, cb was called with 0 as version for the pseudo content type SSL3_RT_HEADER for TLS records.
  • in versions previous to OpenSSL 3.2, cb was called with 0 as version for the pseudo content type SSL3_RT_HEADER for DTLS records.

Copyright 2001-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 it up fr fr πŸ“βœ¨ this was OpenSSL 3.5.9, dated 2026-09-29, and it's the SSL_CTX_SET_MSG_CALLBACK(3ossl) manual β€” now go trace some messages, you icon πŸ’…πŸ¦‹

πŸ“¦ where this page comes from