FOUNDRYNETNo. 001SEPTEMBER 2026SECTION 06PROVENANCE
Provenance on the Wire: Authenticity at the Network Layer
Six guides on what the network itself can prove about content: who fetched it, where it came from, that it arrived unchanged, and how to keep the evidence. The section is new; it inherits the security advisory, ServerIron SSL and sFlow chapters of the old site.
06 Contents
- Bot Verification: Proving a Crawler Is Who It Claims to BeHow-to
A user-agent string is a claim. Bot verification is the procedure that turns the claim into a checked fact, using DNS, the operator's published address list and, where offered, a signature on the request.
- mTLS Between Edge and Origin: Mutual TLS as Proof of Both EndsHow-to
Ordinary TLS proves the server to the client. Mutual TLS adds the reverse proof, so an origin can be certain that the connection it is answering came from its own edge and not from anyone who found its address.
- Content Integrity in Transit: Proving a Response Arrived UnchangedGuide
TLS protects a hop. Content integrity is the harder question of whether the bytes a client received are the bytes the publisher produced, across every cache, proxy and rewrite between them.
- Edge Logs as Evidence: An Audit Log That Proves What Was ServedHow-to
An access log is a record. An audit log is a record that someone else can trust. The difference is in the time source, the fields, the signature on each block and the storage nobody can quietly edit.
- RPKI and Route Origin Validation: Proving a Route Is AuthenticGuide
A BGP announcement is a claim, and for most of the protocol's life there was no standard way to check it. RPKI turns the address registries into a signed record of which network may originate which prefix.
- C2PA Through a CDN: Serving Content Credentials Without Breaking ThemHow-to
A C2PA manifest is a signed statement about an asset, bound to the asset's bytes. Every stage of a delivery pipeline that touches those bytes can silently destroy it, and most image pipelines touch them by default.
- Image Metadata Through the Pipeline: What Survives OptimisationGuide
A photograph carries several independent metadata blocks, each in its own container segment. Resizers, optimisers and platforms treat them differently, and an operator who has not decided what to keep has decided by accident.
- Verifying Bots With HTTP Message SignaturesHow-to
User-agent strings can be copied and IP lists go stale. A signature over the request, made with a key the operator publishes, is the first bot identity check that cannot simply be typed into a header.
- AI Crawler Traffic: Identifying LLM Bots at the Network EdgeGuide
AI crawlers announce themselves with a user-agent token, but the token is a claim; the network edge is where the claim gets checked against DNS, address ranges and behaviour.
- Bot vs Human Traffic: Fingerprinting Automated ClientsGuide
No single signal separates a script from a person, but a TLS handshake, an HTTP/2 preface, a TCP SYN and a click rhythm each leak something, and together they make a usable score.
- Archiving Dead Vendor Documentation HonestlyGuide
When a vendor disappears, its manuals scatter across forum attachments, reseller sites and web archives. Some copies are real, some are edited, and a growing share of what circulates about old gear is generated text that never came from any manual.
06.1 Orientation
Content provenance is usually discussed as a property of files: a signed manifest, a metadata field, a watermark. This section takes the network engineer's view instead. Between a client and an origin there are half a dozen places where identity and integrity can be checked with tools the network already has, and a small number of places where it cannot. The guides here cover both, in the order an operator meets them: the client, the path, the origin, the logs, and finally the content itself as it passes through caches and image pipelines.
Start at the client. A request claiming to be a search crawler or an agent is a claim until it is checked, and verifying a bot's identity sets out the three checks in order of strength: forward-confirmed reverse DNS, published address ranges, and a signature over the request. The signature method is a standard of its own, RFC 9421, and HTTP message signatures for bots in the monitoring section walks through the headers and the key lookup. Where an operator has neither, crawler identification by DNS and address list and behavioural bot detection cover the older, weaker signals and what they are still good for.
Then the path. A reverse proxy or CDN edge that talks to an origin over plain TLS proves the origin's identity to the edge but not the edge's identity to the origin, and client certificates on the edge-to-origin leg closes that gap with a client certificate on the edge side. That the bytes were not altered on the way is a separate question, answered by proving bytes were not altered in transit: TLS, Subresource Integrity, the Digest fields of RFC 9530, and plain hashes compared at both ends. Below the transport sits routing, and RPKI route origin validation explains how a holder's signed ROA lets every validating network reject a hijacked prefix before a single TLS handshake is attempted.
Evidence has to be kept. Edge logs that can serve as evidence covers what a log must have, tamper-evident storage, signing, clock discipline and retention, so that a claim about who fetched what and when can be supported later. A log that was written by the same system it describes, on a clock nobody checked, is a note, not a record. This is where the site's older material rejoins the new: the sFlow sampling guide explains the statistical record of who talked to whom that a switch can keep independently of any application log.
Finally the content. Signed provenance records now travel inside media files, and a pipeline that resizes, converts or strips will destroy them without any error. C2PA manifests through a CDN is the operator's procedure for passing signed originals through caches and optimisers intact, and image metadata through the pipeline sets out where EXIF, IPTC, XMP, ICC and C2PA blocks live in each format, which operations strip them, and how to decide deliberately between provenance and privacy.
Two limits apply throughout. The network can prove that a request came from a holder of a particular key, that a route was authorised by a prefix holder, and that a file arrived with the bytes it left with. It cannot prove that the content is true, that a signer is honest, or that a request a person authorised was a good idea; and no page here makes accuracy claims about tools that guess whether text was machine-written, which is a different lane. Read in the order above, or start from whichever hop is failing. The recovered documents in the margin are the security advisory archive, the ServerIron SSL and health-check chapters and the sFlow and port-monitoring chapters, kept as described in the note on archived vendor documentation.