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.

MecanismoRelação que protegeObservador que não remove
HTTPSA ligação TLS da aplicação ao seu ponto final nomeadoA rede de acesso continua a ver o endereço de destino
DoHA troca DNS com o resolvedor HTTPS escolhidoEsse resolvedor vê cada consulta
ECHOs campos sensíveis do ClientHello, onde são suportados e aceitesOs endereços de destino, e o DNS se não for coberto
VPNOs pacotes cobertos levados até ao par de VPNO 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.

Artigos relacionados