What a VPN Protocol Spec Does and Does Not Prove

A protocol document is a contract between implementations, and reading it carefully tells you what two conforming peers will exchange and which properties the designers intended to hold. It does not tell you which binary is running on the server you connect to, how that server was configured or what happens to your account record afterwards. Those are three different kinds of evidence, and treating the specification as all three is how a protocol name starts doing work it cannot do. Keeping the three apart is the whole exercise.

The document is the beginning of an argument, not its conclusion.

What the Document Actually Specifies

For WireGuard, the protocol description defines a Noise IK handshake, a fixed set of primitives, message layouts and the transport framing that carries packets afterwards. For IKEv2 the comparable artefact is RFC 7296, which specifies exchanges, payloads and the negotiation of proposals. In both cases the scope is precise: the messages, the state machine and the assumptions under which the security goals hold.

Optional modes complicate the reading. A property that holds for one handshake may not apply to a deployment using a different authentication arrangement or a fallback configuration.

Where the Guarantees Stop

A formal analysis answers a question about a model. WireGuard's verification work uses a symbolic model in the Tamarin prover, which can show that the design resists certain attacks given its assumptions; it does not show that a shipped userspace implementation has no memory-safety bug. That gap between model and machine is where real incidents live. Reading a proof as an implementation certificate is a category error.

Forward secrecy illustrates the same boundary. The property depends on keys being destroyed as the protocol intends, which is a property of the implementation and its environment rather than of the message format. A design that specifies erasure cannot enforce it on a platform that pages memory to disk.

Layered dependencies widen the gap further: the TLS library behind a TLS-based tunnel, the kernel interface a userspace tunnel uses, and the random number generator all sit outside the protocol text.

Follow the Bytes Into the Build

Move from document to artefacts by identifying versions, then comparing them with what actually serves traffic. A product that names a protocol may add provisioning, telemetry and management components that the specification never describes.

openvpn --version | head -3
wg --version
dpkg -l | grep -E 'openvpn|wireguard|libssl'
ss -lunp | grep -E '1194|51820'
sha256sum ./wireguard-tools_1.0.20210914_amd64.deb

Reproducible builds and published checksums make it possible to connect a source tree to a distributed binary. Without that link, published source proves only that inspection is possible, not that the running file matches it.

Configuration belongs in the same step. Cipher suites, allowed peers and routing settings are deployment choices, and a conforming build configured carelessly still produces a weak tunnel.

Keep Operating Practices Separate

Account records, payment data and support submissions are operator decisions that no protocol text constrains. An audit report covers named components against a stated scope, and a privacy policy describes intentions and practices; neither substitutes for the other, and neither is a cryptographic statement.

The precise conclusion is cumulative: the specification explains the design, the build and configuration explain the tunnel, and the operator's documented practices explain everything the tunnel never sees. Say which of those you verified, and the claim stays true.