I have a mixed opinion. I tend to agree with Brian. I think the necessity of ifdef made the plugin only support OpenSSL. Similar things can happen on any plugins that rely on TLS info. In that sense, providing those APIs which Brian suggested would be nicer. However, those APIs are basically a compat layer for TLS libraries, and we may end up having a lot of those if we take that route.
Also, this may be a discussion topic on the PR rather than API proposal but, I'm wondering if SSL_CLIENT_INFO stays available even after leaving the callback function. Receiving a TSVConn may be a safer interface, although it is doable to keep a copy of everything that plugins might need. -- Masakazu On Thu, Jan 8, 2026 at 4:34 PM Brian Neradt <[email protected]> wrote: > Thank you for working on this, Jasmine. > > It is unfortunate to have an API that is half-boringssl-only that the > plugin then needs to #ifdef around: TSVConnClientHelloGet is > boringssl-only, but TSClientHello is for both openssl and boringssl. > > What do you think of encapsulating the details behind the API by providing > the following instead: > > TSReturnCode TSClientHelloExtensionGet(TSVConn sslp, int extension_type, > const uint8_t **out_data, size_t > *out_len); > > TSReturnCode TSClientHelloCiphersGet(TSVConn sslp, > const uint8_t **out_data, size_t > *out_len); > > uint16_t TSClientHelloVersionGet(TSVConn sslp); > > TSReturnCode TSClientHelloSessionIdGet(TSVConn sslp, > const uint8_t **out_data, size_t > *out_len); > > TSReturnCode TSClientHelloExtensionTypesGet(TSVConn sslp, > uint16_t **out_types, size_t > *out_count); > > > Then the plugin code works for both boringssl and openssl. The downside, of > course, is adding 5 functions to the API instead of 1, but I think I prefer > that tradeoff to the alternative complexity required by the plugin. > > On Wed, Jan 7, 2026 at 10:14 PM Jasmine Emanouel < > [email protected]> > wrote: > > > Hi ATS Community, > > > > > > TLDR; I propose a new TSAPI TSVConnClientHelloGet that will return the > > SSL_CLIENT_HELLO object, allowing plugins to access extension data when > > using boringssl. > > > > > > > > > > *Problem:* > > > > OpenSSL provides SSL_client_hello_get0_ext(), > > SSL_client_hello_get0_ciphers() and > > SSL_client_hello_get1_extensions_present() to get client hello data from > > an SSL object. BoringSSL doesn't have comparable functions. It requires > the > > SSL_CLIENT_HELLO object via SSL_early_callback_ctx_extension_get(). > > Currently, there's no way to get the SSL_CLIENT_HELLO object in plugins, > > which causes friction when writing SSL-related plugins that need to work > > with both libraries. > > > > > > *Proposed Solution:* > > > > > > TSClientHello TSVConnClientHelloGet(TSVConn sslp); > > > > > > This API provides access to the SSL_CLIENT_HELLO object within plugins > and > > is usable during SSL hooks > > (TS_SSL_CLIENT_HELLO_HOOK, TS_SSL_SERVERNAME_HOOK). > > > > > > *Use Case:* This enables plugins to access ClientHello data (cipher > suites, > > extensions, SNI, ALPN, supported TLS versions) when using BoringSSL. > > Currently, the ja4_fingerprint plugin only works for openssl, this change > > allows us to add boringssl support. > > > > > > *Implementation Notes:* > > > > - The SSL_CLIENT_HELLO is captured during the client hello callback > and > > stored in TLSSNISupport > > - The data is valid during SSL handshake hooks > > - For OpenSSL, plugins can continue using > > existing TSSslConnectionGet() approach > > > > > > This is a non-breaking addition. Existing OpenSSL-based plugins continue > to > > work unchanged. > > > > > > > > Here is the PR: https://github.com/apache/trafficserver/pull/12790 > > > > > > Thanks, > > > > Jasmine > > > > > -- > "Come to Me, all who are weary and heavy-laden, and I will > give you rest. Take My yoke upon you and learn from Me, for > I am gentle and humble in heart, and you will find rest for > your souls. For My yoke is easy and My burden is light." > > ~ Matthew 11:28-30 >
