Fsecurity
Forward proxy
A proxy the client must use to reach a transfer host, often inspecting TLS.
How it works
Inspection decrypts, scans, and re-encrypts. The file is visible to the proxy. Pinning that rejects the proxy certificate breaks the upload. Bypass rules exist for banking and sometimes for file transfer. Know which you are on.
A laptop upload to a bucket fails certificate pinning. The corporate proxy is intercepting. A bypass for the storage host restores the upload and skips inspection. Security signs the bypass. Silent disable of pinning would have hidden a real attacker too.
How it differs
A forward proxy is not a CDN. One sits on the way out. The other sits on the way in to recipients.
A proxy with a small body limit kills large uploads.
Raise it or bypass.
On the ticket
- The practical close is a log line: time, actor, byte count, result.
- Without that line the transfer is a story.
- With it, the next person can see whether this door did what the ticket claimed.
- If the path is shared, say so in the partner profile so a later change does not silently pick a different limit, key, or region.
- On a real ticket, write down the door, the byte count, and the clock.
- For forward proxy, that means naming the host or bucket, the expected size, and the time the other side must have a complete file.
- A progress bar is not that record.
- A 200 response that arrives before the complete call is not that record.
- If a retry is allowed, say how many and whether it resumes.
- If a person must approve the send, name the person.
- Partners who receive forward proxy files should match on hash or size before they import.
- A same-length corrupt file passes a size check and fails a hash.
- Keep the published hash off the only channel an attacker can edit, or treat it as a corruption check rather than a substitution check.
- When the path changes, new key, new region, new cap, update the profile the same day so the next run does not use a stale limit.
Related
Sources
- RFC 8446, TLS 1.3
Session encryption