Extensible `SslDigest` with user-defined SSL fields

[nojima]

What is the problem your feature solves, or the need it fulfills?

Currently, Pingora lacks sufficient support for processing client certificate information at the HTTP layer. While some data can be accessed through the SslDigest structure, important fields such as SNI and SAN are not available. This limitation becomes a blocker when implementing mTLS functionality on top of Pingora, as the application layer cannot access the necessary client identity information.

Describe the solution you'd like

I would like a feature that extends SslDigest to allow user-defined callbacks for extracting and storing arbitrary information from the SslRef.

The callback could have a signature like:

// openssl
Fn(&SslRef) -> Option<Box<dyn std::any::Any>>

// rustls
Fn(&rustls::CommonState) -> Option<Box<dyn std::any::Any>>

SslDigest would then hold a map of user-defined values keyed by their TypeId:

pub struct SslDigest {
    ...
    // User-defined entries
    values: BTreeMap<std::any::TypeId, Box<dyn std::any::Any>>,
}

Users could then retrieve their custom values using a helper method:

impl SslDigest {
    pub fn get<T: 'static>(&self) -> Option<&T> {
        self.values.get(&std::any::TypeId::of::<T>())
            .and_then(|b| b.downcast_ref::<T>())
    }
}

This design allows developers to flexibly embed and retrieve additional certificate-related data (like SNI, SAN, or other extensions).

Describe alternatives you've considered

An alternative approach would be to modify SslDigest directly to include specific fields such as SNI or SAN. However, this approach is less flexible and would require further upstream changes each time a new piece of SSL-related metadata is needed.

Additional context

There is an existing pull request adding SNI to SslDigest: #567.

[tqlab]

This feature is very important, for example, for generating fingerprint information such as JA3/JA4.

[drcaramelsyrup]

We think this is a good way to allow retrieving arbitrary user-defined data from the SSL contexts, if someone would be interested in implementing this we would review that PR.

[nojima]

@drcaramelsyrup @tqlab Thank you for your reply! I’d like to try creating a PR for this.