Ce mai vede rețeaua locală prin VPN-ul tău

Trei observatori se contopesc într-o singură întrebare de fiecare dată când cineva întreabă dacă un VPN îi ascunde traficul: rețeaua la care este conectat, mașina din mâinile lui și operatorul tunelului. Fiecare află altceva, iar tunelul schimbă fiecare dintre aceste vederi într-un mod diferit. Ajută să lucrezi în direcția opusă și să pornești de la afirmația care se face, pentru că afirmația este cea care trebuie să reziste verificării. Decide de ce afirmație ai nevoie, apoi compară instrumentele cu ea.

Prima afirmație: nimeni nu poate citi traficul

Începe cu cea mai îngustă afirmație: încărcătura rămâne ilizibilă. Un observator pasiv pe traseu nu poate vedea în interiorul unei sesiuni TLS, așa că tunelul adaugă puțin unui site care folosește deja HTTPS și nu adaugă nimic împotriva celor două capete. Partea care sparge această afirmație este cine controlează dispozitivul, pentru că un proxy de inspecție încheie conexiunea și o semnează din nou cu o rădăcină în care mașina are deja încredere. De aceea lacătul apare în continuare în timp ce lanțul de certificate poartă numele organizației care a instalat rădăcina.

security find-certificate -a -p /Library/Keychains/System.keychain | openssl crl2pkcs7 -nocrl -certfile /dev/stdin | openssl pkcs7 -noout -print_certs | grep subject
certutil -store Root

Pe macOS acel lanț de comenzi tipărește o linie de subiect pentru fiecare certificat din brelocul mașinii, fără a deschide o fereastră, iar pe Windows certutil -store Root listează același depozit pe care certlm.msc îl arată grafic. O rădăcină care aparține unei școli, unui angajator sau unui produs de securitate a rețelei este înregistrarea pe care trebuie să o cauți. Găsirea uneia dovedește doar că interceptarea este posibilă, nu că se întâmplă.

Ce poți face în privința asta este o chestiune de politică, nu de tehnică. Scoaterea unui profil sau a unei rădăcini de inspecție de pe un hardware care nu este al tău încalcă de obicei acordul de utilizare acceptabilă, iar sistemul de administrare tinde să observe și să îl aplice din nou, așa că cerința ca proprietarul dispozitivului să nu îți citească traficul are nevoie de alt dispozitiv, nu de altă setare.

A doua afirmație: nimeni nu vede unde te duci

Destinația este afirmația mai dificilă, pentru că două dezvăluiri au loc înainte de încărcarea unei pagini. Interogarea merge la resolverul pe care sistemul este configurat să îl folosească, iar răspunsul este vizibil pentru rețeaua care îl transportă. Apoi strângerea de mână TLS transportă numele serverului cerut în clar, dacă Encrypted Client Hello nu este acceptat la ambele capete. Niciuna dintre dezvăluiri nu implică decriptare, așa că tunelul nu are efect asupra niciuneia.

resolvectl status | grep -A2 "Link"
nslookup example.com

Care resolver este folosit de fapt decide expunerea, iar asta se poate măsura în loc să se discute. Pe Linux resolvectl status tipărește serverele DNS pentru fiecare legătură, iar ieșirea lui îți spune dacă răspunde resolverul site-ului sau cel impus. Windows răspunde la aceeași întrebare cu nslookup example.com, al cărui prim bloc de ieșire este serverul DNS care a răspuns.

Când laptopul întreabă resolverul site-ului înainte ca tunelul să urce, sau profilul ajunge fără un server de înlocuire așa încât cel vechi rămâne în uz, administratorul colectează în continuare nume de gazdă fără să decripteze nimic. DNS-ul criptat din browser fie ocolește resolverul impus, fie este blocat complet și eșuează închis. Operatorul de ieșire vede aceleași nume din partea lui. Schimbarea resolverului nu mută deci acea dezvăluire departe de furnizorul tunelului.

A treia afirmație: nimeni nu știe că te-ai conectat

A treia afirmație este cea pe care un tunel nu o poate susține, pentru că pachetele traversează în continuare rețeaua locală. Acea rețea află adresa punctului final, volumul aproximativ, momentul și existența unei singure sesiuni criptate de lungă durată, ceea ce este suficient pentru a bloca, a limita sau pur și simplu a observa. Un firewall care nu poate citi un pachet poate totuși refuza să îl lase să treacă. A fi observat nu este același lucru cu a nu fi observat de nimeni: ai mutat observatorul, nu l-ai șters.

Tunelarea divizată, și orice aplicație care ignoră ruta impusă, produc fluxuri în afara tunelului care arată exact ca înainte. Acelea sunt fluxurile pe care un observator atent le remarcă primele, iar tabelul de rute al clientului arată ce destinații sunt excluse.

Operatorul de la celălalt capăt deține imaginea în oglindă a acelei vederi: adresa de ieșire, momentul, volumul și de obicei numele site-urilor. Furnizorul tău devine partea cu punctul de observație, ceea ce este o înțelegere diferită de invizibilitate. Să alegi un furnizor în care ai încredere este o decizie reală; să numești rezultatul neobservat nu este.

Decide de ce afirmație ai nevoie

Scrie cerința într-o singură linie înainte de a atinge un client: ascunde conținutul, ascunde destinațiile sau ascunde dacă te-ai conectat măcar. Conținutul este deja gestionat de HTTPS împreună cu tunelul, în timp ce destinațiile au nevoie de un resolver și de o cale care ocolesc complet echipamentul site-ului.

A treia cerință este cea incomodă, pentru că ceva este încă vizibil conectat undeva, criptat sau nu. Nicio setare a clientului nu schimbă asta. Dacă cerința și politica se despart, acel decalaj aparține unei conversații cu cel care deține politica, nu unei opțiuni din client. Persoana care poate răspunde este cea care a scris politica.