VPN e Tor non substitúen HTTPS: onde acaba cada capa
Un túnel acaba no seu propio par e un circuíto Tor acaba nun relé de saída. HTTPS é a única capa que chega ao sitio, así que un formulario sen cifrar segue sendo lexible.
Unha VPN e un circuíto Tor cifran o tráfico durante parte da viaxe. Ambos deixan de cifralo nun par que elixen eles mesmos. HTTPS é a capa que chega ao propio sitio web, e ningunha cantidade de tunelización diante dela converte o envío dun formulario sen cifrar nun protexido. Seguir cada capa ata o punto onde remata fai iso evidente.
Tres capas, tres puntos finais distintos
Unha VPN convencional remata o seu túnel no servidor VPN. Todo o que hai entre o teu dispositivo e ese servidor está dentro do túnel, e todo o que vén despois non. Un circuíto Tor compórtase igual con outro par, e abandona a rede nun relé de saída que reenvía a túa petición ao destino.
TLS remata no sitio web. O certificado que validaches vincula un nome de host a unha chave que controla o sitio, e as chaves de sesión existen entre o teu navegador e ese servidor. Ese punto final queda máis alá tanto do servidor VPN como da saída de Tor.
Así pois, as tres capas teñen tres límites de confianza distintos, e unha petición pasa por todas elas en secuencia. Reforzar unha non di nada das demais, e a última é a única na que participa o destino.
Que expón o último salto
Se a aplicación usa HTTP simple, o contido máis alá da saída é lexible por quen opere ese salto. O túnel anterior fixo o seu traballo á perfección e simplemente xa non está. As credenciais escritas nun formulario HTTP quedan expostas exactamente no punto onde rematou a protección.
| 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 |
Con HTTPS validado correctamente, un intermediario no camiño non pode ler nin modificar silenciosamente o contido da aplicación. Segue vendo que te conectaches, cando e a que enderezo, porque as cabeceiras dos paquetes teñen que ser encamiñables. A confidencialidade do contido e os metadatos sobre a conexión son propiedades distintas, e só a primeira é o que achega TLS.
A identidade da conta é outra terceira cousa. Iniciar sesión nunha conta identifícate ante ese servizo independentemente de que enderezo de saída usases, así que a saída protexe o camiño de rede e non a conta. Esa distinción sobrevive a calquera número de capas diante. Cambiar de saída nunca cambia o que revela unha sesión iniciada. O servizo sabía quen eras antes de que saíse o primeiro paquete.
Nada deste arranxo se rompe ao engadir un segundo túnel. O que cambia é que observador ve o primeiro salto, non se o último salto está cifrado.
A orde cambia os observadores, non o punto final
Encadear unha VPN e Tor é unha forma lexítima de cambiar quen ve que a nivel de rede. Executar Tor sobre unha VPN oculta á túa rede de acceso o feito de que usas Tor, mentres que executar unha VPN sobre Tor oculta o teu enderezo ao provedor de VPN. Ambas as ordes están descritas en documentación pública e ambas teñen compromisos de rendemento e de comportamento ante fallos.
Ningunha das dúas ordes move o punto final de TLS. En ambos os casos o navegador segue validando un certificado para o nome de host solicitado, e en ambos os casos un URL HTTP segue enviando o seu contido sen cifrar máis alá do último relé. A composición cambia a lista de observadores; non cambia o número de capas no destino.
Por iso os consellos sobre encadear adoitan tratar de modelos de ameaza e non de seguridade en xeral. Unha cadea máis longa non é unha versión máis forte do mesmo, e non substitúe o protocolo que escolleu a aplicación.
curl -sSI https://example.net | head -3
openssl s_client -connect example.net:443 -servername example.net -brief
Ambos os comandos mostran a capa que importa no destino. O segundo imprime o protocolo negociado sen implicar ningún túnel. Ningún dos dous che di nada sobre a saída que usaches.
Mantén a validación funcionando mentres diagnostica
Un aviso de certificado é información sobre a conexión que estás a piques de facer. Pode significar un nome de host que non coincide, un problema de reloxo, unha cadea non fiable ou un intento de interceptación. Engadir unha excepción permanente porque hai unha VPN conectada elimina o único sinal que distinguiría eses casos.
As funcións de conexión segura do navegador Tor e os seus avisos existen polo mesmo motivo, e desactivalas para que unha páxina cargue cambia un fallo visible por un invisible. Se non se pode chegar a un sitio sen excepción, a conclusión honesta é que a conexión non é verificable, non que o túnel a fixo segura.
O cifrado tampouco di nada sobre a intención. Unha conexión HTTPS válida cun sitio enganoso entrega os teus datos a ese sitio cunha confidencialidade perfecta. Comproba o enderezo e o que envías, non só se está o cadeado.
Os servizos Onion son un modelo verdadeiramente distinto. Chégase a eles pola rede Tor sen unha saída pública ordinaria, o que non é o mesmo que acceder a un sitio público a través de Tor. Trátao como un caso á parte coas súas propias expectativas, non como unha versión máis forte da mesma visita.
A regra que sobrevive a calquera configuración é curta. Mantén intacta a validación do navegador. Xulga cada capa por onde remata realmente.