Don't take our word for it

The code that decrypts your traffic and decides what happens to it is open source. Read it. Run it. Check that it does what this site says.

Why this claim is worth anything here

Plenty of vendors have an open-source component and call it transparency. It usually means little, because the open part is a client library or an integration while the part you actually have to trust stays closed.

The boundary here was drawn on exactly that question — whether a component touches customer traffic. The enforcement path is published: TLS interception, policy evaluation, default-deny, east-west authorisation, DNS control, mTLS device admission. The part you would have to take on trust is the part that is published.

For software whose entire function is to undo encryption on purpose, that is the most useful thing that can be said about it.

Two legs, not one

Read it

The enforcement path ships as importable Go packages, not as a dump. Alongside the code:

• The threat model — what is defended, what is assumed, and explicitly what is excluded
• The defaults — every one of them, framed as the compatibility versus security trade it actually makes
• Certificate pinning — pinned hosts are proposed for bypass and never auto-bypassed; the operator decides

Publishing the exclusions is part of the argument rather than a caveat to bury. A security product that will not say what it does not defend against has not finished thinking about it.

Run it

The verification guide walks through observing the data plane yourself: committed tests that need no setup, then provisioning certificates, running the edge, and watching decrypt-all happen through the real tunnel with a real client. The invitation is not to admire the source; it is to reproduce the behaviour this site claims.

That guide is also written to say what each check does not cover. OS-level flow capture from a real browser needs an activated system extension, so it says so instead of implying coverage. Treat any capability not backed by something you can run yourself as unproven.

The honest gap: reading is not running

If you take a build from someone else, you are trusting that the binary matches the published source. Nothing here proves that yet — there are no reproducible builds and no source-to-binary attestation. It is on the list on the status page.

We would rather volunteer that than have it raised as a gotcha, because it is precisely the objection a serious reviewer makes, and answering it unprompted is the only thing that makes the rest of this page worth reading.

One risk taken deliberately

Publishing the enforcement core means an attacker can read it too. The standard answer holds: security that depends on the enforcement logic being secret is not security, and a component that undoes encryption earns trust by being readable rather than by being hidden.

The repository opens on 2026-09-01 at github.com/lantern-networks/dsse-core, as an Experimental release.