Short-lived processes complete before eBPF hooks can attach - possible enhancement?

[aman1105-sa]

I've been using eCapture v1.4.3 in a production Kubernetes environment to monitor SSL/TLS traffic, and it's working great for long-running services. However, I've noticed that short-lived processes (like
curl, wget, or any script that makes a quick HTTPS call and exits) complete their SSL operations before eCapture's eBPF hooks can attach.

Environment:

• eCapture version: v1.4.3
• Kernel: 6.8.0 (x86_64)
• Libraries detected: OpenSSL 3.0, OpenSSL 1.1.1, GnuTLS 3.x
• Deployment: DaemonSet mode, auto-detecting libraries every 30 seconds

Expected behavior:
Capture SSL/TLS plaintext from all processes, including short-lived ones.

Actual behavior:

• ✅ Long-running processes (web servers, APIs, databases): captured successfully
• ❌ Short-lived processes (curl, wget, one-off scripts): complete before hooks attach

Example scenario:

This completes in ~500ms, hooks attach too late

curl https://api.example.com/endpoint

eCapture log shows:

"Found openssl in PID 12345"

"Starting eCapture for PID 12345"

But by then, curl has already finished and exited

My understanding:
I believe this happens because:

1. eCapture scans /proc to find processes with SSL libraries loaded
2. eBPF uprobes are attached to those PIDs
3. But if the process completes the SSL handshake and exits before step 2 finishes, we miss the traffic

Question:
Is there a way to work around this timing issue? Some ideas (not sure if feasible):

1. Could eCapture attach probes globally to the SSL library files (e.g., /usr/lib/libssl.so) instead of per-process, so the hooks are already active when any process loads the library?
2. Could we use a combination of kprobe on execve() + fast uprobe attachment to catch new processes immediately as they start?
3. Is there a tracepoint or alternative hooking mechanism that doesn't have this race condition?

I understand this might be a fundamental limitation of how eBPF uprobes work with process attachment, but I wanted to check if there's a known solution or if this could be a potential enhancement.

[dosubot]

Hi @aman1105-sa! I'm Dosu and I’m helping the ecapture team.

You’re right that short-lived processes can finish before eBPF uprobes attach if probes are only attached after process discovery. However, eCapture supports a global uprobe attachment model: you can specify the path to the SSL library (e.g., --libssl=/path/to/libssl.so) and eCapture will hook the relevant functions in that library for all processes that load it, not just for specific PIDs. This approach allows you to capture SSL/TLS plaintext from short-lived processes like curl or wget as long as the probe is attached to the library before those processes start. This is the recommended and supported method for containerized environments, and there are examples of it working for short-lived processes if the correct library path is used and eCapture is started early enough (example).

There’s no evidence that eCapture currently uses kprobes on execve() or similar mechanisms to trigger immediate uprobe attachment for new processes. The global uprobe strategy is the main workaround for the timing issue you described. If you have multiple versions or copies of SSL libraries (common in Kubernetes), you may need to run multiple eCapture instances, each targeting a different library path.

If you’re still missing traffic, double-check that the SSL library path is correct for your target processes, and that eCapture is running with sufficient privileges. For even more robust capture (especially with OpenSSL 3.x or BIO-based apps), consider using the keylog+pcapng mode, which is being discussed as a future enhancement to address some of the remaining race and association issues (discussion).

Let me know if you want practical steps for finding the right library path in your environment!

To reply, just mention @dosu.

---

^{How did I do? Good | Irrelevant | Incorrect | Verbose | Hallucination | Report 🐛 | Other}    

[cfc4n]

Could eCapture attach probes globally to the SSL library files (e.g., /usr/lib/libssl.so) instead of per-process, so the hooks are already active when any process loads the library?

You need to confirm whether the captured processes share the same SSL library. If so, you can specify it via the libssl parameter in the command line.

Could we use a combination of kprobe on execve() + fast uprobe attachment to catch new processes immediately as they start?

It is technically feasible, but it should not be within the scope of ecapture's support.