DNS HTTPS - Solução meia e errada

Ao longo da existência da Internet, a abertura tem sido uma de suas características definidoras e a maior parte do tráfego atual ainda é transmitida sem criptografia. A maioria das solicitações de páginas HTML e conteúdo relacionado é feita em texto sem formatação e as respostas são retornadas da mesma maneira, apesar do protocolo HTTPS existir desde 1994.

No entanto, às vezes há necessidade de segurança e / ou confidencialidade. Embora a criptografia do tráfego da Internet tenha se espalhado amplamente em áreas como serviços bancários e compras on-line, a questão da manutenção da confidencialidade em muitos protocolos da Internet não foi resolvida tão rapidamente. Em particular, ao consultar o endereço IP de um site para um host, quase sempre uma consulta DNS é transmitida em texto não criptografado, o que permite que todos os computadores e provedores determinem qual site você está visitando, mesmo se você usar HTTPS após estabelecer uma conexão.

A idéia de que a criptografia também é necessária para consultas de DNS não é nova e as primeiras tentativas foram feitas nos anos 2000 - DNSCrypt, DNS sobre TLS (DoT) etc. Mozilla, Google e outras grandes empresas de Internet estão promovendo um novo método de criptografia de consultas DNS : DNS sobre HTTPS (DoH).

O DoH não apenas criptografa a consulta DNS, mas também a transfere para o servidor Web "regular", não para o servidor DNS, para que o tráfego DNS não possa ser diferenciado do HTTPS normal. Esta moeda tem dois lados. Esse procedimento protege a consulta DNS em si, como DNSCrypt ou DoT, e também impossibilita que os funcionários dos serviços de segurança de grandes empresas rastreiem a falsificação de DNS e transferem a responsabilidade por funções críticas da rede do sistema operacional para o aplicativo. E também não ajuda em nada a ocultar o endereço IP do site que você acabou de solicitar - afinal, você acessa o site mesmo assim.

Comparado ao DoT, o DoH centraliza informações sobre os sites que você visitou em várias empresas: hoje é o Cloudflare, que promete se livrar de seus dados em 24 horas, e o Google, que pretende salvar e monetizar todos os detalhes de tudo que você já planejou fazer.

DNS e privacidade são tópicos importantes, então vamos nos aprofundar nos detalhes.

Servidor DNS e confiança

O conceito de sistema de nome de domínio remonta à ARPANET , quando o único arquivo de texto em cada nó da ARPANET - sob o nome HOSTS.TXT - continha toda a correspondência entre os nomes dos sistemas conectados à ARPANET e seus endereços digitais. Quando você reabasteceu esse arquivo, foi fácil verificar se estava correto. Com o crescimento da rede, tornou-se irrealista manter cópias centrais e locais desses arquivos. No início dos anos 80, tentativas já haviam começado a criar um sistema de automação para esse processo.

O primeiro servidor de nomes (Berkeley Internet Name Domain Server ou BIND) foi escrito em 1984 por um grupo de estudantes da Universidade da Califórnia, Berkeley, com base nas RFC 882 e RFC 883. Em 1987, o padrão DNS foi revisado várias vezes, levando ao advento das RFC 1034 e RFC 1035. que desde então, em geral, não mudaram.



A base da estrutura DNS é sua estrutura em árvore, onde nós e folhas são divididos em zonas. A zona raiz do DNS é o nível superior, composto por treze clusters de servidores raiz que formam os servidores DNS raiz oficiais. Qualquer novo servidor DNS (criado por um provedor ou empresa) recebe registros DNS de pelo menos um desses servidores principais.

Cada zona DNS subsequente adiciona outro domínio ao sistema de nomes. Normalmente, cada país mantém seus próprios domínios e os domínios .org ou .com que não estão associados a países são servidos separadamente. Uma consulta para um nome de host por meio do DNS começa com um nome de domínio (por exemplo, .com) e, em seguida, com um nome (por exemplo, google), seguido por possíveis subdomínios. Se os dados ainda não foram armazenados em cache, pode ser necessário fazer várias transições pelas zonas DNS para resolver a solicitação.

