VPN og Tor erstatter ikke HTTPS: hvor hvert lag slutter
En tunnel slutter hos sin egen peer, og et Tor-kredsløb slutter ved et exit-relæ. HTTPS er det eneste lag, der når webstedet, så en almindelig formular forbliver læsbar.
En VPN og et Tor-kredsløb krypterer begge din trafik i en del af rejsen. Begge holder op med at kryptere den hos en peer, de selv vælger. HTTPS er det lag, der når selve webstedet, og ingen mængde tunellering foran det gør en almindelig formularindsendelse til en beskyttet. At følge hvert lag til det punkt, hvor det slutter, gør det indlysende.
Tre lag, tre forskellige endepunkter
En konventionel VPN afslutter sin tunnel på VPN-serveren. Alt mellem din enhed og den server er inde i tunnelen, og alt efter den er ikke. Et Tor-kredsløb opfører sig på samme måde med en anden peer og forlader netværket ved et exit-relæ, der videresender din anmodning til destinationen.
TLS afsluttes på webstedet. Det certifikat, du validerede, binder et værtsnavn til en nøgle, som webstedet kontrollerer, og sessionsnøglerne findes mellem din browser og den server. Det endepunkt ligger ud over både VPN-serveren og Tor-udgangen.
Så de tre lag har tre forskellige tillidsgrænser, og en anmodning passerer alle tre i rækkefølge. At styrke ét siger intet om de andre, og det sidste er det eneste, som destinationen deltager i.
Hvad det sidste hop afslører
Hvis applikationen bruger almindelig HTTP, er indholdet efter udgangen læsbart for enhver, der driver det hop. Den tidligere tunnel gjorde sit arbejde perfekt og er simpelthen ikke der længere. Legitimationsoplysninger, der tastes i en HTTP-formular, afsløres præcis på det punkt, hvor beskyttelsen sluttede.
| Layer | Terminates at | Who can read the request there |
|---|---|---|
| VPN tunnel | The VPN server you selected | The operator of that server, and anyone who can compel them |
| Tor circuit | An exit relay chosen by the network | The exit relay operator, for traffic that is not otherwise protected |
| HTTPS | The website's own TLS endpoint | The site itself, and no intermediary on the path |
Med korrekt valideret HTTPS kan en mellemmand på vejen ikke læse eller lydløst ændre applikationsindholdet. Den ser stadig, at du oprettede forbindelse, hvornår og til hvilken adresse, fordi pakkehovederne skal kunne routes. Fortrolighed af indhold og metadata om forbindelsen er forskellige egenskaber, og kun den første er hvad TLS giver.
Kontoidentitet er igen en tredje ting. At logge ind på en konto identificerer dig over for den tjeneste uanset hvilken udgangsadresse du brugte, så udgangen beskytter netværksstien snarere end kontoen. Den forskel overlever et vilkårligt antal lag foran den. At skifte udgange ændrer aldrig, hvad en logget-ind session afslører. Tjenesten vidste, hvem du var, før den første pakke forlod dig.
Intet i denne ordning brydes ved at tilføje en anden tunnel. Det, der ændres, er hvilken observatør der ser det første hop, ikke om det sidste hop er krypteret.
Rækkefølgen ændrer observatørerne, ikke endepunktet
At kæde en VPN og Tor er en legitim måde at ændre, hvem der ser hvad på netværksniveau. At køre Tor over en VPN skjuler over for dit adgangsnetværk, at du bruger Tor, mens at køre en VPN over Tor skjuler din adresse for VPN-udbyderen. Begge rækkefølger er beskrevet i offentlig dokumentation, og begge har afvejninger i ydeevne og fejladfærd.
Ingen af rækkefølgerne flytter TLS-endepunktet. I begge tilfælde validerer browseren stadig et certifikat for det værtsnavn, den anmodede om, og i begge tilfælde sender en HTTP-adresse stadig sit indhold i klartekst efter det sidste relæ. Sammensætningen ændrer observatørlisten; den ændrer ikke antallet af lag ved destinationen.
Det er derfor råd om kædning handler om trusselsmodeller snarere end om sikkerhed generelt. En længere kæde er ikke en stærkere version af det samme, og den er ikke en erstatning for den protokol, applikationen valgte.
curl -sSI https://example.net | head -3
openssl s_client -connect example.net:443 -servername example.net -brief
Begge kommandoer viser det lag, der betyder noget ved destinationen. Den anden udskriver den forhandlede protokol uden at inddrage nogen tunnel. Ingen af dem fortæller dig noget om den udgang, du brugte.
Hold valideringen kørende, mens du fejlfinder
En certifikatadvarsel er information om den forbindelse, du er ved at oprette. Den kan betyde uoverensstemmelse i værtsnavn, et urproblem, en ikke-betroet kæde eller et forsøg på aflytning. At tilføje en permanent undtagelse, fordi en VPN er tilsluttet, fjerner det eneste signal, der ville have skelnet de tilfælde.
Tor Browsers sikre-forbindelse-funktioner og dets advarsler findes af samme grund, og at deaktivere dem for at få en side til at indlæse bytter en synlig fejl for en usynlig. Hvis et websted ikke kan nås uden en undtagelse, er den ærlige konklusion, at forbindelsen ikke kan verificeres, ikke at tunnelen gjorde den sikker.
Kryptering siger heller intet om hensigt. En gyldig HTTPS-forbindelse til et vildledende websted leverer dine data til det websted med perfekt fortrolighed. Kontroller adressen og hvad du indsender, ikke kun om hængelåsen er der.
Onion-tjenester er en virkelig anden model. De nås gennem Tor-netværket uden en almindelig offentlig udgang, hvilket ikke er det samme som at tilgå et offentligt websted gennem Tor. Behandl det som et særskilt tilfælde med egne forventninger snarere end som en stærkere version af det samme besøg.
Reglen, der overlever enhver konfiguration, er kort. Hold browservalideringen intakt. Vurder hvert lag efter, hvor det faktisk slutter.