VPN og Tor erstatter ikke HTTPS: hvor hvert lag slutter

En VPN og en Tor-krets krypterer begge trafikken din for en del av reisen. Begge slutter å kryptere den hos en motpart de velger selv. HTTPS er laget som når selve nettstedet, og ingen mengde tunellering foran det gjør en vanlig skjemainnsending om til en beskyttet. Å følge hvert lag til punktet der det slutter gjør det åpenbart.

Tre lag, tre forskjellige endepunkter

En vanlig VPN avslutter tunnelen sin på VPN-serveren. Alt mellom enheten din og den serveren er inne i tunnelen, og alt etter den er ikke. En Tor-krets oppfører seg på samme måte med en annen motpart, og forlater nettverket ved et utgangsrelé som videresender forespørselen din til målet.

TLS avsluttes på nettstedet. Sertifikatet du validerte binder et vertsnavn til en nøkkel nettstedet kontrollerer, og sesjonsnøklene finnes mellom nettleseren din og den serveren. Det endepunktet ligger utenfor både VPN-serveren og Tor-utgangen.

Så de tre lagene har tre forskjellige tillitsgrenser, og en forespørsel går gjennom alle i rekkefølge. Å styrke ett sier ingenting om de andre, og det siste er det eneste målet deltar i.

Hva det siste hoppet avdekker

Hvis applikasjonen bruker vanlig HTTP, er innholdet bortenfor utgangen lesbart for enhver som driver det hoppet. Den tidligere tunnelen gjorde jobben sin perfekt og er rett og slett ikke der lenger. Påloggingsdetaljer som tastes inn i et HTTP-skjema, eksponeres nøyaktig på det punktet der beskyttelsen tok slutt.

Med korrekt validert HTTPS kan en mellommann på veien verken lese eller stille endre applikasjonsinnholdet. Den ser fortsatt at du koblet til, når og til hvilken adresse, fordi pakkehodene må kunne rutes. Konfidensialitet for innhold og metadata om forbindelsen er forskjellige egenskaper, og bare den første er det TLS gir.

Kontoidentitet er igjen en tredje ting. Å logge på en konto identifiserer deg for den tjenesten uansett hvilken utgangsadresse du brukte, så utgangen beskytter nettverksveien og ikke kontoen. Den forskjellen overlever et vilkårlig antall lag foran. Å bytte utgang endrer aldri hva en innlogget økt avdekker. Tjenesten visste hvem du var før den første pakken dro.

Ingenting i denne ordningen brytes ved å legge til en andre tunnel. Det som endres er hvilken observatør som ser det første hoppet, ikke om det siste hoppet er kryptert.

Rekkefølgen endrer observatørene, ikke endepunktet

Å kjede en VPN og Tor sammen er en legitim måte å endre hvem som ser hva på nettverksnivå. Å kjøre Tor over en VPN skjuler for tilgangsnettverket ditt at du bruker Tor, mens å kjøre en VPN over Tor skjuler adressen din for VPN-leverandøren. Begge rekkefølgene er beskrevet i offentlig dokumentasjon, og begge har avveininger i ytelse og feilatferd.

Ingen av rekkefølgene flytter TLS-endepunktet. I begge tilfeller validerer nettleseren fortsatt et sertifikat for vertsnavnet den ba om, og i begge tilfeller sender en HTTP-adresse fortsatt innholdet sitt i klartekst bortenfor det siste reléet. Sammensetningen endrer observatørlisten; den endrer ikke antall lag ved målet.

Derfor handler råd om kjed ing vanligvis om trusselmodeller og ikke om sikkerhet generelt. En lengre kjede er ikke en sterkere versjon av det samme, og den erstatter ikke protokollen applikasjonen valgte.

curl -sSI https://example.net | head -3
openssl s_client -connect example.net:443 -servername example.net -brief

Begge kommandoene viser laget som betyr noe ved målet. Den andre skriver ut den forhandlede protokollen uten å involvere noen tunnel. Ingen av dem forteller deg noe om utgangen du brukte.

Hold valideringen i gang mens du feilsøker

En sertifikatadvarsel er informasjon om forbindelsen du er i ferd med å opprette. Den kan betyde avvik i vertsnavn, et klokkeproblem, en ikke-klarert kjede eller et avlyttingsforsøk. Å legge til et permanent unntak fordi en VPN er tilkoblet, fjerner det eneste signalet som ville ha skilt disse tilfellene.

Tor Browsers funksjoner for sikker tilkobling og advarslene dens finnes av samme grunn, og å slå dem av for å få en side til å laste bytter en synlig feil mot en usynlig. Hvis et nettsted ikke kan nås uten unntak, er den ærlige konklusjonen at forbindelsen ikke kan verifiseres, ikke at tunnelen gjorde den trygg.

Kryptering sier heller ingenting om hensikt. En gyldig HTTPS-forbindelse til et villedende nettsted leverer dataene dine til det nettstedet med perfekt konfidensialitet. Sjekk adressen og hva du sender inn, ikke bare om hengelåsen er der.

Onion-tjenester er en virkelig annen modell. De nås gjennom Tor-nettverket uten en vanlig offentlig utgang, noe som ikke er det samme som å nå et offentlig nettsted gjennom Tor. Behandle det som et eget tilfelle med egne forventninger, ikke som en sterkere versjon av samme besøk.

Regelen som overlever enhver konfigurasjon, er kort. Hold nettleservalideringen intakt. Vurder hvert lag etter hvor det faktisk slutter.