Pajautājiet, ko VPN var redzēt, un atbilde ir atkarīga no tā, kur jūs atrodaties ceļā. Sesijas slānī operatoram ir autentifikācijas notikumi un baitu skaits. Pakešu slānī viņam ir galamērķa adreses un laiks. DNS slānī viņam var būt paši nosaukumi. Katrs slānis atbild uz citu jautājumu, un neviens slēdzis nepārvieto jūs starp tiem.

Nosakiet slāni pirms apgalvojuma

Tas pats savienojums katrā punktā rada citus ierakstus, un apgalvojumam par privātumu ir jēga tikai tad, ja tas nosauc šo punktu. Lasiet tabulu kolonnu pa kolonnai: kas pastāv šajā slānī, ko tur var redzēt operators un ko šie paši ieraksti joprojām nevar pateikt.

LayerVisible thereNot visible there
Session and authenticationAccount, client address, start and stop times, assigned address, byte countsURLs, page content, search terms
Forwarded packetsDestination address and port, sizes, timing, often the TLS server nameHTTP path, headers, response body
DNS resolverQueried names and the client that askedPage content and later requests
TLS-terminating proxyFull request line, headers and bodyNothing, by design

Viena slāņa lasīšana kā visa aina ir gan pārspīlētu apgalvojumu, gan viltus drošības sajūtas sākums. Pakalpojumu sniedzējs, kas saka, ka neveic pārlūkošanas reģistrēšanu, var būt precīzs attiecībā uz URL reģistrēšanu un tomēr glabāt sesiju ierakstus, un pakešu ieraksts, kas parāda tikai adreses, bez apgrieztām vaicājumiem un minējumiem nekļūst par pārlūkošanas vēsturi.

Vērtējot politiku, atrodiet teikumu, kas apraksta katru slāni. Ja politika tos nenošķir, jautājiet, kādi ieraksti pastāv, tā vietā lai pieņemtu vispārīgu apgalvojumu par šifrēšanu.

Sesiju uzskaite: ko glabā parasts OpenVPN serveris

Noklusējuma iestatījumos OpenVPN serveris neieraksta satiksmi. Parastā izvade ir sesiju uzskaite: kurš konts autentificējās, no kādas avota adreses nāca, sākuma un beigu laika atzīmes, piešķirtā tuneļa adrese un baitu kopsummas abos virzienos. Tā ir sesiju uzskaite, nevis galamērķu saraksts.

Reģistrēšanas opcijas var pievienot detaļas. Augstāks detalizācijas līmenis raksta vairāk par rokasspiedienu, un statusa fails var uzskaitīt pievienotos klientus, bet neviens no tiem nepārvērš serveri par caurspīdīgu starpniekserveri. Lai iegūtu URL, jāpārtrauc TLS vai jāpalaiž skaidrs starpniekserveris, un abi maina uzticības kārtību, nevis ieslēdz slēptu funkciju.

Tāpēc precīzā versija apgalvojumam, ka pārlūkošanas žurnāla nav, ir šaurāka, nekā izklausās. Serveris nezina lapu, bet zina, ka sesija pastāvēja un cik aptuveni datu tai gāja cauri. Vai šis sesijas ieraksts tiek glabāts un cik ilgi, ir atsevišķs politikas jautājums.

Iekšējās un ārējās paketes ir atšķirīgi pierādījumi

Pakešu ieraksts ir veids, kā redzēt, kas patiešām iet caur tuneli. Serverī norādiet tuneļa saskarni un rakstiet failā, ko var analizēt bezsaistē:

sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | head

Šajā failā ir atšifrēta iekšējā satiksme: klienta tuneļa adrese kā avots, galamērķa adrese un ports, pakešu izmēri un laiks. Tajā nav HTTP ceļa vai atbildes pamatteksta, ja vien TLS kaut kur netika pārtraukts, un tie ir jutīgi dati, kuru glabāšana ir politikas lēmums, nevis atkļūdošanas ērtība.

Ieraksts fiziskajā saskarnē parāda ko citu. Tur redzamas ārējās paketes, kas adresētas VPN galapunktam, ar šifrētu saturu iekšpusē. Nesaistītas adreses šajā failā ir normālas, tiklīdz ir virtuālais adapteris, jo tuneļa ierīce pārvadā iekšējās plūsmas, bet šifrētais transports – ārējās.

Jautājiet, uz kādu jautājumu ierakstam jāatbild. Lietotnes tuneļa izmantošana ir redzama virtuālajā adapterī; tuneļa sasniedzamība līdz galapunktam ir redzama fiziskajā. Jebkura faila izmantošana kā visas ainas attēls dod secinājumus, ko dati neattaisno.

DNS ir vieta, kur nosaukumi kļūst redzami

DNS paliek praktiskais izņēmums. Atrisinātājs redz nosaukumus, ko tam lūdz atrisināt, tāpēc tas, kurš to pārvalda, uzzina, kādas vietnes klients meklē, pat ja vēlākie savienojumi ir šifrēti. Tuneļa ieraksts parāda adreses; atrisinātājs parāda nosaukumus.

Pārbaudiet, ar kādu adresi atrisinātājs sasniedza ārēju pakalpojumu. Atbilde ir atrisinātāja izejas adrese, un salīdzinājums ar VPN izeju parāda, vai vaicājums gāja caur tuneli:

dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53

Ja šī adrese sakrīt ar vietējo savienojumu, nevis tuneļa izeju, meklēšana apgāja VPN un nosaukums bija redzams vietējā ceļā. Atkārtojiet pārbaudi pēc klienta atjaunināšanas, jo jauna versija var mainīt, kuru atrisinātāju profils instalē.

Šifrēts DNS pārvieto redzamību, nevis to noņem. Tīkls vairs neredz vaicājumu, bet atrisinātājs to joprojām redz, un uzticības jautājums vienkārši maina rokas. TLS servera nosaukums savienojuma rokasspiedienā ir vēl viens daļējs signāls: tas bieži izdzīvo arī tad, kad saturs ir necaurredzams, tāpēc galamērķa adreses nav vienīgie metadati, ko pāradresējošs serveris var novērot.

Trīs ierakstu veidi un kas tos var lasīt

Sesiju uzskaite, ieraksti pēc nosaukuma un noplūdes pierādījumi ir trīs atšķirīgi produkti ar trim atšķirīgiem pienākumiem. Sesiju žurnāli ir lēti un mazjutīgi, un tie atbild, kas un kad pieslēdzās. Ierakstiem pēc nosaukuma vajag reģistrējošu atrisinātāju vai skaidru starpniekserveri, un tie rada atklāšanas pienākumu pret skartajiem cilvēkiem. Noplūdes pierādījumi ir klienta puses tests, kas salīdzina to, ko atklāj atrisinātājs, ar tuneļa izeju.

Pierakstiet, kuru no šiem trim jūs pārvaldāt, kas to var lasīt un cik ilgi tas paliek. Apgalvojumi, ka pakalpojums neglabā žurnālus, apraksta vienu slāni un paliek patiesi tikai šajā tvērumā. Viens un tas pats sniedzējs var būt precīzs par sesijām un kļūdīties par DNS.

Saglabājiet testu atkārtojamu: tas pats atrisinātāja vaicājums, tā pati ierakstīšanas saskarne un tas pats salīdzinājums. Privātuma apgalvojums, ko nevar pārbaudīt nosauktā slānī, ir sauklis, nevis darbības fakts.

Saistītie raksti