DNSSEC: adicionando confiança ao sistema DNS

Antes de prosseguir com a criptografia das consultas DNS, você precisa garantir que possamos confiar no servidor DNS. Essa necessidade tornou-se aparente nos anos 90 e levou às primeiras extensões operacionais do DNS Security Standard (DNSSEC), RFC 2353 e RFC 4033 revisado (DNSSEC-bis).


Mapa da internet em 2006

DNSSEC funciona assinando registros de consulta DNS com uma chave pública. A autenticidade do registro DNS pode ser confirmada pelas chaves públicas da zona raiz do DNS, que é um terceiro confiável nesse cenário. Os proprietários do domínio geram suas chaves, assinadas pelos operadores de zona e adicionadas ao DNS.

Embora o DNSSEC permita que você esteja relativamente confiante de que as respostas do servidor DNS são reais, esse protocolo deve ser incluído no sistema operacional. Infelizmente, poucos sistemas operacionais implementam um serviço DNS que pode fazer mais do que apenas "saber sobre DNSSEC", ou seja, eles não confirmam realmente as respostas DNS. Portanto, hoje você não pode ter certeza de que as respostas que recebe do DNS são reais.

Problema com DoH

Suponha que você esteja usando DNSSEC. Você está pronto para criptografar mensagens para adicionar privacidade à sua transferência de dados. Pode haver muitas razões para manter as consultas DNS em segredo para olhares indiscretos. Entre os mais inocentes, estão ignorando os filtros da corporação e fornecedores, proibindo o monitoramento dos hábitos da Internet e muito mais. Entre os mais sérios estão as tentativas de evitar perseguições por parte do governo por expressar opiniões políticas na Internet. Naturalmente, a criptografia de consultas DNS não permite que as pessoas as espionem, mas, como resultado, problemas maiores com a segurança do DNS e, é claro, todos os outros protocolos de comunicação são ignorados.

Os principais concorrentes aqui são DoT usando TLS e DoH usando HTTPS. A diferença mais óbvia entre as duas é a porta: o DoT é executado em uma porta TCP dedicada 853 e o DoH se mistura com outro tráfego HTTPS na porta 443. Isso oferece a vantagem controversa de tornar as consultas DNS indistinguíveis de outro tráfego, o que torna impossível para os operadores de rede (privados e corporativos) ) proteja sua própria rede, como Paul Vixie, um dos arquitetos do DNS, anunciou no Twitter no ano passado.

A segunda das principais diferenças é que, se o DoT simplesmente envia consultas DNS pelo TLS, o DoH é essencialmente DNS sobre HTTP sobre TLS, requer seu próprio aplicativo Tipo de Mídia / dns-message e torna as coisas muito mais complicadas. A mistura de DoH com protocolos existentes faz com que cada consulta e resposta DNS passe pela pilha HTTPS. Esse é um pesadelo para aplicativos incorporados e também é incompatível com quase todos os tipos de equipamentos existentes.

O DoT tem outra vantagem - esse protocolo já foi implementado e, por muito mais tempo que o DoH, é usado por empresas como Cloudflare, Google e fornecedores de Internet locais; Um software de servidor padrão como o BIND usa o DoT imediatamente. No Android Pie OS (versão 9), o DNS sobre TLS será usado por padrão se o servidor DNS selecionado suportar DoT.

Por que mudar para o DoH se o DoT já está sendo implementado? Se aplicativos não padrão, como o Firefox, ignoram o DNS do sistema baseado em DoT e usam seu próprio sistema de recuperação de nomes de domínio via DoH, então, do ponto de vista da segurança, essa situação se tornará muito difícil. Transferir o DNS para aplicativos individuais, o que está acontecendo agora, parece um passo atrás. Você sabe qual método DNS cada aplicativo usa? Você sabia que ele mistura esse processo com o tráfego TCP na porta 443?

A criptografia não interfere com a espionagem

