Verify an archived response

TLS authenticates the connection to its participants. Its application records use symmetric authentication keys available to the endpoints. A client controlling its capture environment can construct a false transcript and authenticate it with those keys. Saving network packets, certificates, HAR or WARC files does not by itself eliminate that possibility.

In TLS 1.3, the server’s CertificateVerify signature covers the handshake transcript; later application records use symmetric AEAD protection. The distinction is explicit in the IETF’s TLS 1.3 handshake specification and record protection specification. TLS 1.2 makes the corresponding separation in RFC 5246.

Preservation, timing and source authentication answer different questions. A timestamp is useful evidence about when particular data existed; a hash helps check whether it changed afterward. Neither mechanism examines whether the material was fabricated before it was submitted. See the IETF time-stamping protocol.

TLSNotary adds evidence of remote origin. It does not replace record keeping, context or an assessment of evidentiary weight. This service’s receipt is not a qualified electronic timestamp or a legal notarial act.

MPC lets the browser and verifier perform the TLS operations together without giving the browser unilateral control of the authentication secrets. Zero-knowledge then lets the browser prove that a concealed response matches a cryptographic commitment—a fingerprint locked to those bytes—without revealing the response itself.

A zero-knowledge proof alone would not fix a transcript the client was free to fabricate. Participation in the connection is essential. This plugin uses TLSNotary’s MPC mode, plus a SHA-256 hash commitment; it does not use the separate protocol called “proxy mode.” See why an online verifier is needed and commitment strategies.

No. TLSNotary has a long history, but “the first ever” and “the only solution” are broader claims than these sources establish. For example, the 2017 TLS-N paper describes a different approach: extending TLS to support transferable proofs. TLSNotary’s practical attraction is bringing a separate verifier to existing websites while preserving the user’s privacy.

The capture configuration discloses no request transcript. It hashes the complete received response and reveals only fixed syntax such as HTTP/1.1, spaces and line endings. The response opening stays local. The destination is deliberately visible to the transport proxy; this is not an anonymity service. Cloudflare, which fronts this deployment, can also observe transport metadata. A sensitive value encoded in a hostname is not hidden like a value in the URL path.

TLSNotary supports selective disclosure, but this ArchiveBox receipt binds the whole saved response. Editing or redacting that file afterward makes this receipt fail verification. The plugin currently authenticates a separate main-document request made by the extension, using captured browser request headers. It does not certify all tab traffic, downloaded assets, video content or the rendered screenshot. A JavaScript application’s initial response may not contain the document visible on screen.

See the extension’s disclosure model and this plugin’s capture and server code.

• The whole page: it covers the accompanying response, not every file in an ArchiveBox snapshot or an ArchiveWeb.page WACZ.
• The exact requested URL or account: the signed payload names the server, not the private request path, query, cookies or user identity.
• Truth or authorship: a server can publish false statements, display user-supplied text or be compromised.
• A publication date: the receipt’s time is the verifier’s issuance time, not when the website first published the content or a separately certified time.
• Automatic legal acceptance: admissibility and weight still depend on the applicable rules, context and supporting evidence.

During capture, the upstream TLSNotary verifier checks the protocol and commitment proof. ArchiveBox’s gateway signs a payload containing the authenticated hostname, its issuance time, the response range and the commitment. Later verification checks that signature and opens the commitment using your saved response. It does not replay the interactive proof or independently repeat certificate validation.

This is an ArchiveBox receipt backed by a verifier’s attestation, not a website-issued signature or a standalone TLSNotary presentation. A dishonest operator, a compromised signing key or collusion could produce a false receipt that passes the local check. Running your own verifier gives you operational control, but does not make your self-issued receipts independent evidence to someone who distrusts you. See TLSNotary’s explanation of delegated trust.

Review and obtain verify.mjs from the source repository. Place it alongside the two capture files. With a current Node.js version supporting Web Crypto and DecompressionStream, run the command below from that directory. Replace the placeholder with the base64 SPKI public key you independently trust for the verifier that issued the receipt.

TRUSTED_KEY='INDEPENDENTLY_TRUSTED_BASE64_SPKI_KEY' node --input-type=module <<'JS'
import { readFileSync } from 'node:fs';
import { verifyReceipt } from './verify.mjs';

const receipt = JSON.parse(readFileSync('receipt.json', 'utf8'));
const response = new Uint8Array(readFileSync('response.http'));
const result = await verifyReceipt(receipt, response, process.env.TRUSTED_KEY);
console.log('Verified:', result.server_name);
console.log('Verifier time:', new Date(result.time * 1000).toISOString());
console.log('Authenticated bytes:', response.length);
JS

The check validates an Ed25519 signature over the decoded payload, recomputes SHA-256(response.http bytes || 16-byte blinder), matches the signed byte range and requires a complete successful HTTP response. The blinder is random data that hides the commitment from guessing while the response is private. It is saved locally in the receipt.

A green result on a website controlled by an untrusted party is not independent verification. For contested evidence, review the code and establish the key through a separate trusted channel. Keep the original key when an operator rotates keys; newly published keys do not automatically authenticate older receipts.