Wat de tunnel versleutelt en wat leesbaar blijft

Je tunnel staat aan, het ene tabblad toont een groen slot, en een gewone HTTP-pagina in een ander tabblad waarschuwt nog steeds dat de verbinding niet veilig is. Die combinatie verwart mensen omdat de twee beschermingen verschillende afstanden dekken. Een VPN beschermt verkeer tussen zijn eigen eindpunten, en voorbij de uitgang is het verkeer weer gewoon. HTTPS beschermt één verbinding tot aan de website. Als je die twee feiten naast elkaar legt, verklaart dat de meeste vragen over wat een VPN werkelijk verbergt.

Wat de tunnel feitelijk dekt

Tussen de client en de VPN-peer ziet een waarnemer versleutelde bytes in plaats van een leesbaar verzoek. Dat dekt het segment dat de tunnel doorkruist, en dat is meestal het deel dat je niet beheert. Het reikt niet tot de verbinding tussen de VPN-uitgang en de website, omdat de tunnel bij de uitgang eindigde. De bytes zijn weer leesbaar vanaf het moment dat de tunnel eindigt. Niets daaraan is een verkeerde configuratie.

De uitgang is een machine die ontsleutelt en doorstuurt, en daar is een VPN precies voor bedoeld. Alles wat hij doorstuurt is voor hem zichtbaar in de vorm waarin hij het ontving, dus een gewoon HTTP-verzoek blijft vanaf de uitgang platte tekst.

Lees dat als een eigenschap en niet als een gebrek. Versleuteling is beperkt tot een pad, en het pad eindigt waar de dienst begint.

Sleutels, nonces en integriteit in gewone taal

Lopend verkeer wordt beschermd met symmetrische cryptografie, en beide kanten leiden het sleutelmateriaal af of verkrijgen het tijdens de handshake. Geauthenticeerde versleuteling, in algemene termen beschreven door RFC 5116, geeft vertrouwelijkheid en integriteit in één constructie. De ontvanger weigert gewijzigde bytes in plaats van ze alleen niet te kunnen lezen, en dat is het deel dat mensen vergeten wanneer ze denken dat versleuteling betekent dat het door elkaar wordt gehusseld.

De sleutels komen uit die uitwisseling, niet uit het wachtwoord dat bij het inloggen wordt getypt. Het wachtwoord authenticeert een identiteit, en daarna stelt het protocol sessiemateriaal vast. Efemere sleuteluitwisseling is wat voorwaartse geheimhouding geeft, zodat een opgenomen sessie onleesbaar blijft, zelfs als later een langetermijnsleutel uitlekt.

Een groot getal in een specificatie beantwoordt geen van die vragen, en getallen vergelijken tussen onverwante algoritmen is geen ranglijst. Vraag in plaats daarvan wat de sleuteluitwisseling biedt.

Waar de tunnel eindigt

Het eindpunt dat de tunnel beëindigt kan lezen wat het doorstuurt. Dat geldt evenzeer voor een bedrijfsgateway, een commerciële aanbieder en een zelf-gehoste server. Het is het ontwerp, niet een gebrek erin. Sterke cryptografie kan een gecompromitteerd eindpunt er niet van weerhouden platte tekst te lezen die daar aankomt, want het eindpunt is waar de bescherming stopt.

HTTPS gaat voorbij dat punt verder, en daarom kan een site op een vijandig netwerk veilig zijn, zelfs zonder VPN. De twee beschermingen overlappen op het eerste segment en slechts één ervan gaat na de uitgang verder.

Daarom is het verzwakken van certificaatverificatie om een verbinding aan de praat te krijgen geen test van de tunnel. Het schakelt een andere bescherming uit en laat je achter met minder dan waarmee je begon.

Waarom anonimiteit een ander product is

Adressen, timing en volume blijven buiten de tunnel waarneembaar. Een waarnemer kan zien dat verkeer naar een VPN-eindpunt stroomt, ongeveer hoeveel en wanneer. De inhoud kan onleesbaar zijn terwijl het patroon nog informatief is.

De aanbieder zit ook ergens anders dan je eigen netwerk, wat een verandering van waarnemer is en geen verwijdering van waarneming. Cookies, logins en account-ID's werken precies zoals voorheen, omdat de tunnel nooit heeft beloofd ze te veranderen.

Kies een aanbieder op basis van het logbeleid en de jurisdictie als dat de eis is, en lees daarna het beleid zelf. Marketingpagina's beantwoorden die vraag zelden op een manier die iemand kan controleren.

Controleer de tunnel en de site afzonderlijk

Controleer eerst de tunnel, zodat je weet welke bescherming je test. Controleer daarna het eigen transport van de site, en vergelijk de twee resultaten in plaats van aan te nemen dat het ene het andere impliceert. Een tunnel die gewone HTTP vervoert en een site die HTTPS levert, doen beide precies waarvoor ze zijn geconfigureerd.

Voer de controles uit tegen een host die je mag testen, en lees de uitvoer in plaats van de samenvatting.

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

Als de tunnel aan staat en de site HTTPS is, heb je twee beschermingen op het eerste segment en één op het tweede. Als de site gewone HTTP is, is het tweede segment leesbaar voor iedereen daarop, inclusief de uitgang die het verzoek doorstuurde. Weten welke van de twee ontbreekt is de hele diagnose, en dat kost twee opdrachten in plaats van een nieuwe client.