How to Verify E2EE in NFLTR

Use this guide to confirm that a tunnel is really running in verified mode at the NFLTR relay, that the verified hostname points at the identity you expect, and that the proof artifacts match the agent fingerprint you trust. It starts with the plain-language version first.

Minimal Verification Story

Think of a verified NFLTR tunnel like a locked truck:

• your app puts the data in the truck and locks it
• NFLTR drives the truck to the visitor
• NFLTR should not be able to open the truck and read what is inside

If you only want the simple version, check these three things:

Why this proof works

1. Fingerprint matching is hard to fake because changing TLS identity means changing the private key. If the relay showed you a different fingerprint, it would be a different certificate identity. A matching fingerprint means the proof artifacts and the agent startup banner are talking about the same identity, not a substituted one.
2. blind_relay: true is the relay's public claim about that same identity. The proof page is not asking you to trust an anonymous statement. It publishes blind_relay: true alongside the exact tls_fingerprint you matched, so the route-mode claim is tied to the same TLS identity you started the tunnel with.
3. What you are verifying is the link between identity and claim. Matching fingerprints means same identity. blind_relay: true means that identity is claiming NFLTR did not read HTTP content for this route.
4. The agent honestly reports its fingerprint. The agent binary (or source code once publication is available) prints the real fingerprint of the TLS certificate it is using. As open-source artifacts roll out, you can audit this behavior and verify reproducible builds match the source.

Why you should trust this

• If the relay claims blind relay but actually read your data, it is making a false public claim under a specific TLS identity that can be logged, audited, and compared over time.
• trust_state: Transparency Verified makes that stronger because it adds historical accountability. Identity alone says who is making the claim right now. Transparency says this identity was logged and the append-only chain verified, which makes silent substitution harder.
• For deeper trust: As the agent open-source rollout lands, you can audit exactly how the certificate fingerprint is printed and used. You can verify the binary matches the source via reproducible builds. This reduces reliance on binary-only trust.
• This is an accountability model, not magic. You are trusting this identity's claim now, while keeping evidence you can audit later.

What is proven

• You have verified that the TLS identity claiming blind_relay: true is the same identity the agent started the tunnel with.
• The relay publicly classifies this route as agent-terminated TLS rather than inspectable HTTP.
• Making that claim under a linked identity creates accountability because false claims can be audited later.

What is not proven

• Metadata handling: Fingerprint verification proves the relay cannot read your payload. It does not verify what metadata (IP, timing, byte counts, hostnames) NFLTR logs or retains. Review NFLTR's privacy policy and retention practices separately.
• Persistent trustworthiness: This verification proves the current identity is linked to the current blind_relay=true claim. It does not guarantee NFLTR will keep this promise in the future or never change the code.
• Requests after tunnel restart: Once the tunnel is restarted, the agent may generate a new certificate with a different fingerprint. If the fingerprint changes, you are verifying a different identity. Re-verify if it matters for your use case.
• End-to-end trustworthiness beyond the relay: This verification proves the relay cannot read your payload at the relay. It does not prove that the user visiting your tunnel cannot be observed by network eavesdroppers, ISPs, or compromised endpoints.

Common confusion

"The fingerprint match means the same identity. Blind relay is what that identity claims."

If the operator breaks that promise later, the identity or the proof state would need to change, and you would have evidence that something changed. However, if the tunnel is restarted, the fingerprint may be different (new certificate), so you would be verifying a different identity than before. Each tunnel session has its own fingerprint-to-claim verification.

What You Are Verifying

Prerequisites

1. The agent is running with --mode verified or --e2ee.
2. The server has a verified base domain configured if you want a stable hostname:
   --e2ee.tls_passthrough.base_domain=secure.example.com
3. Your wildcard DNS already points at the relay.

If the verified hostname is missing or stuck in configure state, use Cloudflare DNS Helper first.

1. Start a Verified Tunnel

# local test service
python3 -m http.server 3000

# verified tunnel
nfltr http 3000 --mode verified --name demo-app --no-share

In the CLI output, confirm all of these are present:

• Tunnel Mode Verified
• E2EE enabled
• Fingerprint ...
• a forwarding URL such as https://nfltr.xyz/browse/demo-app/

2. Check the Dashboard

Open the dashboard and find the agent card.

You want to see:

