Pot veure l'operador d'una VPN quins llocs visiteu?
Un servidor OpenVPN per defecte registra sessions, no URL. Compareu els registres de connexió, una captura del túnel i una prova de fuita de DNS abans d'afirmar què veu l'operador.
Pregunteu què pot veure la VPN i la resposta depèn de on sigueu dins del camí. A la capa de sessió l'operador té esdeveniments d'autenticació i recomptes de bytes. A la capa de paquets té adreces de destinació i temps. A la capa de DNS pot tenir els noms mateixos. Cada capa respon una pregunta diferent, i cap interruptor no us mou entre elles.
Dibuixeu la capa abans de fer cap afirmació
La mateixa connexió produeix registres diferents a cada punt, i una afirmació sobre privacitat només té sentit quan anomena el punt. Llegiu la taula columna per columna: què hi ha en aquella capa, què hi pot veure l'operador i què aquells mateixos registres encara no li poden dir.
| Layer | Visible there | Not visible there |
|---|---|---|
| Session and authentication | Account, client address, start and stop times, assigned address, byte counts | URLs, page content, search terms |
| Forwarded packets | Destination address and port, sizes, timing, often the TLS server name | HTTP path, headers, response body |
| DNS resolver | Queried names and the client that asked | Page content and later requests |
| TLS-terminating proxy | Full request line, headers and body | Nothing, by design |
Llegir una sola capa com si fos tota la imatge és com comencen tant les exageracions com la falsa tranquil·litat. Un proveïdor que diu que no registra la navegació pot ser exacte sobre el registre d'URL mentre encara guarda registres de sessió, i una captura de paquets que només mostra adreces no es converteix en historial de navegació sense cerques inverses i conjectures.
Quan valoreu una política, trobeu la frase que descriu cada capa. Si la política no les separa, pregunteu quins registres existeixen en lloc d'acceptar una afirmació general sobre el xifratge.
Inventari de sessions: què guarda un servidor OpenVPN estàndard
Tal com surt de fàbrica, un servidor OpenVPN no captura trànsit. La sortida normal és un inventari de sessions: el compte que s'ha autenticat, l'adreça d'origen d'on ha vingut, marques de temps d'inici i final, l'adreça del túnel assignada i els totals de bytes en cada direcció. És un inventari de sessions, no una llista de destinacions.
Les opcions de registre poden afegir detall. Un nivell de verbositat més alt escriu més sobre l'apretada de mans, i un fitxer d'estat pot llistar els clients connectats, però cap de les dues coses converteix el servidor en un proxy transparent. Produir URL requereix acabar el TLS o executar un proxy explícit, i totes dues coses canvien l'acord de confiança en lloc d'activar una funció oculta.
Per això la versió exacta de l'afirmació que no hi ha registre de navegació és més estreta del que sembla. El servidor no coneix la pàgina, però sap que una sessió va existir i aproximadament quantes dades hi van passar. Si aquest registre de sessió es guarda, i durant quant de temps, és una qüestió de política a part.
Els paquets interiors i els exteriors són proves diferents
Una captura de paquets és com veieu què travessa realment el túnel. Al servidor, anomeneu la interfície del túnel i escriviu en un fitxer que es pugui analitzar fora de línia:
sudo tcpdump -ni tun0 -w /tmp/tun.pcap
sudo tcpdump -r /tmp/tun.pcap -nn | headAquest fitxer conté trànsit interior desxifrat: l'adreça del túnel del client com a origen, l'adreça i el port de destinació, les mides dels paquets i el temps. No conté el camí HTTP ni el cos de la resposta tret que s'hagi acabat el TLS en algun lloc, i són dades sensibles la retenció de les quals és una decisió de política i no una comoditat de depuració.
Una captura a la interfície física mostra una altra cosa. Allà veieu paquets exteriors adreçats al punt final de la VPN, amb la càrrega xifrada a dins. Les adreces no relacionades que apareixen en aquest fitxer són normals un cop existeix un adaptador virtual, perquè el dispositiu del túnel porta els fluxos interiors mentre el transport xifrat porta els exteriors.
Pregunteu què ha de respondre la captura. L'ús que fa una aplicació del túnel és visible a l'adaptador virtual; l'abast del túnel fins al punt final és visible a la interfície física. Fer servir qualsevol dels dos fitxers com si fos la imatge completa produeix conclusions que les dades no poden sostenir.
El DNS és on els noms es fan visibles
El DNS continua sent l'excepció pràctica. El resolutor veu els noms que li demanen de resoldre, així que qui el gestiona aprèn quins llocs consulta un client encara que les connexions posteriors estiguin xifrades. Una captura del túnel mostra adreces; el resolutor mostra noms.
Comproveu quina adreça ha fet servir el resolutor per arribar a un servei exterior. La resposta és l'adreça de sortida del resolutor, i comparar-la amb la sortida de la VPN us diu si la consulta ha viatjat pel túnel:
dig +short myip.opendns.com @resolver1.opendns.com
dig example.com
sudo tcpdump -ni any udp port 53Si aquesta adreça coincideix amb la connexió local i no amb la sortida del túnel, la consulta ha evitat la VPN i el nom era visible pel camí local. Repetiu la comprovació després d'una actualització del client, perquè una versió nova pot canviar quin resolutor instal·la el perfil.
El DNS xifrat mou la visibilitat en lloc d'eliminar-la. La xarxa ja no veu la consulta, però el resolutor sí, i la qüestió de confiança simplement canvia de mans. El nom del servidor TLS a l'apretada de mans de la connexió és un altre senyal parcial: sovint sobreviu fins i tot quan la càrrega és opaca, així que les adreces de destinació no són les úniques metadades que un servidor de reenviament pot observar.
Tres tipus de registres i qui els pot llegir
La comptabilitat de sessions, els registres per nom i les proves de fuita són tres productes diferents amb tres obligacions diferents. Els registres de sessió són barats i de baixa sensibilitat, i responen qui s'ha connectat i quan. Els registres per nom requereixen un resolutor que registri o un proxy explícit, i creen una obligació de revelació envers les persones afectades. La prova de fuita és una prova del costat del client que compara què revela el resolutor amb la sortida del túnel.
Anoteu quin d'aquests tres executeu, qui el pot llegir i quant de temps es queda. Les afirmacions que un servei no guarda registres descriuen una capa, i només són certes dins d'aquest abast. El mateix proveïdor pot ser exacte sobre les sessions i equivocar-se sobre el DNS.
Manteniu la prova reproduïble: la mateixa consulta al resolutor, la mateixa interfície de captura i la mateixa comparació. Una afirmació de privacitat que no es pot provar en una capa anomenada és un eslògan, no un fet operatiu.