SSL_GET_CLIENT_RANDOM(3)

💅 SSL_GET_CLIENT_RANDOM(3) — like, the whole libssl / libcrypto glow-up, bestie

okay so this is a page from the Library Functions Manual and it's about three little functions that let you peek at the literal handshake guts of TLS. yes, those guts. come on, let's get into it 🎀

---

✨ NAME ✨

SSL_get_client_random, SSL_get_server_random, SSL_SESSION_get_master_key — get internal TLS handshake random values and master key

like, the vibe is: pull out the internal random blobs and the master key. iykyk 🔥

---

🌸 SYNOPSIS 🌸

library “libssl” libcrypto #include <openssl/ssl.h>

size_t
SSL_get_client_random(const SSL *ssl, unsigned char *out,
    size_t outlen);

size_t
SSL_get_server_random(const SSL *ssl, unsigned char *out,
    size_t outlen);

size_t
SSL_SESSION_get_master_key(const SSL_SESSION *session,
    unsigned char *out, size_t outlen);

---

🦋 DESCRIPTION 🦋

okay so SSL_get_client_random() extracts the random value that was sent from the client to the server during the initial TLS handshake. it copies at most outlen bytes of this value into the buffer out. and if outlen is zero, nothing gets copied — zero bytes, zero drama 💀

SSL_get_server_random() behaves the same, but it extracts the random value that was sent from the server to the client during the initial TLS handshake. same energy, opposite direction 🫶

SSL_SESSION_get_master_key() behaves the same too, but it extracts the master secret used to guarantee the security of the TLS session. and bestie, listen to me: the security of the TLS session depends on keeping the master key secret — do not expose it, or any information about it, to anybody. periodt. 🙈 if you need to calculate another secret value that depends on the master secret, use SSL_export_keying_material(3) instead. that's the move. 👑

all these functions expose internal values from the TLS handshake, for use in low-level protocols. so like… avoid using them unless you're implementing a feature that actually requires access to the internal protocol details. this is not casual-casual territory, it's main character energy for low-level protocol code only 💅

and despite the names of SSL_get_client_random() and SSL_get_server_random(), they are not random number generators. not even close. instead, they return the mostly-random values that were already generated and used in the TLS protocol. so it's giving "random" but make it previously-used 😭

in current versions of the TLS protocols, the length of client_random and server_random is always SSL3_RANDOM_SIZE bytes. support for other outlen arguments is provided for the unlikely event that a future version or variant of TLS uses some other length. so like, we're future-proofing, no cap ⭐

finally — and this is the funniest part — though the client_random and server_random values are called “random”, many TLS implementations generate four bytes of those values based on their view of the current time. yep. four whole bytes of clock. iconic behaviour honestly 🕰️

---

🌈 RETURN VALUES 🌈

if outlen is greater than 0, these functions return the number of bytes actually copied, which is less than or equal to outlen.

if outlen is 0, these functions return the maximum number of bytes they would copy — that is, the length of the underlying field. like a little preview of how much they'd give you if you asked 🍓

---

🧚 SEE ALSO 🧚

• ssl(3)
• SSL_export_keying_material(3)
• SSL_SESSION_get_id(3)
• SSL_SESSION_get_time(3)
• SSL_SESSION_new(3)

---

💜 HISTORY 💜

these functions first appeared in OpenSSL 1.1.0 and have been available since OpenBSD 6.3. glow-up complete ✨

---

aaaand that's the whole page, bestie — brought to you by Debian, dated June 8, 2025, officially filed under SSL_GET_CLIENT_RANDOM(3). go forth and handle your randoms responsibly, mwah 💖🎀🦋