bpf: object bodies beginning with "HTTP/1." are captured as a response head

[echemythia]

looks_like_http_response (bpf/include/s3tap_parse.h) is a pure 7-byte prefix test for
HTTP/1., and ssl_read_capture (bpf/src/s3tap.bpf.c) calls it on every SSL_read
return with no per-connection state.

So an S3 object whose bytes happen to begin with HTTP/1. — an HTTP log, a proxy capture,
an .http fixture — is treated as a response head. Up to ~4095 bytes of real object
content are copied into evt_tls_data, reach userspace, and can be printed unlabeled by
--dump-events.

This is currently an ACCEPTED tradeoff, documented at the recognizer, at the call site, and
pinned by name in bpf/tests/parser_tests.c
("http: a body chunk beginning with a status line IS misread as a head (accepted)").
Filing it so the acceptance is a tracked decision rather than only a comment.

Suggested fix

A per-(tgid, ssl) "a response is expected now" bit: set when a request write is captured,
cleared when a response head is consumed. The recognizer then only fires at a genuine
message boundary instead of on arbitrary body bytes.

Needs a new LRU map and correct handling of pipelined/persistent connections carrying
several in-flight request/response pairs, so it is a capture-path design change rather than
a small patch.

Affected

bpf/include/s3tap_parse.h, bpf/src/s3tap.bpf.c (ssl_read_capture),
crates/s3tap-cli/src/main.rs (--dump-events rendering).

[echemythia]

Additional nuance from the core/eBPF review: the correlator already prevents one important correctness failure here. If an operation is awaiting a declared Content-Length body, on_tls_read treats later head-looking bytes as body until the declared target is met, so an object chunk beginning with HTTP/1. does not overwrite that already-open response state or close the operation early.

That does not close this issue. The privacy boundary is still crossed before userspace gets a chance to apply that guard: ssl_read_capture classifies the buffer in-kernel, copies up to the head cap into EVT_TLS_READ, and only then does the correlator decide how to interpret it. So the issue remains specifically about avoiding the kernel-side plaintext copy unless a response head is actually expected at a message boundary.

[echemythia]

Deep BPF review addendum:

The same privacy boundary also applies on the request side, not only to downloaded object bodies beginning with HTTP/1..

looks_like_http_request currently admits buffers beginning with GET /, PUT /, HEAD /, POST /, OPTIONS or DELETE, and ssl_write_capture then copies up to HDR_CAP - 1 bytes into EVT_TLS_WRITE. A PUT/POST body chunk or uploaded object content that happens to begin with one of those request-looking prefixes can therefore be copied as if it were an HTTP request head.

Relevant paths:

• bpf/include/s3tap_parse.h:353
• bpf/src/s3tap.bpf.c:1641
• bpf/tests/parser_tests.c:1232

The userspace awaiting-body guard mitigates some response-side mis-correlation, but it runs after the kernel has already emitted the copied plaintext event. So this remains a capture/privacy issue, not only a correlator accuracy issue.