Add TLS metadata to network connection data

[smith-xyz]

In stackrox/stackrox#19001, I proposed adding TLS handshake metadata (version, cipher suite, key exchange algorithm, SNI) to network flows. After reviewing and understanding the Collector side more, this seems like it could be a significant addition. Today all eBPF collection goes through Falco's modern_bpf tracepoints, which operate at the syscall level. There's no packet-level inspection.

Capturing TLS metadata requires inspecting the ClientHello and ServerHello messages on the wire. This can be done without decrypting traffic since the handshake is plaintext up to the point where encryption begins.

A proposed approach:

Attach a BPF socket filter or TC classifier to network interfaces that:

1. Identifies TCP segments containing TLS handshake records (content type 0x16)
2. Parses ClientHello for SNI and supported key exchange groups
3. Parses ServerHello for negotiated TLS version, cipher suite, and key exchange group
4. Emits structured events (keyed by 5-tuple) to userspace via ring buffer

Userspace correlates these events with the existing ConnTracker 5-tuple state and populates the tls_info field on NetworkConnection in ConnToProto().

This would be a standalone BPF program loaded via libbpf, separate from the Falco probe. I noticed #1460 and #1461 discuss custom CO-RE BPF -- is that infrastructure something this should build on, or is this different enough to warrant its own loader?

For reference:

I have a working Rust/eBPF implementation that does this with TC classifiers: https://github.com/smith-xyz/tls-probe. The BPF side is portable -- the parsing logic for ClientHello/ServerHello is language-agnostic.

NetObserv's eBPF agent has an open PR for TLS version tracking (netobserv/netobserv-ebpf-agent#815) using a similar packet inspection approach.

Some open questions:

• Is TC classifier vs socket filter preferred? TC gives ingress+egress visibility but requires interface attachment. Socket filter is simpler but may miss some traffic depending on attachment point.
• Should this integrate with the custom CO-RE BPF work (Toggle for custom CO-RE BPF #1460/Compile-time switch for custom CO-RE BPF #1461) or be separate?
• Any concerns about running a second BPF program alongside the Falco probe on production nodes?

Happy to contribute this. The stackrox/stackrox side (proto, Sensor/Central pipeline, DB migration) is straightforward plumbing -- the Collector BPF capture seems to be a larger shift into having custom BPF probes.

[mtodor]

Hi @smith-xyz! Tnx for the proposal! I have created ticket to track this: ROX-33510

[Molter73]

Hi @smith-xyz,

We are discussing this internally with the team, a short summary for the discussion so far would be along the lines of:

• As you notice, us loading a probe separate from Falco requires significant effort that we can't seem to get capacity for.
• NetObs is usually what has been considered as the place to implement things related to networking, particularly w.r.t dissecting packets, so this issue falls in a bit of a grey area. As you point out, there is already some effort there to implement something along these lines.
• There is a separate BPF based component we are currently working on that is also based in Rust and aya called fact. This separate project is currently based around catching file system activity, but we are interested in finding other ways to leverage this, your PoC might fit better in that context.

The BPF side is portable -- the parsing logic for ClientHello/ServerHello is language-agnostic.

I peeked into the implementation and the BPF side is written in Rust it seems, this requires a nightly compiler and I'm not sure this is something we can get in our production pipelines. Changing it to C shouldn't be too much effort I suppose though.

[smith-xyz]

@Molter73 thank you for the follow up. fact reads as file-activity–specific; adding a network/TLS probe there feels like a scope stretch. Are you imagining fact broadening into a general custom-BPF project, or would it make more sense to have a separate component for network/TLS (even if it’s still Rust/aya and not in Collector)?

On the NetObserv angle: should we pursue contributing to NetObserv (eBPF agent or operator) to pipe TLS metadata—or flow data that includes it—into StackRox/ACS? Or does any integration from the NetObserv operator into StackRox already exist today that we could build on?

One downside I see: going through NetObserv adds a dependency for customers (they have to run the NetObserv operator), whereas having this in Collector would keep everything under the existing ACS eBPF stack. Curious how you weigh that.

[Molter73]

Are you imagining fact broadening into a general custom-BPF project, or would it make more sense to have a separate component for network/TLS (even if it’s still Rust/aya and not in Collector)?

We are considering moving our process pipeline over to fact, so definitely a possibility to grow it. We also don't have to have this probe be part of the main fact binary, we can have a separate crate for it and leverage the CI infrastructure that is in place to package that into the final image, then we deploy separate containers with different entrypoints with the same container for every use case, we do a similar thing with the main image for stackrox. We need to have a broader discussion with the team, but we currently are a bit short on capacity to have a proper design for this, so it might take some time.

On the NetObserv angle: should we pursue contributing to NetObserv (eBPF agent or operator) to pipe TLS metadata—or flow data that includes it—into StackRox/ACS? Or does any integration from the NetObserv operator into StackRox already exist today that we could build on?

We have considered the option of replacing our network implementation with the netobserv ebpf agent, we haven't had capacity to pursue this further though. I think implementing this feature in netobs side doesn't really hurt us either, but there is no integration between the two projects in place ATM.

One downside I see: going through NetObserv adds a dependency for customers (they have to run the NetObserv operator), whereas having this in Collector would keep everything under the existing ACS eBPF stack. Curious how you weigh that.

Yeah, this is basically why there is no integration between the two yet.