What the Tunnel Encrypts, and What It Leaves Readable

Your tunnel is up, one tab shows a green padlock, and a plain HTTP page in another tab still warns that the connection is not secure. That combination confuses people because the two protections cover different distances. A VPN protects traffic between its own endpoints, and beyond the exit the traffic is ordinary again. HTTPS protects one connection all the way to the website. Lining those two facts up explains most of the questions about what a VPN actually hides.

What the tunnel actually covers

Between the client and the VPN peer, an observer sees encrypted bytes rather than a readable request. That covers the segment the tunnel crosses, which is usually the part you do not control. It does not extend to the link between the VPN exit and the website, because the tunnel ended at the exit. The bytes are readable again from the moment the tunnel terminates. Nothing about that is a misconfiguration.

The exit is a machine that decrypts and forwards, which is exactly what a VPN is for. Anything it forwards is visible to it in the form it received, so a plain HTTP request stays plaintext from the exit onward.

Read that as a property rather than a flaw. Encryption is scoped to a path, and the path ends where the service begins.

Keys, nonces and integrity in plain terms

Ongoing traffic is protected with symmetric cryptography, and both ends derive or obtain the key material during the handshake. Authenticated encryption, described in general terms by RFC 5116, gives confidentiality and integrity in one construction. The receiver rejects modified bytes rather than merely failing to read them, which is the part people forget when they think encryption means scrambling.

Keys come from that exchange, not from the password typed at login. The password authenticates an identity, and the protocol then establishes session material. Ephemeral key exchange is what gives forward secrecy, so a recorded session stays unreadable even if a long-term key leaks later.

A large number in a specification answers none of those questions, and comparing numbers across unrelated algorithms is not a ranking. Ask what the key exchange provides instead.

Where the tunnel ends

The endpoint that terminates the tunnel can read what it forwards. That is true of a corporate gateway, a commercial provider and a self-hosted server alike. It is the design, not a defect in it. Strong cryptography cannot stop a compromised endpoint from reading plaintext that arrives at it, because the endpoint is where the protection stops.

HTTPS continues past that point, which is why a site can be safe on a hostile network even without a VPN. The two protections overlap on the first segment and only one of them continues after the exit.

That is also why weakening certificate verification to make a connection work is not a test of the tunnel. It disables a different protection and leaves you with less than you started with.

Why anonymity is a different product

Addresses, timing and volume remain observable outside the tunnel. An observer can see that traffic is flowing to a VPN endpoint, roughly how much, and when. Content may be unreadable while the pattern is still informative.

The provider also sits somewhere different from your own network, which is a change of observer rather than a removal of observation. Cookies, logins and account identifiers keep working exactly as before, because the tunnel never promised to alter them.

Choose a provider by its logging policy and jurisdiction if that is the requirement, then read the policy itself. Marketing pages rarely answer that question in a way anyone can audit.

Check the tunnel and the site separately

Verify the tunnel first, so you know which protection you are testing. Then verify the site's own transport, and compare the two results instead of assuming that one implies the other. A tunnel that carries plain HTTP and a site that serves HTTPS are both doing exactly what they were configured to do.

Run the checks against a host you are allowed to test, and read the output rather than the summary.

wg show
ip -brief addr show tun0
curl -sS -o /dev/null -w '%{http_code} %{url_effective}\n' https://example.com

When the tunnel is up and the site is HTTPS, you have two protections on the first segment and one on the second. When the site is plain HTTP, the second segment is readable by anyone on it, including the exit that forwarded the request. Knowing which of the two is missing is the whole diagnosis, and it takes two commands rather than a new client.