• the Verified mode badge
• an active E2EE panel
• a Verified E2EE Hostname entry in the Route Catalog
• the verified hostname status set to ready
• a Proof bundle action next to that hostname

You should also expect the opposite of inspectable mode behavior: Traffic Inspector stays empty because the relay cannot inspect plaintext traffic.

3. Open the Public Proof Artifacts

For an agent named demo-app, the three proof endpoints are:

https://your-server.example/proof/demo-app
https://your-server.example/proof/demo-app.json
https://your-server.example/proof/demo-app.zip

The JSON endpoint is the easiest place to verify raw facts. A healthy verified tunnel looks like this:

{
  "agent_id": "demo-app",
  "verified_hostname": "https://demo-app.secure.example.com/",
  "blind_relay": true,
  "trust_state": "Transparency Verified",
  "transparency_logged": true,
  "chain_verified": true,
  "tls_fingerprint": "AA:BB:CC:..."
}

Check these fields:

1. verified_hostname is present and points at the hostname users should visit.
2. blind_relay is true, meaning the NFLTR relay is classifying this route as agent-terminated TLS.
3. transparency_logged is true.
4. chain_verified is true when the full append-only transparency log chain verified.
5. tls_fingerprint matches the fingerprint printed by the agent when it started.

4. Download the Proof Bundle

The proof bundle is the durable audit artifact you can save alongside a deployment, security review, or customer handoff.

It contains:

• README.txt
• proof.json
• transparency-history.json when transparency entries exist

If you need to prove what identity was live at a specific point in time, the ZIP is the easiest artifact to keep.

5. Understand the Trust States

In practice, the dashboard often shows Transparency Logged, while the public proof page or JSON can upgrade that result to Transparency Verified after a full chain check.

6. What Fingerprint Matching Actually Proves

Fingerprint matching is an identity check, not a complete proof about every hop on the network path.

7. Optional Advanced Check: Verify the Agent Source Code

If you want the strongest possible verification, you can audit the agent source code and build from source instead of using a binary.

Why this matters: The verification flow relies on the agent honestly reporting its TLS certificate fingerprint. During open-source rollout, you can:

• Audit the agent code to confirm it prints the real fingerprint of the certificate it uses
• Verify the certificate used for reporting is the same certificate used for the user-facing TLS connection
• Build the agent yourself from source and verify reproducible builds match the official binary

Steps:

1. Clone the agent repository (URL to be added when agent is open-sourced)
2. Review cmd/nfltr/main.go and related certificate handling code
3. Build from source:

   go build -o nfltr ./cmd/nfltr

4. Run your own build and compare the fingerprint output to the official proof page
5. Verify reproducible builds: Compare binary hash to official release builds

This removes the need to trust a closed-source binary — you can verify the behavior directly from the code.

8. Optional Advanced Check: Compare the Certificate Directly

Only do this when the verified hostname exposes the agent's certificate directly. If a CDN or reverse proxy terminates TLS in front of the relay, use the proof JSON and proof bundle as your trust anchor instead.

openssl s_client \
  -connect demo-app.secure.example.com:443 \
  -servername demo-app.secure.example.com </dev/null 2>/dev/null \
  | openssl x509 -noout -fingerprint -sha256

Compare the printed fingerprint to tls_fingerprint in the proof JSON.

9. Troubleshooting

Quick Checklist

1. Start the tunnel with --mode verified.
2. Save the fingerprint shown in the CLI banner.
3. Confirm the dashboard shows Verified mode.
4. Open /proof/<agent>.json and verify blind_relay = true and that the fingerprint matches the CLI output.
5. If you want the stronger check, confirm the Route Catalog shows Verified E2EE Hostname in ready state and the proof JSON reports a good trust state.
6. Download the proof bundle if you need a durable audit artifact.

Success Checklist

• You can explain in one sentence why the fingerprint match matters: same identity means the same party is accountable for the claim.
• You can explain why Transparency Verified is stronger than identity alone: it adds append-only historical evidence on top of the current identity match.
• You understand the trade-off: you are trusting this identity's claim now, but you can audit that claim later through the proof bundle and transparency history.
• (For maximum verification confidence) You have audited the agent source code or built the agent from source to confirm it honestly reports its TLS certificate fingerprint.

Related reading:

• Cloudflare DNS Helper
• End-to-End Encryption
• E2EE Whitepaper