Hvad tunnelen krypterer, og hvad den lader læsbart

Din tunnel er oppe, én fane viser en grøn hængelås, og en almindelig HTTP-side i en anden fane advarer stadig om, at forbindelsen ikke er sikker. Den kombination forvirrer folk, fordi de to beskyttelser dækker forskellige afstande. En VPN beskytter trafik mellem sine egne endepunkter, og ud over udgangen er trafikken almindelig igen. HTTPS beskytter én forbindelse hele vejen til webstedet. Stiller man de to kendsgerninger op side om side, forklarer det de fleste spørgsmål om, hvad en VPN egentlig skjuler.

Hvad tunnelen faktisk dækker

Mellem klienten og VPN-peeret ser en observatør krypterede bytes i stedet for en læsbar anmodning. Det dækker det segment, tunnelen krydser, og det er normalt den del, du ikke kontrollerer. Det strækker sig ikke til forbindelsen mellem VPN-udgangen og webstedet, fordi tunnelen sluttede ved udgangen. Byterne er læsbare igen fra det øjeblik, tunnelen afsluttes. Intet ved det er en fejlkonfiguration.

Udgangen er en maskine, der dekrypterer og videresender, og det er netop, hvad en VPN er til. Alt, hvad den videresender, er synligt for den i den form, den modtog det, så en almindelig HTTP-anmodning forbliver klartekst fra udgangen og frem.

Læs det som en egenskab snarere end en fejl. Kryptering er afgrænset til en sti, og stien ender, hvor tjenesten begynder.

Nøgler, nonces og integritet i klart sprog

Løbende trafik beskyttes med symmetrisk kryptografi, og begge ender udleder eller skaffer nøglematerialet under håndtrykket. Autentificeret kryptering, beskrevet i generelle vendinger af RFC 5116, giver fortrolighed og integritet i én konstruktion. Modtageren afviser ændrede bytes i stedet for blot at undlade at kunne læse dem, og det er den del, folk glemmer, når de tror, at kryptering betyder at blande sammen.

Nøgler kommer fra den udveksling, ikke fra adgangskoden, der tastes ved login. Adgangskoden autentificerer en identitet, og protokollen etablerer derefter sessionsmateriale. Ephemeral nøgleudveksling er det, der giver forward secrecy, så en optaget session forbliver ulæselig, selv om en langsigtet nøgle senere lækkes.

Et stort tal i en specifikation besvarer ingen af de spørgsmål, og at sammenligne tal på tværs af ubeslægtede algoritmer er ikke en rangliste. Spørg i stedet, hvad nøgleudvekslingen giver.

Hvor tunnelen ender

Det endepunkt, der afslutter tunnelen, kan læse det, den videresender. Det gælder en virksomhedsgateway, en kommerciel udbyder og en selvhostet server på samme måde. Det er designet, ikke en mangel i det. Stærk kryptografi kan ikke forhindre et kompromitteret endepunkt i at læse klartekst, der ankommer til det, fordi endepunktet er, hvor beskyttelsen stopper.

HTTPS fortsætter forbi det punkt, og derfor kan et websted være sikkert på et fjendtligt netværk, selv uden en VPN. De to beskyttelser overlapper på det første segment, og kun én af dem fortsætter efter udgangen.

Det er også grunden til, at svækkelse af certifikatverifikation for at få en forbindelse til at virke ikke er en test af tunnelen. Det deaktiverer en anden beskyttelse og efterlader dig med mindre, end du startede med.

Hvorfor anonymitet er et andet produkt

Adresser, timing og mængde forbliver observerbare uden for tunnelen. En observatør kan se, at trafik flyder til et VPN-endepunkt, nogenlunde hvor meget og hvornår. Indholdet kan være ulæseligt, mens mønsteret stadig er informativt.

Udbyderen sidder også et andet sted end dit eget netværk, hvilket er en ændring af observatør snarere end en fjernelse af observation. Cookies, logins og kontoidentifikatorer fungerer præcis som før, fordi tunnelen aldrig lovede at ændre dem.

Vælg en udbyder ud fra dens logningspolitik og jurisdiktion, hvis det er kravet, og læs så politikken selv. Markedsføringssider besvarer sjældent det spørgsmål på en måde, nogen kan revidere.

Kontroller tunnelen og webstedet hver for sig

Kontroller først tunnelen, så du ved, hvilken beskyttelse du tester. Kontroller derefter webstedets egen transport, og sammenlign de to resultater i stedet for at antage, at det ene medfører det andet. En tunnel, der bærer almindelig HTTP, og et websted, der leverer HTTPS, gør begge præcis det, de blev konfigureret til.

Kør kontrollerne mod en vært, du har tilladelse til at teste, og læs outputtet frem for resuméet.

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

Når tunnelen er oppe, og webstedet er HTTPS, har du to beskyttelser på det første segment og én på det andet. Når webstedet er almindelig HTTP, er det andet segment læsbart for alle derpå, inklusive den udgang, der videresendte anmodningen. At vide, hvilken af de to der mangler, er hele diagnosen, og det kræver to kommandoer i stedet for en ny klient.