O Chrome 78 começará a experimentar a ativação de DNS sobre HTTPS

Seguindo Mozilla Empresa Google relatado sobre a intenção de realizar um experimento para testar a implementação “DNS over HTTPS” (DoH, DNS over HTTPS) que está sendo desenvolvida para o navegador Chrome. Chrome 78, previsto para 22 de outubro, terá algumas categorias de usuários por padrão traduzido para usar DoH. Somente usuários cujas configurações atuais do sistema especifiquem determinados provedores de DNS reconhecidos como compatíveis com DoH participarão do experimento para habilitar o DoH.

A lista branca de provedores de DNS inclui serviços Google (8.8.8.8, 8.8.4.4), Cloudflare (1.1.1.1, 1.0.0.1), OpenDNS (208.67.222.222, 208.67.220.220), Quad9 (9.9.9.9, 149.112.112.112), Cleanbrowsing (185.228.168.168. 185.228.169.168, 185.222.222.222) e DNS.SB (185.184.222.222, XNUMX). Se as configurações de DNS do usuário especificarem um dos servidores DNS mencionados acima, o DoH no Chrome será habilitado por padrão. Para quem utiliza servidores DNS fornecidos pelo seu provedor de Internet local, tudo permanecerá inalterado e o resolvedor do sistema continuará a ser utilizado para consultas DNS.

Uma diferença importante em relação à implementação do DoH no Firefox, que gradualmente habilitou o DoH por padrão vai começar já no final de setembro, é a falta de vinculação a um serviço DoH. Se estiver no Firefox por padrão usado Servidor DNS CloudFlare, o Chrome atualizará apenas o método de trabalho com DNS para um serviço equivalente, sem alterar o provedor de DNS. Por exemplo, se o usuário tiver DNS 8.8.8.8 especificado nas configurações do sistema, o Chrome irá ativado Serviço Google DoH (“https://dns.google.com/dns-query”), se o DNS for 1.1.1.1, então serviço Cloudflare DoH (“https://cloudflare-dns.com/dns-query”) e etc.

Se desejar, o usuário pode ativar ou desativar o DoH usando a configuração “chrome://flags/#dns-over-https”. São suportados três modos de operação: seguro, automático e desligado. No modo “seguro”, os hosts são determinados apenas com base em valores seguros previamente armazenados em cache (recebidos por meio de uma conexão segura) e solicitações via DoH; o fallback para DNS normal não é aplicado. No modo “automático”, se o DoH e o cache seguro não estiverem disponíveis, os dados podem ser recuperados do cache inseguro e acessados ​​através do DNS tradicional. No modo “off”, o cache compartilhado é verificado primeiro e caso não haja dados a solicitação é enviada através do DNS do sistema. O modo é definido através configurando kDnsOverHttpsMode e o modelo de mapeamento de servidor por meio de kDnsOverHttpsTemplates.

O experimento para habilitar o DoH será realizado em todas as plataformas suportadas no Chrome, com exceção do Linux e iOS, devido à natureza não trivial da análise das configurações do resolvedor e da restrição do acesso às configurações de DNS do sistema. Se, após habilitar o DoH, houver problemas no envio de solicitações ao servidor DoH (por exemplo, devido ao seu bloqueio, conectividade de rede ou falha), o navegador retornará automaticamente as configurações de DNS do sistema.

O objetivo do experimento é testar a implementação do DoH e estudar o impacto do uso do DoH no desempenho. Deve-se notar que, na verdade, o apoio do DoH foi adicionado na base de código do Chrome em fevereiro, mas para configurar e ativar o DoH obrigatório iniciar o Chrome com um sinalizador especial e um conjunto não óbvio de opções.

Lembremos que o DoH pode ser útil para prevenir vazamentos de informações sobre os nomes de host solicitados através dos servidores DNS dos provedores, combater ataques MITM e falsificação de tráfego DNS (por exemplo, ao conectar-se a redes Wi-Fi públicas), combater o bloqueio no DNS nível (o DoH não pode substituir uma VPN na área de contornar o bloqueio implementado no nível DPI) ou para organizar o trabalho se for impossível acessar diretamente os servidores DNS (por exemplo, ao trabalhar através de um proxy). Se em uma situação normal as solicitações DNS são enviadas diretamente aos servidores DNS definidos na configuração do sistema, então no caso do DoH, a solicitação para determinar o endereço IP do host é encapsulada no tráfego HTTPS e enviada ao servidor HTTP, onde o resolvedor processa solicitações por meio da API da Web. O padrão DNSSEC existente utiliza criptografia apenas para autenticar o cliente e o servidor, mas não protege o tráfego contra interceptação e não garante a confidencialidade das solicitações.

Fonte: opennet.ru

Adicionar um comentário