Vad tunneln krypterar och vad den lämnar läsbart

Din tunnel är uppe, en flik visar ett grönt hänglås, och en vanlig HTTP-sida i en annan flik varnar fortfarande för att anslutningen inte är säker. Den kombinationen förvirrar folk eftersom de två skydden täcker olika sträckor. En VPN skyddar trafik mellan sina egna ändpunkter, och bortom utgången är trafiken återigen vanlig. HTTPS skyddar en anslutning ända fram till webbplatsen. Ställer man de två fakta sida vid sida förklarar det de flesta frågor om vad en VPN egentligen döljer.

Vad tunneln faktiskt täcker

Mellan klienten och VPN-motparten ser en observatör krypterade byte i stället för en läsbar begäran. Det täcker det segment som tunneln korsar, och det är vanligtvis den del du inte kontrollerar. Det sträcker sig inte till länken mellan VPN-utgången och webbplatsen, eftersom tunneln slutade vid utgången. Byten är läsbara igen från det ögonblick tunneln avslutas. Inget av detta är en felkonfiguration.

Utgången är en maskin som dekrypterar och vidarebefordrar, och det är precis vad en VPN är till för. Allt den vidarebefordrar är synligt för den i den form den tog emot det, så en vanlig HTTP-begäran förblir klartext från utgången och framåt.

Läs det som en egenskap och inte som en brist. Kryptering är begränsad till en väg, och vägen slutar där tjänsten börjar.

Nycklar, nonce och integritet i klarspråk

Pågående trafik skyddas med symmetrisk kryptografi, och båda sidor härleder eller hämtar nyckelmaterialet under handskakningen. Autentiserad kryptering, beskriven i allmänna ordalag av RFC 5116, ger konfidentialitet och integritet i en enda konstruktion. Mottagaren avvisar ändrade byte i stället för att bara inte kunna läsa dem, och det är den del folk glömmer när de tror att kryptering betyder att blanda ihop.

Nycklarna kommer från det utbytet, inte från lösenordet som skrivs vid inloggning. Lösenordet autentiserar en identitet, och därefter etablerar protokollet sessionsmaterial. Ephemeral nyckelutbyte är det som ger forward secrecy, så en inspelad session förblir oläsbar även om en långsiktig nyckel läcker senare.

En stor siffra i en specifikation besvarar ingen av dessa frågor, och att jämföra siffror mellan orelaterade algoritmer är ingen rangordning. Fråga i stället vad nyckelutbytet ger.

Var tunneln slutar

Den ändpunkt som avslutar tunneln kan läsa det den vidarebefordrar. Det gäller en företagsgateway, en kommersiell leverantör och en självhostad server på samma sätt. Det är designen, inte en brist i den. Stark kryptografi kan inte hindra en komprometterad ändpunkt från att läsa klartext som anländer dit, eftersom ändpunkten är där skyddet slutar.

HTTPS fortsätter förbi den punkten, och därför kan en webbplats vara säker i ett fientligt nätverk även utan VPN. De två skydden överlappar på det första segmentet och bara ett av dem fortsätter efter utgången.

Det är också därför försvagning av certifikatverifieringen för att få en anslutning att fungera inte är ett test av tunneln. Det stänger av ett annat skydd och lämnar dig med mindre än du började med.

Varför anonymitet är en annan produkt

Adresser, timing och volym förblir observerbara utanför tunneln. En observatör kan se att trafik flödar till en VPN-ändpunkt, ungefär hur mycket och när. Innehållet kan vara oläsbart medan mönstret fortfarande är informativt.

Leverantören sitter också någon annanstans än ditt eget nät, vilket är ett byte av observatör och inte ett avlägsnande av observation. Cookies, inloggningar och kontoidentifierare fungerar precis som förut, eftersom tunneln aldrig lovade att ändra dem.

Välj en leverantör utifrån dess loggningspolicy och jurisdiktion om det är kravet, och läs sedan policyn själv. Marknadsföringssidor svarar sällan på den frågan på ett sätt som någon kan granska.

Kontrollera tunneln och webbplatsen var för sig

Verifiera tunneln först, så att du vet vilket skydd du testar. Verifiera sedan webbplatsens egen transport och jämför de två resultaten i stället för att anta att det ena innebär det andra. En tunnel som bär vanlig HTTP och en webbplats som levererar HTTPS gör båda exakt det de konfigurerades för.

Kör kontrollerna mot en värd du har tillstånd att testa, och läs utdata i stället för sammanfattningen.

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

När tunneln är uppe och webbplatsen är HTTPS har du två skydd på det första segmentet och ett på det andra. När webbplatsen är vanlig HTTP är det andra segmentet läsbart för alla som är där, inklusive utgången som vidarebefordrade begäran. Att veta vilket av de två som saknas är hela diagnosen, och det kräver två kommandon i stället för en ny klient.