HTTPS, DoH, ECH e uma VPN escondem coisas diferentes
Cada mecanismo remove um observador diferente do caminho, e nenhum remove todos. Compare o que está protegido antes de acrescentar outro túnel.
Acrescentar uma VPN a um navegador que já usa HTTPS, DoH e ECH não empilha três proteções numa só; muda quem está em posição de observar o quê. Cada mecanismo remove uma parte diferente de uma troca diferente, e cada um deixa algo para trás. A pergunta útil não é qual é o mais forte, mas que observador está a tentar remover, porque a resposta decide se um túnel ajuda de todo. Uma comparação dos observadores restantes é mais útil do que uma lista de funcionalidades.
Quatro mecanismos, quatro observadores
Comece pelas quatro relações e pela parte que cada uma foi desenhada para manter de fora. A tabela abaixo é a que uso em revisão, porque obriga a conversa a nomear um observador em vez de uma tecnologia.
| Mecanismo | Relação que protege | Observador que não remove |
|---|---|---|
| HTTPS | A ligação TLS da aplicação ao seu ponto final nomeado | A rede de acesso continua a ver o endereço de destino |
| DoH | A troca DNS com o resolvedor HTTPS escolhido | Esse resolvedor vê cada consulta |
| ECH | Os campos sensíveis do ClientHello, onde são suportados e aceites | Os endereços de destino, e o DNS se não for coberto |
| VPN | Os pacotes cobertos levados até ao par de VPN | O operador da VPN vê os destinos |
O valor da tabela está no que se recusa a dizer. Não hierarquiza os mecanismos e não afirma que usar os quatro remove os quatro observadores. Uma aplicação web na nuvem que já termina o TLS na sua própria periferia está protegida da rede de acesso para essa troca, e nenhum túnel melhora essa propriedade concreta. O que um túnel pode mudar é qual rede vê os pacotes exteriores e que operador está agora no caminho.
O que o HTTPS esconde de facto
O HTTPS protege a troca da aplicação entre o cliente e o ponto final que o certificado nomeia. Não esconde o endereço de destino, não esconde que houve uma ligação e não esconde o nome, a menos que o ECH esteja em jogo. A validação do certificado faz parte da proteção, não é uma formalidade à volta dela.
Uma VPN não precisa de terminar esse TLS, e uma saída de encaminhamento não deve ser tratada como o ponto final autenticado da aplicação. Se um desenho faz a saída desencriptar, isso é outra arquitetura com outra declaração de confiança.
O que o DoH e o ECH movem, e o que deixam
O DoH move a troca DNS para um resolvedor HTTPS, o que significa que esse resolvedor vê as suas consultas em vez do resolvedor da rede local. É uma mudança real e delimitada: o resolvedor escolhido torna-se uma parte que pode correlacionar as consultas com os endereços a que depois se liga, e é precisamente a correlação que o RFC 8484 discute. Transporte cifrado não torna o destinatário ignorante das consultas a que responde.
O ECH protege a parte sensível do ClientHello para que um observador passivo no caminho não possa ler o nome de servidor pretendido. Depende de uma implementação com suporte e da aceitação pelo servidor e pela rede, e deixa outros canais no lugar: os endereços de destino continuam visíveis, e o DNS pode ainda revelar o nome.
A outra coisa que o ECH não faz é provar-se a si mesmo. Uma ligação que usa TLS 1.3 não é prova de que o ECH foi aceite, e um navegador que oferece ECH a um servidor que não o suporta recua em silêncio. Verifique o estado real da ligação em vez de o inferir da versão do protocolo.
É esta a forma geral de toda a comparação: cada mecanismo é verificado na sua própria camada, e nenhum deles é verificado pelo sucesso de outro.
O que uma VPN move, e o que acrescenta
Quando o tráfego web entra numa VPN, a rede de acesso vê a troca exterior com o par de VPN em vez das ligações individuais das aplicações, e o operador da VPN toma posição no caminho seguinte. É um deslocamento da fronteira de confiança, não a sua eliminação. O operador vê agora que destinos alcança, mesmo que o conteúdo continue cifrado de ponta a ponta. Se isso é uma melhoria depende inteiramente de qual destas duas partes confia menos.
Mantenha o HTTPS da aplicação e a proteção prevista do resolvedor no lugar enquanto faz isto. Um túnel não substitui a validação do certificado, e desligar as proteções de um resolvedor porque o tráfego passa por um túnel remove um controlo sem o substituir.
Escolher a partir do requisito
Enuncie o requisito real, porque é ele que decide o desenho. A admissão a recursos privados, um ponto de saída gerido, uma ameaça concreta da rede de acesso e a autorização de dispositivos são quatro necessidades diferentes com quatro respostas diferentes, e uma empresa que só usa aplicações de nuvem pública continua a ter de decidir a autorização e o tratamento de dados. Camadas adicionais podem ser adequadas sem serem permutáveis. Uma ligação mais complicada não é uma medida de anonimato e não é um argumento de segurança por si só.
A especificação do ECH, RFC 9849, vale a pena ler pelo que o mecanismo cobre e não cobre, e é honesta quanto aos canais que deixa em paz. Compare os mecanismos pelo observador que cada um remove, anote esse observador e depois decida se a camada extra se lhe dirige. Se a resposta for que o observador já estava fora do seu modelo de ameaças, o túnel é custo sem benefício.