Hi ATS Community,
TLDR; I've revised the proposal to use a TSClientHello type that abstracts OpenSSL/BoringSSL differences, providing a consistent API for accessing ClientHello data. Updated Design: TSClientHello TSVConnClientHelloGet(TSVConn sslp); void TSClientHelloDestroy(TSClientHello ch); TSReturnCode TSClientHelloExtensionGet(TSClientHello ch, unsigned int type, const unsigned char **out, size_t *outlen); Key Changes from Original Proposal: - Opaque type instead of direct SSL_CLIENT_HELLO exposure - provides library-agnostic interface - Accessor methods on TSClientHello for version, cipher suites, extensions - Helper function TSClientHelloExtensionGet() for retrieving specific extensions (e.g., ALPN, SNI) - Memory management - caller must free with TSClientHelloDestroy() Benefits: - Works identically with OpenSSL and BoringSSL - Hides implementation details from plugin authors - Non-breaking - existing plugins continue to work unchanged - Enables ja4_fingerprint plugin to support both SSL libraries PR: https://github.com/apache/trafficserver/pull/12790 Thanks Jasmine On Fri, 9 Jan 2026 at 11:55, Masakazu Kitajo <[email protected]> wrote: > 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 > > >
