S3 — TLS scan verification

S3 — TLS scan / mTLS / field crypto

Edge terminates TLS; this Worker sanitizes JSON, masks Luhn-valid PANs, redacts private IPs, strips debug objects, and can decrypt/re-encrypt AES-GCM field envelopes. Live capability calls require a trusted client certificate.

Capability host rejects callers without a valid client cert. Origin host is open for the unprotected direct fixture.

Browser vs command line: a browser cannot read a local PEM/key through page JavaScript. The browser check first runs the real Worker’s read-only structural policy against a synthetic fixture at /__rs/browser-proof, then separately shows the protected API identity result. A positive API result requires the client certificate to be installed in the browser or operating-system certificate store. The command-line section uses the operator-held certificate with curl; a hosted container or sandbox would hold that credential on behalf of the caller and would not prove the caller’s own browser identity.

Key questions

Question

Can S3 protect and scan its real payload classes without using forged identity headers?

Yes. Native request.cf.tlsClientAuth gates the capability; the Worker structurally processes 1 KiB and 500 KiB JSON and passes 10 MiB binary through unread. S3 does not transform HTML.

Success criteria / proof

Native identity gates access.Only verified native client-certificate identity is accepted; forged x-rs-mtls-* headers do not authenticate.
Response data is sanitized.Synthetic XSS strings are encoded, valid PANs are masked, private IPs are removed, public IPs remain, and debug keys are deleted.
JSON structure is preserved.The structural scan returns valid JSON and fails closed for invalid JSON or authentication errors.
Opaque payloads bypass scanning.Binary responses are forwarded without reading or modifying their bytes.
Field crypto is authenticated.AES-256-GCM envelopes use the configured key ring and reject unknown keys or authentication failures.

2. Command-line verification (copy and run)

Set the certificate paths to operator-held files; never commit the pair.

Step 1 — Capture the before fixture

The direct origin is open and intentionally returns raw synthetic policy data.

curl -sS https://s3-origin.thecompany-lab.com/api/fixture | jq .

Step 2 — Confirm rejection without identity

The capability must reject a request that has no native client certificate.

curl -sS -o /dev/null -w '%{http_code}
'   https://s3.thecompany-lab.com/api/fixture   # expect 403

Step 3 — Capture the after fixture with identity

Use the local certificate pair. The response should be HTTP 200 and contain sanitized synthetic data.

CERT_DIR="${S3_MTLS_CERT_DIR:-.local/s3-mtls}"
CLIENT_CERT="${S3_CLIENT_CERT:-$CERT_DIR/client.pem}"
CLIENT_KEY="${S3_CLIENT_KEY:-$CERT_DIR/client.key}"
curl -sS --cert "$CLIENT_CERT" --key "$CLIENT_KEY"   https://s3.thecompany-lab.com/api/fixture | jq .

Step 4 — Verify inbound JSON sanitization

Send a synthetic XSS string through the capability and inspect the encoded response.

curl -sS --cert "$CLIENT_CERT" --key "$CLIENT_KEY"   -H 'Content-Type: application/json'   -d '{"user":{"displayName":"<script>alert(1)</script>"}}'   https://s3.thecompany-lab.com/api/echo | jq .

Step 5 — Verify opaque binary pass-through

The binary response should be byte-identical before and after the capability.

curl -sS --cert "$CLIENT_CERT" --key "$CLIENT_KEY"   'https://s3.thecompany-lab.com/api/binary?size=65536' -o /tmp/s3-after.bin
curl -sS 'https://s3-origin.thecompany-lab.com/api/binary?size=65536' -o /tmp/s3-before.bin
cmp /tmp/s3-before.bin /tmp/s3-after.bin && echo byte-identical

Outbound origin client-certificate proof is an accepted gap for this proxied origin topology. PAN masking is hygiene, not PCI certification.