SSL_CTX_SET_TLSEXT_USE_SRTP(3ossl)

๐Ÿ’– SSL_CTX_set_tlsext_use_srtp ๐Ÿ’– โ€” like, the whole SRTP situation, explained

okay so bestie, this one lives in the OpenSSL family and it's filed under manual section 3ossl. It's the page for SSL_CTX_set_tlsext_use_srtp, SSL_set_tlsext_use_srtp, SSL_get_srtp_profiles, and SSL_get_selected_srtp_profile โ€” four little icons, one whole vibe. Let's get into it ๐Ÿซถ


โœจ NAME โœจ

SSL_CTX_set_tlsext_use_srtp, SSL_set_tlsext_use_srtp, SSL_get_srtp_profiles, SSL_get_selected_srtp_profile โ€” literally just here to configure and query SRTP support. That's the job. That's the whole assignment ๐Ÿ’…


๐ŸŽ€ SYNOPSIS ๐ŸŽ€

okay so you gotta include the header first, always:

#include <openssl/srtp.h>

and then the four functions, in all their glory:

int SSL_CTX_set_tlsext_use_srtp(SSL_CTX *ctx, const char *profiles);
int SSL_set_tlsext_use_srtp(SSL *ssl, const char *profiles);

STACK_OF(SRTP_PROTECTION_PROFILE) *SSL_get_srtp_profiles(SSL *ssl);
SRTP_PROTECTION_PROFILE *SSL_get_selected_srtp_profile(SSL *s);

๐ŸŒธ DESCRIPTION ๐ŸŒธ

so. SRTP is the Secure Real-Time Transport Protocol. OpenSSL ships support for the "use_srtp" DTLS extension, the one defined in RFC5764. It's giving... a whole mechanism for establishing SRTP keying material, algorithms and parameters, all via DTLS. This capability can be used as part of an implementation that conforms to RFC5763. ๐Ÿฆ‹

โš ๏ธ and this is important bestie: OpenSSL does not implement SRTP itself, and it does not implement RFC5763. It's just the handshake-side bestie, not the whole thing.

more caveats, because of course:

  • OpenSSL does not support SRTP Master Key Identifiers (MKIs). nope, not a thing here.
  • This extension is only supported in DTLS. Any SRTP configuration will be ignored if a TLS connection is attempted. like, straight up ignored. ๐Ÿซ 

๐Ÿ’ซ setting it up ๐Ÿ’ซ

An OpenSSL client that wants to send the "use_srtp" extension should call SSL_CTX_set_tlsext_use_srtp() โ€” that turns it on for all SSL objects created from that SSL_CTX afterward. Or, if you're feeling specific, the client can call SSL_set_tlsext_use_srtp() to set it for one individual SSL object instead.

the profiles parameter? point it at a NUL-terminated, colon delimited list of SRTP protection profile names. colon delimited. write that down ๐Ÿ“

๐Ÿ‘‘ the protection profile names that are currently supported ๐Ÿ‘‘

  • SRTP_AES128_CM_SHA1_80 โ€” corresponds to SRTP_AES128_CM_HMAC_SHA1_80 as defined in RFC5764.
  • SRTP_AES128_CM_SHA1_32 โ€” corresponds to SRTP_AES128_CM_HMAC_SHA1_32 as defined in RFC5764.
  • SRTP_AEAD_AES_128_GCM โ€” corresponds to the profile of the same name defined in RFC7714.
  • SRTP_AEAD_AES_256_GCM โ€” corresponds to the profile of the same name defined in RFC7714.
  • SRTP_DOUBLE_AEAD_AES_128_GCM_AEAD_AES_128_GCM โ€” corresponds to the profile of the same name defined in RFC8723.
  • SRTP_DOUBLE_AEAD_AES_256_GCM_AEAD_AES_256_GCM โ€” corresponds to the profile of the same name defined in RFC8723.
  • SRTP_ARIA_128_CTR_HMAC_SHA1_80 โ€” corresponds to the profile of the same name defined in RFC8269.
  • SRTP_ARIA_128_CTR_HMAC_SHA1_32 โ€” corresponds to the profile of the same name defined in RFC8269.
  • SRTP_ARIA_256_CTR_HMAC_SHA1_80 โ€” corresponds to the profile of the same name defined in RFC8269.
  • SRTP_ARIA_256_CTR_HMAC_SHA1_32 โ€” corresponds to the profile of the same name defined in RFC8269.
  • SRTP_AEAD_ARIA_128_GCM โ€” corresponds to the profile of the same name defined in RFC8269.
  • SRTP_AEAD_ARIA_256_GCM โ€” corresponds to the profile of the same name defined in RFC8269.

and if you supply a protection profile name that isn't recognised? error. that's it. that's the consequence ๐Ÿ’€

๐Ÿงš server side, same energy ๐Ÿงš

An OpenSSL server that wants to support the "use_srtp" extension should also call SSL_CTX_set_tlsext_use_srtp() or SSL_set_tlsext_use_srtp() โ€” that's how it announces which protection profiles it's willing to negotiate. everyone has to say what they want, no guessing games ๐ŸŒˆ

๐Ÿ” looking at what's configured ๐Ÿ”

The currently configured list of protection profiles โ€” for a client or a server โ€” comes from calling SSL_get_srtp_profiles(). It hands you back a stack of SRTP_PROTECTION_PROFILE objects.

๐Ÿ™ˆ do not free the memory pointed to by this function's return value. it's not yours. put it down.

โญ after the handshake โญ

Once a handshake has been completed, the negotiated SRTP protection profile (if any) can be obtained โ€” on the client or the server โ€” by calling SSL_get_selected_srtp_profile(). If no SRTP protection profile was negotiated, it returns NULL.

๐Ÿ™ˆ same rule again: the memory returned from this function should not be freed by the caller.

๐Ÿ”‘ the keying material part (iykyk) ๐Ÿ”‘

If an SRTP protection profile has been successfully negotiated, then the SRTP keying material โ€” on both client and server โ€” should be obtained via a call to SSL_export_keying_material(3).

That call should provide:

  • a label value of "EXTRACTOR-dtls_srtp"
  • a NULL context value (so use_context is 0)

and the total length of keying material you get should equal two times the sum of the master key length and the salt length as defined for the protection profile in use. ๐Ÿงฎ

what does that give you, in order? the client write master key, the server write master key, the client write master salt, and the server write master salt โ€” in that exact order. don't shuffle them bestie, order matters โœจ

๐Ÿšซ QUIC says no ๐Ÿšซ

These functions cannot be used with QUIC SSL objects.

  • SSL_CTX_set_tlsext_use_srtp() fails if called on a QUIC SSL context.
  • SSL_set_tlsext_use_srtp() fails if called on a QUIC SSL object.

๐Ÿ’œ RETURN VALUES ๐Ÿ’œ

okay so read this carefully because the numbers are doing a little troll thing:

  • SSL_CTX_set_tlsext_use_srtp() and SSL_set_tlsext_use_srtp() return 0 on success or 1 on error.
  • SSL_get_srtp_profiles() returns a stack of SRTP_PROTECTION_PROFILE objects on success, or NULL on error or if no protection profiles have been configured.
  • SSL_get_selected_srtp_profile() returns a pointer to an SRTP_PROTECTION_PROFILE object if one has been negotiated, or NULL otherwise.
๐Ÿ’€ yes, the setters really are backwards from what your brain expects. 0 = slay, 1 = not slay. check it every single time, no cap.

๐Ÿ”ฅ SEE ALSO ๐Ÿ”ฅ

ssl(7), SSL_export_keying_material(3)


Copyright 2017-2023 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, you ate it ๐Ÿซถ this was OpenSSL 3.5.9, dated 2026-09-29, and honestly? iconic. go negotiate some SRTP. periodt ๐Ÿ’…โœจ

๐Ÿ“ฆ where this page comes from