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.
- Syslog as Evidence: Provenance and Integrity of Network LogsHow-to
A syslog line is only as good as the path it took. Which device wrote it, which clock stamped it, how it travelled and whether anyone could change it afterwards decide whether the line is evidence or just text.
- Audit Trail for Network Changes: An Authorship RecordHow-to
A network audit trail answers one question for every configuration change: who did it, when, from where, and what the device looked like before and after. No single system holds all four answers, so the trail is built from several.
- Packet Capture as Evidence: Chain of Custody for pcap FilesHow-to
A packet capture is only as believable as the record of how it was taken and kept. This page covers the capture points, the pcap and pcapng formats, the hashes and the custody record that turn a trace into evidence.
- Network Forensics: Provenance of Captures, Flows and LogsGuide
Network forensics rebuilds an event from three kinds of record: packet captures, flow records and device logs. Each is made by a different mechanism, carries a different provenance and proves a different thing. An investigation is only as strong as its weakest record.
- DNSSEC: How a Resolver Can Verify the Origin of a DNS AnswerHow-to
A plain DNS answer is whatever arrived first on UDP port 53. DNSSEC attaches a signature to each record set so a resolver can check that the zone's key holder published it and that nothing changed it on the way.
- Certificate Transparency: A Public Provenance Log for TLSGuide
Every publicly trusted TLS certificate is now written to append-only public logs before a browser will accept it. Certificate Transparency turns issuance from a private act between a CA and a requester into a record anyone can audit.
- Subresource Integrity: Verify the Origin of Every ScriptHow-to
A script tag names a URL, and a URL is a promise about location, not content. Subresource integrity adds a digest to the tag so the browser can refuse any bytes that differ from what the page author hashed.
- SHA-256 Checksums and Signed Firmware: Verify the SourceHow-to
A matching SHA-256 digest proves that the file on your disk is the file the publisher hashed. It does not prove who the publisher was. Firmware for switches and routers needs both answers before it goes to flash.
- Code Signing: Provenance of the Firmware and Configs You RunGuide
A firmware image or a configuration bundle arrives as bytes with a name attached. Code signing ties those bytes to a named publisher and shows that nothing changed after the publisher let go of them.
- NTP Server Time as Provenance: Timestamps You Can DefendHow-to
Every log line, flow record and capture carries a time that some clock wrote. If that clock had no verified source, the timestamp is an opinion. An NTP server hierarchy, authenticated where it matters, turns it into a defensible fact.
- WARC Files: Archiving Web Pages as Evidence With ProvenanceHow-to
A screenshot shows what a browser drew. A WARC file records what a server actually sent, byte for byte, with the request that provoked it and a digest over the payload. That difference is what makes it evidence.
- DMARC, SPF and DKIM: Verify the Origin of Email at the EdgeHow-to
SPF, DKIM and DMARC are three DNS-published records that let a receiving mail gateway decide whether a message really left the domain named in its From header. Together they form a provenance system for mail, with precise limits on what they prove.
- 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.