Hva tunnelen krypterer, og hva den lar være lesbart

Tunnelen din er oppe, én fane viser en grønn hengelås, og en vanlig HTTP-side i en annen fane advarer fortsatt om at tilkoblingen ikke er sikker. Den kombinasjonen forvirrer folk fordi de to beskyttelsene dekker ulike avstander. En VPN beskytter trafikk mellom sine egne endepunkter, og utenfor utgangen er trafikken vanlig igjen. HTTPS beskytter én tilkobling helt til nettstedet. Setter man de to faktaene side ved side, forklarer det de fleste spørsmålene om hva en VPN egentlig skjuler.

Hva tunnelen faktisk dekker

Mellom klienten og VPN-motparten ser en observatør krypterte byte i stedet for en lesbar forespørsel. Det dekker segmentet tunnelen krysser, og det er vanligvis den delen du ikke kontrollerer. Det strekker seg ikke til forbindelsen mellom VPN-utgangen og nettstedet, fordi tunnelen endte ved utgangen. Bytene er lesbare igjen fra det øyeblikket tunnelen avsluttes. Ingenting av dette er feil konfigurasjon.

Utgangen er en maskin som dekrypterer og videresender, og det er nettopp det en VPN er til for. Alt den videresender er synlig for den i den formen den mottok det, så en vanlig HTTP-forespørsel forblir klartekst fra utgangen og utover.

Les det som en egenskap og ikke som en mangel. Kryptering er begrenset til en sti, og stien slutter der tjenesten begynner.

Nøkler, nonces og integritet i klartekst

Løpende trafikk beskyttes med symmetrisk kryptografi, og begge ender utleder eller skaffer nøkkelmaterialet under håndtrykket. Autentisert kryptering, beskrevet i generelle vendinger av RFC 5116, gir konfidensialitet og integritet i én konstruksjon. Mottakeren avviser endrede byte i stedet for bare å ikke klare å lese dem, og det er den delen folk glemmer når de tror kryptering betyr å blande sammen.

Nøklene kommer fra den utvekslingen, ikke fra passordet som skrives ved pålogging. Passordet autentiserer en identitet, og deretter etablerer protokollen sesjonsmateriale. Ephemeral nøkkelutveksling er det som gir forward secrecy, så en innspilt sesjon forblir uleselig selv om en langsiktig nøkkel lekker senere.

Et stort tall i en spesifikasjon svarer ikke på noen av disse spørsmålene, og å sammenligne tall på tvers av urelaterte algoritmer er ikke en rangering. Spør i stedet hva nøkkelutvekslingen gir.

Hvor tunnelen ender

Endepunktet som avslutter tunnelen kan lese det den videresender. Det gjelder en bedriftsgateway, en kommersiell leverandør og en selvhostet server på samme måte. Det er designet, ikke en mangel i det. Sterk kryptografi kan ikke hindre et kompromittert endepunkt i å lese klartekst som ankommer det, fordi endepunktet er der beskyttelsen stopper.

HTTPS fortsetter forbi det punktet, og derfor kan et nettsted være trygt på et fiendtlig nettverk selv uten VPN. De to beskyttelsene overlapper på det første segmentet, og bare én av dem fortsetter etter utgangen.

Det er også grunnen til at å svekke sertifikatverifiseringen for å få en tilkobling til å virke ikke er en test av tunnelen. Det slår av en annen beskyttelse og lar deg sitte igjen med mindre enn du begynte med.

Hvorfor anonymitet er et annet produkt

Adresser, timing og volum forblir observerbare utenfor tunnelen. En observatør kan se at trafikk flyter til et VPN-endepunkt, omtrent hvor mye og når. Innholdet kan være uleselig mens mønsteret fortsatt er informativt.

Leverandøren sitter også et annet sted enn ditt eget nett, som er en endring av observatør og ikke en fjerning av observasjon. Informasjonskapsler, pålogginger og kontoidentifikatorer fungerer nøyaktig som før, fordi tunnelen aldri lovet å endre dem.

Velg en leverandør ut fra loggføringspolicyen og jurisdiksjonen hvis det er kravet, og les deretter policyen selv. Markedssider svarer sjelden på det spørsmålet på en måte noen kan revidere.

Sjekk tunnelen og nettstedet hver for seg

Verifiser tunnelen først, så du vet hvilken beskyttelse du tester. Verifiser deretter nettstedets egen transport, og sammenlign de to resultatene i stedet for å anta at det ene innebærer det andre. En tunnel som bærer vanlig HTTP, og et nettsted som leverer HTTPS, gjør begge nøyaktig det de ble konfigurert til.

Kjør kontrollene mot en vert du har tillatelse til å teste, og les utdataene i stedet for sammendraget.

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 nettstedet er HTTPS, har du to beskyttelser på det første segmentet og én på det andre. Når nettstedet er vanlig HTTP, er det andre segmentet lesbart for alle som er der, inkludert utgangen som videresendte forespørselen. Å vite hvilken av de to som mangler er hele diagnosen, og det krever to kommandoer i stedet for en ny klient.