¿Un VPN delante de Tor te hace más difícil de vigilar?

Añadir otro segmento cifrado a una ruta no elimina observadores; los reubica y, a veces, añade uno. El ejercicio útil consiste en dibujar la ruta y etiquetar quién ve qué en cada paso, porque una VPN delante de Tor y una VPN alcanzada a través de Tor dan respuestas opuestas a casi todas las preguntas que merece la pena hacerse. Ninguno de los dos arreglos derrota a un extremo comprometido, y ninguno arregla una cuenta que nombre al usuario. Recorrer la ruta en orden y luego preguntar qué falla cuando desaparece una capa convierte un eslogan en una decisión.

Recorre la ruta y nombra a cada observador

Empieza por el caso sencillo de Tor y etiqueta cada salto. La red local y el proveedor de internet ven una conexión a un punto de entrada de Tor, junto con su tamaño y su temporización. El guardián de entrada ve la dirección del cliente, y por eso el guardián es una relación de larga duración y no una elección aleatoria. El nodo de salida ve el destino y el texto plano de todo lo que no está cifrado de extremo a extremo, mientras que el destino ve una dirección de salida sin ninguna dirección de cliente asociada.

Anota esas etiquetas antes de añadir nada. El diagrama es el argumento, y es fácil de comprobar.

Dos órdenes producen observaciones distintas

Una VPN situada delante de Tor significa que el tráfico sale del dispositivo hacia el proveedor de VPN, sale de ese proveedor y solo entonces llega a una entrada de Tor. La red local ya no ve Tor en absoluto, que es justo el objetivo cuando una red lo bloquea o lo vigila. El guardián de entrada ahora ve la dirección de la VPN en lugar de la del usuario, y el proveedor de VPN ve que un cliente concreto se conecta a Tor con un patrón temporal determinado. Ese proveedor se convierte en una parte nueva con una observación valiosa, y su política de registros pasa a formar parte del modelo de amenazas en lugar de quedar fuera de él.

Llegar a una VPN a través de Tor invierte el orden e invierte también la exposición: el destino ve la dirección de la VPN, la salida de Tor ya no ve el destino y el proveedor de VPN ve llegar tráfico de Tor en lugar de la dirección de casa de un cliente. Además grava la conexión con dos capas de latencia y exige un soporte de cliente que muchas aplicaciones comerciales no ofrecen.

Elegir entre ellas es una cuestión de qué observador importa más, no de cuál suena más seguro. Un usuario que esconde el uso de Tor a una red local quiere el primer orden; un usuario que intenta que un destino no aprenda nada que pueda atribuírsele necesita otro análisis, y ninguno de los dos órdenes esconde un nombre de cuenta.

Qué sigue identificando la sesión

Los observadores a nivel de dirección son solo una parte de la imagen, y a menudo no la decisiva. Una cuenta con sesión iniciada ata la actividad a una identidad con independencia de qué dirección de salida llevó el paquete, y un registro de pago que el servicio pueda vincular a una persona hace lo mismo. El estado del navegador también contribuye: una cookie persistente, una sesión guardada o una extensión identificadora pueden seguir a un usuario por circuitos diseñados para no ser vinculables.

El contenido enviado a un sitio es la tercera señal. Un documento con metadatos, un nombre escrito en un formulario o un estilo de escritura único sobreviven a cualquier número de capas de cifrado, y ninguna de las herramientas que tiene delante está diseñada para tocar eso. Mantener una lista honesta de estos identificadores protege más que añadir otro salto.

Planifica una capa que desaparezca

El comportamiento ante fallos es donde los arreglos realmente difieren, y es una propiedad de configuración y no una característica de ninguna de las dos herramientas. Si la VPN cae mientras Tor está configurado para pasar por ella, ¿se detiene Tor o se reconecta en silencio por la ruta ordinaria? El segundo resultado no es una fuga hacia el destino, pero revela a la red local que se está usando Tor, que puede ser exactamente lo que el arreglo pretendía evitar.

Un interruptor de corte a nivel de dispositivo puede imponer parte de la respuesta al rechazar el tráfico fuera del túnel, y solo cubre el tráfico que el dispositivo enruta. Una aplicación excluida del túnel se salta esa protección, y un resolutor usado durante la configuración de la conexión puede revelar nombres incluso cuando la carga útil permanece dentro del túnel. Lee las exclusiones y la configuración del resolutor en lugar de suponer que el interruptor lo cubre todo.

Deja en paz el paquete del navegador

Las protecciones del Tor Browser dependen de que todo el paquete se comporte como se diseñó: su propia configuración de proxy, su aislamiento entre sitios y sus defensas contra huellas digitales. Apuntar un navegador corriente a un puerto local de Tor, o añadir una extensión de proxy al Tor Browser, cambia supuestos en los que se basa el diseño. La propia guía del Tor Project sobre combinar una VPN con Tor trata la combinación como una configuración avanzada, y esa cautela se refiere a estas interacciones y no al proveedor de la VPN.

Antes de combinar herramientas, sé capaz de exponer con frases sencillas la ruta normal, la ruta de fallo y el papel de cada operador. Si la única justificación es que dos capas suenan más seguras, no hay ningún requisito contra el que diseñar, y el modo de fallo añadido es lo principal que se ha añadido.