Feature Request: Investigate JA4 Fingerprint Calculation via SSL/TLS Handshake Data in Pingora

[SecAegis]

Description:

I am exploring the possibility of calculating JA4 (Client Fingerprints) using Pingora. Currently, I’m unsure if Pingora provides a way to extract the necessary SSL/TLS handshake data (like cipher suites, extensions, etc.) which could be used to generate a JA4 fingerprint.

Use Case:

We need client-specific tracking using JA4 fingerprints, which are based on SSL/TLS handshake data.

Questions/Requests:

Does Pingora allow access to SSL/TLS handshake information (e.g., cipher suites, extensions, etc.)?

If Pingora does not currently support this, are there any suggestions on how to extend its capabilities to capture the handshake data necessary for JA4?

Additional Information:

JA4 is a client-side fingerprint similar to JA3, and it's used to track clients based on SSL/TLS handshake details.

If Pingora doesn’t directly support this functionality, I would be happy to discuss ways to extend it and contribute to the project.

[cxw620]

pingora/pingora-core/src/protocols/mod.rs

Lines 87 to 107 in 1348489

	/// The abstraction of transport layer IO
	pub trait IO:
	AsyncRead
	+ AsyncWrite
	+ Shutdown
	+ UniqueID
	+ Ssl
	+ GetTimingDigest
	+ GetProxyDigest
	+ GetSocketDigest
	+ Peek
	+ Unpin
	+ Debug
	+ Send
	+ Sync
	{
	/// helper to cast as the reference of the concrete type
	fn as_any(&self) -> &dyn Any;
	/// helper to cast back of the concrete type
	fn into_any(self: Box<Self>) -> Box<dyn Any>;
	}

The approach with minimal changes may be like this: wrap T: IO with a wrapper struct and implement IO trait for it. You can even specifically read the ClientHello packet from TcpStream (and so on) via MSG_PEEK in the cost of generality, eliminating the need to maintain the logic of transparently transmitting already read data to Pingora.

This method offers the best compatibility with various TLS backends, since extract ClientHello from BoringSSL / Rustls /OpenSSL ctx is not something easy, while TLS has it's RFC and the handshake packet structure is known and fixed.

(Well this is just what I do in my simple L4 proxy)

Ref: