Skip to content

docs(sandbox): the forensic-egress allowlist is a destination filter, not read-only - #3075

Merged
Xore merged 1 commit into
mainfrom
fix/8-3072-forensic-egress-header
Sep 6, 2026
Merged

Xore merged 1 commit into
mainfrom
fix/8-3072-forensic-egress-header

Conversation

@Xore

@Xore Xore commented Sep 6, 2026

Copy link
Copy Markdown
Owner

Refs #3072 — deliberately not Closes. This lands only the cheap half of that issue: the stated-intent/actual-enforcement mismatch. The enforcement gap itself (an allowlisted domain is a bidirectional channel) is untouched, and both of #3072's real directions — TLS interception, or splitting read-only from write-capable destinations — stay open and unforeclosed.

What was wrong

sandbox/forensic-egress-allowed-domains.txt was headed # Retrieval-only domains available to proxy-aware forensic samples., and docs/sandbox/README.md described the same component as a "retrieval proxy". Neither property is enforced anywhere:

  • The ACL is acl allowed_forensic_domains dstdomain "/etc/honeypot-sandbox/allowed-domains.txt", gating CONNECT. Once the TLS tunnel is established squid parses no HTTP inside it — it cannot distinguish a fetch from an upload, a git clone from a git push, or a raw read from a Gist/release/API write.
  • safe_ports includes 80 and the allow rule is not connect_method-restricted, so plain-HTTP POST to an allowlisted domain is permitted as well.
  • reply_body_max_size / request_body_max_size do not bound the tunnel. They act on HTTP message bodies squid parses, and a CONNECT tunnel has none — so tunneled traffic is size-unbounded in both directions, not capped at 1 MB.
  • What does survive as mitigation is the access_log entry for the CONNECT: destination host, port, transferred byte counts. After-the-fact detection of volume, not prevention, and not content.
  • .github.io compounds it: GitHub Pages is shared multi-tenant hosting, so an attacker-controlled <name>.github.io is inside the list by construction.

What this changes

Documentation only. The allowlist header now states the operator intent and the enforcement boundary, and the README's provisioning step says the allowlist bounds where a sample may connect, not what it may do there.

No behavioural change: squid ignores # lines in an ACL file, and sandbox/install-forensic-egress.sh → forensic-egress-squid.conf is the only consumer of this file.

… not read-only

The allowlist was headed "Retrieval-only domains available to proxy-aware
forensic samples", and the sandbox README described the same thing as a
"retrieval proxy". Neither is enforced. Squid gates these names with
`dstdomain` on CONNECT and then parses no HTTP inside the established
tunnel, so it cannot distinguish a fetch from an upload, a clone from a
push, or a raw read from a Gist/release/API write. Plain HTTP to port 80
against the same names is permitted too, since the allow rule is not
CONNECT-restricted.

The size caps do not close that either: `request_body_max_size` and
`reply_body_max_size` act on message bodies squid parses, and a CONNECT
tunnel has none, so tunneled traffic is unbounded in both directions. What
actually remains is the access_log entry for the CONNECT -- host, port and
byte counts, i.e. after-the-fact detection of volume, not prevention and
not content.

Says so, in both places, and notes that .github.io is shared multi-tenant
hosting so an attacker-controlled <name>.github.io is inside the list by
construction.

Documentation only -- no enforcement change, and this deliberately
forecloses none of the directions in #3072 (TLS interception, splitting
read-only from write-capable destinations). Squid ignores `#` lines in an
ACL file, and nothing but squid reads this file.

Refs #3072
@github-actions

github-actions Bot commented Sep 6, 2026

Copy link
Copy Markdown

Dependency Review

✅ No vulnerabilities or license issues or OpenSSF Scorecard issues found.

Scanned Files

None

@Xore
Xore merged commit 31f2e09 into main Sep 6, 2026
124 checks passed
@Xore
Xore deleted the fix/8-3072-forensic-egress-header branch September 6, 2026 08:26
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant