DNSSEC - Como se protege de um ataque MITM?

Question

Eu tenho lido por várias horas sobre DNSSEC e ainda não consigo entender como ele protege de MITM ataques. Eu também li todas as perguntas aqui no serverfault relacionadas a DNSSEC .

Por favor, dê uma olhada nesta DNSSEC captura de pacotes: link

O que impede o MITM de interceptar todas as consultas e responder com seus próprios pares de chaves para cada DNSKEYS , RRSIG e DS registros?

Por exemplo, o MITM geraria o RRSIG para www.ietf.org, em seguida, DNSKEYS para ietf.org e, em seguida, DS para ietf.org . Em seguida, outro conjunto de DNSKEYS e DS registra "org" e, em seguida, novamente <Root> .

No TLS, podemos confiar na cadeia de confiança das CAs, pois as CAs raiz são pré-instaladas em todos os sistemas, para que possamos verificar as respostas. Em DNSSEC , não acredito que a raiz DNSKEY esteja instalada em sistemas como as CAs Raiz. Então, o que faz com que possamos confiar nesta chave que recebemos?

    

Answer 1

Este problema é resolvido com uma cadeia de confiança : cada link nesta cadeia assinou DS registro (s) na zona anterior, como já mencionado na sua pergunta. Isso enfatiza a importância de uma âncora nos servidores de nomes raiz. Se isso foi falsificado, toda a cadeia de confiança foi comprometida. Portanto, os resolvedores devem ser pré-configurados com a âncora de confiança . RFC 6781 explica:

4.2.3. Compromises of Keys Anchored in Resolvers

A key can also be pre-configured in resolvers as a trust anchor. If trust anchor keys are compromised, the administrators of resolvers using these keys should be notified of this fact. Zone administrators may consider setting up a mailing list to communicate the fact that a SEP key is about to be rolled over. This communication will of course need to be authenticated by some means, e.g., by using digital signatures.

End-users faced with the task of updating an anchored key should always verify the new key. New keys should be authenticated out-of- band, for example, through the use of an announcement website that is secured using Transport Layer Security (TLS) [RFC5246].

Você pode fazer o download das Âncoras de confiança raiz atuais ( bind.keys ) diretamente dos Sistemas da Internet Consórcio. O site é protegido usando TLS & o arquivo também é assinado com sua chave de assinatura.

If you don’t have anything in named.conf and there is no bind.keys file, named will use the compiled in keys.

Note: these are managed keys, so this is only applies the first time you execute named. Assuming that the keys are not already expired (in which case named will log that the key is expired and validation will not work), named will use RFC 5011 to detect new keys and automatically roll and maintain keys. Once named is managing the keys, the current keys will be in managed-keys.bind or *.mkeys, if you use views.

Outro problema é a comunicação com o seu resolvedor, a "última milha". O resolvedor pode estar validando as assinaturas e respondendo com o bit DNS Authenticated Data (AD) , mas como o DNS funciona em texto simples, os resultados podem ser modificados por um invasor man-in-the-middle (MITM). Existem várias soluções possíveis para isso:

• Você poderia ter um próprio resolvedor local com o arquivo de chaves de ancoragem, mas essa não é uma solução prática para massas. Isso também causa mais tráfego para os servidores de nomes raiz, se não houver encaminhadores configurados. É uma solução confiável, em que você verifica as assinaturas sozinho.

• DNS-sobre-TLS & DNS-over-HTTPS . Por exemplo. A Cloudflare, com o 1.1.1.1 , suporta ambos :

  What's needed is a move to a new, modern protocol. There are a couple of different approaches. One is DNS-over-TLS. That takes the existing DNS protocol and adds transport layer encryption. Another is DNS-over-HTTPS. It includes security but also all the modern enhancements like supporting other transport layers (e.g., QUIC) and new technologies like server HTTP/2 Server Push. Both DNS-over-TLS and DNS-over-HTTPS are open standards.

  We think DNS-over-HTTPS is particularly promising — fast, easier to parse, and encrypted. – – We're hoping that with an independent DNS-over-HTTPS service now available, we'll see more experiments from browsers, operating systems, routers, and apps to support the protocol.

• DNSCrypt autentica as comunicações entre um cliente DNS e um resolvedor de DNS usando assinaturas criptográficas. Isso nunca foi proposto para o IETF (não há RFC).

Answer 2

Além da resposta extensa de Esa Jokinen, voltemos a:

Eu não acredito que o DNSKEY raiz esteja instalado em sistemas como as CAs Raiz. Esta é a falsa suposição que você cria, e então todas as conseqüências que você tem o direito de descrever.

Mas a raiz DNSKEY é enviada com os resolvedores. O que cria outros problemas, especialmente após a mudança planejada desta chave (ela foi planejada para o último mês de outubro, mas foi adiada).

Você tem mesmo um bootstrap DNSSEC. O software deve ter a chave fora da banda, mas também pode precisar atualizá-lo. O que acontece se você comprar um produto hoje, portanto enviado com a chave atual, deixá-lo assim por dois anos e depois ligá-lo, onde a chave raiz atual do DNSKEY terá sido substituída por outra?

Você pode imaginar muitas coisas como ... vamos pegar a chave do site da IANA através do HTTPS, é claro! Só que para fazer isso você precisa resolver o nome do site da IANA e, portanto, você depende do DNS e do DNSSEC associado que está tentando configurar. E você não irá, obviamente, codificar endereços IP de sites da IANA. Ou você pode imaginar confiar apenas no TLS, pois você pode até trocar as cadeias de confiança DNS / DNSSEC durante o handshake TLS ... exceto que isso significa que você precisa enviar um certificado de CA, que pode mudar (mesmo que possamos dizer agora) que os certificados de CA duram / durarão mais do que a chave de raiz do DNSSEC ... exceto que com o Let's Encrypt poderíamos também imaginar um futuro com CAs mais curtas ...), então voltemos à estaca zero.

Problema de galinha e ovo.

Você pode aprender mais sobre este problema e soluções para ele neste documento, por exemplo: link Este documento discute uma abordagem para configuração automática de    confiar em âncoras em um validador DNSSEC.

Se você já tiver uma chave raiz DNSSEC válida (atual), haverá um procedimento específico a seguir para alternar automaticamente, com segurança, para chaves mais novas quando elas ocorrerem: Atualizações Automáticas de Âncoras de Confiança de Segurança de DNS (DNSSEC)