Duas grandes empresas, Cloudflare e Mozilla, defendem o DNS por HTTPS, e o último até lançou uma pequena e agradável história em quadrinhos , na qual tenta explicar o esquema de DoH. Sem surpresa, eles não mencionam o DNSSEC (mesmo que seja chamado de "crítico" na RFC 8484) e, em vez disso, oferecem algo chamado Trusted Recursive Resolver (TRR), que representa essencialmente o conselho "use trust Servidor DNS ”pelo qual Mozilla significa Cloudflare.

Além do DoH, eles mencionam o padrão de minimização de QNAME ( RFC 7816 ), que deve reduzir a quantidade de informações não críticas enviadas pelo servidor DNS. Ao mesmo tempo, esse padrão não depende do DoH de forma alguma e funcionará sem nenhuma criptografia DNS. Como no DNSSEC, a segurança e a privacidade são aprimoradas com a evolução do padrão DNS.

O mais interessante está na seção “O que o TRR + DoH não corrige”? Como muitos especialistas disseram, a criptografia DNS não impede a espionagem. Qualquer solicitação subsequente para o endereço IP que foi recebido de uma maneira terrivelmente secreta ainda será claramente visível. Mesmo assim, eles saberão que você visitou o Facebook.com ou o site para dissidentes. Nenhuma criptografia de DNS ou tráfego da Internet ocultará informações vitais para a operação de uma rede como a Internet.

A futura Internet se tornará um ponto único de falha?

A Mozilla se oferece para lidar com a questão da espionagem de IP simplesmente afirmando que isso não é um problema através do uso da nuvem. Quanto mais sites e redes de distribuição de conteúdo (CDNs) dependem de um pequeno número de serviços (Cloudflare, Azure, AWS, etc.), menos esse único endereço IP significa - você só precisa acreditar que o escolhido seu serviço de nuvem não roubará seus dados e não cairá por um dia.

Este ano, 24 de junho, houve uma queda maciça nos serviços, quando um erro de configuração cometido pelo provedor da Verizon deixou o Cloudflare, Amazon, Linode e muitos outros indisponíveis durante a maior parte do dia. Em 2 de julho deste ano , o Cloudflare caiu por cerca de meia hora e, com ele, muitos sites que dependem de seus serviços.

Coincidentemente, o serviço em nuvem Office365 da Microsoft também permaneceu por várias horas naquele dia, motivo pelo qual muitos usuários não conseguiram usar seus serviços. No fim de semana anterior ao Dia do Trabalho [feriado nacional dos EUA comemorado na primeira segunda-feira de setembro / aprox. A falha de energia trans.] no data center da AWS nos EUA-Leste-1 levou a que um terabyte de dados de clientes armazenados lá fosse coberto por uma bacia de cobre . Obviamente, ainda existem algumas desvantagens na idéia dos benefícios de centralizar a Internet.

Músicas antigas de uma nova maneira

Surpreendentemente, não há menção de redes privadas virtuais (VPNs) ao longo desta discussão sobre privacidade e rastreamento. Eles resolvem problemas com criptografia de dados e consultas DNS, ocultando o endereço IP e muito mais, simplesmente movendo o ponto em que seu PC ou outro dispositivo conectado à Internet se conecta à Internet. Dissidentes dentro de regimes autoritários usam VPNs há décadas para contornar a censura na Internet; As VPNs, incluindo recursos especiais como o Tor, são um elemento crítico da liberdade da Internet.


Como o Tor funciona

Se você confia em uma grande empresa comercial como a Cloudflare em um esquema como o DoH, será fácil encontrar um provedor de VPN confiável que não armazene ou venda seus dados. E o navegador Opera geralmente oferece suporte a proxy gratuito e integrado, que oferece muitos benefícios de VPN .

No final, podemos dizer que o DoH confirma sua sigla, fazendo mal que o DoT já esteja indo bem [“Doh!” - uma exclamação indicando a estupidez de uma ação perfeita, especialmente a sua / aprox. transl.]. Precisamos nos concentrar mais na implementação onipresente do DNSSEC, juntamente com o DoT e na minimização do QNAME. E se você se preocupa com a privacidade real, precisa recorrer à VPN.