Mantenha-o criptografado, mantenha-o seguro: trabalhando com ESNI, DoH e DoT
Publicados: 2022-03-11Os desenvolvimentos mais recentes na proteção da privacidade na Internet incluem indicação de nome de servidor TLS criptografado (ESNI) e DNS criptografado na forma de DNS sobre HTTPS (DoH), ambos considerados altamente controversos pelos coletores de dados.
Então, aqui está uma rápida olhada nas razões pelas quais eles existem, os detalhes sobre o que são e a tecnologia por trás de como eles funcionam.
O DNS precisa funcionar corretamente
Conexões de rede privada virtual (VPN) de túnel dividido, o protocolo de descoberta automática de proxy da Web (WPAD), DNS multicast de configuração zero (mDNS), listas negras em tempo real (RBL) e muitas outras tecnologias amplamente implantadas são interrompidas quando o DNS não t funcione corretamente.
Quebrando a Internet para Lucro e Fama
Já em 2003, os usuários da Internet aprenderam sobre a importância do DNS em escala global quando a empresa que administrava o domínio de primeiro nível .com (TLD) optou por parar de emitir respostas NXDOMAIN . Em vez disso, eles personificaram qualquer domínio inexistente na tentativa de exibir mais anúncios, vender mais domínios e, finalmente, gerar mais receita. O efeito indireto inesperado resultou em um debate público e um relatório contundente do Comitê Consultivo de Segurança e Estabilidade da ICANN (SSAC). Este projeto foi de fato encerrado, mas do ponto de vista técnico, a vulnerabilidade persistiu.
Mais tarde, em 2008, outra tentativa de manipular o DNS para fins lucrativos foi anunciada publicamente quando alguns dos maiores ISPs acabaram introduzindo vários caminhos para ataques de script entre sites contra literalmente qualquer site. Devido à natureza das vulnerabilidades, até mesmo sites hospedados em uma rede privada e inacessíveis pela internet podem ser explorados.
O problema encontrado não é com os principais protocolos da Internet, mas sim um problema agravado pela monetização inadequada de determinados recursos do DNS.
Paul Vixie, Consórcio de Sistemas de Internet (ISC)
Embora seja verdade que os próprios protocolos não são realmente a causa do problema, também é verdade que esses protocolos não impedem que maus atores abusem do sistema. Então, do ponto de vista técnico, a vulnerabilidade persistiu.
Quebrando a Internet para Vigilância e Censura
Em 2016, observou-se que os ISPs no Irã estavam manipulando o DNS. Desta vez, em vez de injetar anúncios, eles estavam bloqueando o acesso aos servidores de e-mail de 139 dos 10.000 principais domínios da internet. Não está claro se esta é uma política intencional de negação de serviço contra esses domínios específicos - semelhante à censura de renome mundial na China - ou talvez apenas um exemplo de uma implementação técnica ruim de qualquer sistema que esteja interceptando as consultas DNS.
Veja também:
- Seu ISP está seqüestrando seu tráfego DNS?
- Meu ISP usa Inspeção Profunda de Pacotes; O que eles podem observar?
Não saber por que o DNS está sendo interceptado é importante: mesmo se deixarmos de lado as questões morais e legais sobre vigilância e censura geral, a tecnologia usada para fazer isso não é, por sua própria natureza, compatível com os padrões e pode muito bem estar interferindo na seu uso normal, diário, razoável e legal da Internet.
No entanto, do ponto de vista técnico, a vulnerabilidade persistiu.
Quebrando a Internet para fins nefastos
É claro que não são apenas entidades comerciais e governos que estão tentando interceptar o tráfego da Internet para seus próprios meios. Há muitos exemplos de criminosos que tentam seqüestrar conexões, geralmente com o objetivo de roubar dados de usuários ou induzir os usuários a revelar credenciais de acesso importantes. Mais proeminentemente, o envenenamento de cache DNS tem sido usado para direcionar usuários a sites de phishing, implantar ransomware, implantar botnets, negar serviço a sites específicos e muito mais.
TLS vaza quem se conecta a quem
Transport Layer Security (TLS) é a tecnologia por trás do HTTPS, a versão segura do HTTP na qual todos confiamos todos os dias. O estabelecimento de uma conexão TLS requer várias etapas, durante as quais o servidor prova sua identidade apresentando um certificado e novas chaves de criptografia são trocadas.
Fazer com que o servidor use um certificado para provar sua identidade é uma etapa muito importante, pois parte do certificado é uma chave de criptografia pública assimétrica.
Quando o cliente envia uma mensagem usando esta chave, somente o servidor que possui a chave privada associada pode ler a mensagem. Como resultado, qualquer pessoa que intercepte ou escute a conexão fica bloqueada e incapaz de ler o conteúdo.
No entanto, essa troca inicial ainda é feita sem criptografia, o que significa que um observador sempre saberá a identidade do servidor.
Fronting de domínio
Algumas ferramentas do tipo anticensura contornaram esse vazamento no TLS por um período de tempo usando uma técnica conhecida como fronting de domínio. Isso explora o fato de que, uma vez que uma conexão HTTPS é estabelecida, a maioria dos grandes provedores de hospedagem não verifica se o nome do host apresentado em cada solicitação HTTP corresponde ao usado no handshake TLS. Em termos de ferramentas de privacidade, isso foi visto como um recurso útil que permite a comunicação secreta com um site oculto. Para provedores de hospedagem e coletores de dados, isso foi visto como um abuso na forma como a especificação foi implementada.
Isso é por si só uma vulnerabilidade e, como tal, foi corrigido por vários grandes provedores de hospedagem, incluindo a AWS.
Resolvendo o problema alterando o padrão: SNI criptografado (ESNI)
A ideia por trás do ESNI é evitar que o TLS vaze quaisquer dados criptografando todas as mensagens, incluindo a mensagem inicial do Client Hello . Isso deixa qualquer observador completamente no escuro sobre qual certificado de servidor o servidor está apresentando.
Para fazer isso, o cliente precisa de uma chave de criptografia antes de fazer a conexão. Portanto, o ESNI exige que um conjunto específico de chaves de criptografia ESNI seja colocado em um registro SRV no DNS.
Os detalhes exatos disso ainda estão em fluxo, no entanto, como a especificação ainda não foi finalizada. Apesar disso, uma implementação do ESNI já foi colocada em produção pelo Mozilla Firefox e Cloudflare.
Protegendo e criptografando o DNS
Para que as chaves ESNI sejam entregues sem serem interceptadas, é importante proteger contra adulteração de DNS.
Desde 1993, a comunidade da Internet vem tentando proteger o DNS. O IETF observa que as primeiras reuniões de resolução de problemas discutiram:
- Proteção contra a divulgação de dados DNS a partes não autorizadas
- Garantindo a integridade dos dados
- Autenticação de origem de dados
Essas reuniões resultaram no padrão Domain Name System Security Extensions (DNSSEC) em 1997. O padrão optou por abordar duas de três dessas preocupações, pois a equipe de design tomou uma decisão explícita de excluir todas as ameaças de divulgação de dados explicitamente fora do escopo.
Como tal, DNSSEC significa que os usuários podem confiar que as respostas às suas consultas de DNS são o que os proprietários de domínio pretendem que sejam. No contexto da ESNI, isso significa que sabemos que a chave que estamos recebendo não foi adulterada e, felizmente, muitas vulnerabilidades mencionadas acima desaparecem quando o DNSSEC está em uso. No entanto, não garante privacidade e, portanto, ainda é vulnerável a problemas introduzidos por sistemas de vigilância e censura.
Infelizmente, como é totalmente compatível com o “DNS inseguro” e muito difícil de implementar corretamente, a adoção do DNSSEC é muito baixa. Muitos proprietários de domínio estão desistindo no meio da tentativa de configurá-lo, como evidenciado por inúmeras configurações inválidas e semi-configuradas vistas na natureza.
DNS sobre HTTPS (DoH)
Para que as chaves ESNI sejam entregues sem que os observadores saibam qual site os usuários estão tentando visitar, é importante proteger contra espionagem de DNS. Como tal, é bastante lógico e compreensível dizer que o DNS criptografado (como com DoH) é uma coisa boa. No entanto, como está hoje, o DNS não é criptografado.
Existem movimentos da Mozilla, Google, APNIC, Cloudflare, Microsoft e outros para mudar isso.
A experiência de usuário criptografada ideal
Um usuário que deseja aproveitar as tecnologias acima pode ter uma lista bastante longa de requisitos quando se trata dos detalhes práticos de UX para trabalhar com criptografia. Provavelmente, eles gostariam de evitar os gostos de:
- Ser forçado a usar um provedor de serviços DNS específico (não importa quão bom seja) ou a escolha ser invisível ou difícil de encontrar
- Cada aplicativo em um dispositivo manipulando o DNS de maneira diferente (por exemplo, o Firefox pode encontrar coisas que o Safari não pode)
- Todos os aplicativos em um dispositivo precisam criar sua própria implementação de DNS segura dentro de si
- Ter que configurar manualmente o DNS várias vezes
- Ter que optar por privacidade e segurança
- Aplicativos que retornam à operação insegura sem o consentimento do usuário
Usuários preocupados com a privacidade gostariam de:
- Privacidade de vigilância injustificada por qualquer pessoa
- Proteção contra publicidade direcionada com a qual eles não consentiram
- Proteção de seu próprio conteúdo publicado (por exemplo, em um site pessoal) de ser alterado ou manipulado a caminho de outros espectadores
- Garantia de que os espectadores de seu próprio conteúdo publicado não terão problemas simplesmente por acessá-lo
- Para continuar a ter a opção de controlar o DNS em suas próprias redes (porque às vezes, o DNS split-horizon é bom para manter os recursos internos no escopo dos usuários internos)
- A capacidade de ativar ou, pelo menos, desativar a filtragem no nível do DNS (por exemplo, Quad9, CleanBrowsing e OpenDNS Family Shield)
- Configuração fácil e sem complicações (ou seja, DHCP)
- Para ser solicitado a consentir em usar DNS sem criptografia
- Proteção não apenas para o tráfego do navegador, mas para todos os tipos de tráfego, por exemplo, e-mail, Slack, VoIP, SSH, VPN, etc.
Esforços atuais de criptografia
Quais opções existem para usuários com os objetivos acima?
A solução da Mozilla é um começo, mas está longe de ser o ideal. Eles estão apenas protegendo o Firefox; o padrão é substituir as configurações do seu sistema operacional em favor da escolha do provedor (Cloudflare) sem dizer isso, e silenciosamente volta a ser inseguro (em casos de bloqueio de DNS criptografado etc.)
A solução do Google é uma abordagem melhor. Eles estão protegendo o Android 9+, que se aplica a todos os aplicativos. (Não tenho certeza dos planos deles para o Chrome OS, mas suspeito que esteja em andamento.) Eles também estão protegendo o Chrome em todas as plataformas, mas ele só aciona a segurança quando a plataforma host está configurada para usar um provedor que oferece suporte à segurança. Isso é bom em termos de escolha do usuário, mas não é o ideal porque silenciosamente volta a ser inseguro.
Todos os outros navegadores principais também estão implementando suporte.
Na situação ideal para os usuários, a comunidade mais ampla de desenvolvedores de software e SO:
- Pare de implementar novos recursos de segurança DNS no nível do aplicativo
- Comece a implementá-los no nível do sistema operacional
- Respeite a configuração no nível do SO ou obtenha o consentimento do usuário
Implementando o DNS criptografado no nível do sistema operacional, poderíamos continuar seguindo o mesmo modelo distribuído que temos atualmente para resolvedores de DNS. Executar o próprio servidor DNS em sua própria rede e ser capaz de tornar esse resolvedor seguro faz sentido continuar sendo uma opção, assim como usar um provedor centralizado.
Linux e BSD já possuem esta funcionalidade com uma variedade de opções disponíveis. Infelizmente, nenhuma distro está habilitando qualquer um deles por padrão, até onde eu sei. Confira nss-tls se você quiser algo que seja plugado na glibc.
A implementação de DNS sobre TLS do Google no Android 9+ também já faz isso. Ele funciona testando o servidor DNS para suporte de criptografia. Se ele tem, então ele vai usá-lo. Caso contrário, como no Chrome, ele continua de maneira insegura, sem solicitar consentimento.
Vale a pena notar que a maioria das redes está configurada para usar servidores DNS que não suportam criptografia, portanto, a solução incorporada ao Android ainda não altera nada para a maioria dos usuários. Talvez seja melhor oferecer um DNS criptografado centralizado nos casos em que o descentralizado não suporta criptografia.
Para dispositivos de sabor Apple e Microsoft, o suporte para DNS criptografado ainda não chegou oficialmente até o momento. Com a Microsoft anunciando em novembro de 2019 suas intenções de oferecer suporte ao DNS criptografado, esperamos que a Apple siga em breve.
Soluções alternativas de DNS criptografado
Existem algumas soluções alternativas na forma de proxies que podem ser executadas localmente. Com eles, o computador de um usuário fala o DNS não criptografado para si mesmo, que então fala o DNS criptografado para qualquer provedor que esteja configurado para usar. Esta não é uma solução ideal, mas como soluções alternativas, é decente.
A inspiração para escrever este artigo é o proxy DNSCrypt, que é muito estável, tem muitos recursos e é multiplataforma. Ele suporta o protocolo DNSCrypt mais antigo, bem como os protocolos DNS sobre TLS (DoT) e DNS sobre HTTPS (DoH) mais recentes.
Para usuários do Windows, há um instalador e GUI chamado Simple DNSCrypt, que é completo e muito fácil de usar.
Eu recomendo, mas esteja ciente de que o mundo provavelmente ainda não está pronto para você, e você pode precisar desativá-lo de tempos em tempos (por exemplo, quando você tiver que usar um portal cativo em seu café favorito ou em uma LAN Festa).
Outras opções
Além disso, há o Technitium DNS Server, que suporta DNS criptografado, é multiplataforma (Windows, MacOS, Linux em ARM/Raspberry Pi) e possui uma interface web elegante. Está em “outros” porque é mais uma ferramenta completa do que uma solução específica para esse problema. (Provavelmente seria uma boa escolha se você deseja executar seu servidor DNS Raspberry Pi em casa. Estou interessado em ouvir comentários de pessoas que experimentam nos comentários abaixo.)
Para seus dispositivos Android ou iOS (iPhone, iPad, etc.), há também o aplicativo 1.1.1.1, que forçará todas as suas consultas DNS pelo serviço DNS criptografado da Cloudflare. Ouvi dizer que também existem aplicativos mais flexíveis, como o Intra, mas ainda não tive tempo de testá-los.
Claro, você também pode habilitar o DNS criptografado no Firefox e no Chrome - lembre-se de todas as advertências discutidas acima.
Confiabilidade do DNS: Trabalho número um
Há muita controvérsia com a tecnologia de privacidade na Internet. No entanto, quando se trata de implementar medidas de segurança e privacidade, a tecnologia em questão não trata principalmente de manter segredos. Trata-se de garantir a confiabilidade e garantir que a tecnologia continue funcionando corretamente, apesar do comportamento dos outros. No entanto, precisamos estar cientes de que, assim como a tecnologia sem salvaguardas de privacidade é ruim, as salvaguardas mal implementadas só podem piorar a situação.