Verificador de registros DANE/TLSA

Consulta os registros TLSA publicados pelos servidores de e-mail (hosts MX) de um domínio em vários resolvedores DNS públicos para verificar se o DANE está configurado.

Dicas

  • Os registros TLSA não ficam sob o nome de domínio comum — eles são publicados sob um nome especial, `_25._tcp.{host MX}`. Por isso, consultar o TLSA apenas no domínio nunca encontra nada.
  • "DANE não configurado" não é um erro. O DANE é uma camada adicional de defesa para a criptografia de e-mail, e a maioria dos servidores de e-mail ainda não o utiliza.
  • O DANE só é confiável se o próprio registro TLSA do domínio estiver protegido pela cadeia de assinaturas do DNSSEC. Mesmo que um registro TLSA seja encontrado, use também a ferramenta irmã "Verificador DNSSEC" para confirmar que o domínio tem o DNSSEC habilitado.
  • Quando um domínio tem vários hosts MX, esta ferramenta verifica até 3 hosts, começando pelo de menor número de preferência (maior prioridade).
  • Se os resolvedores divergirem, o registro pode ter sido atualizado recentemente e os caches ainda não sincronizaram. Aguarde um pouco e verifique novamente.

Perguntas frequentes

"DANE não configurado" por si só não é perigoso — a grande maioria dos servidores de e-mail ainda opera sem ele. Ainda assim, habilitá-lo vale a pena como defesa contra ataques man-in-the-middle ao STARTTLS, se essa opção estiver disponível.

Ambos visam forçar a criptografia TLS no transporte de e-mail, mas baseiam sua confiança de forma diferente: o MTA-STS depende da cadeia de validação de uma autoridade certificadora, enquanto o DANE depende da cadeia de assinaturas do DNSSEC. Se o DNSSEC já está habilitado, o DANE é uma escolha natural; caso contrário, o MTA-STS é o ponto de partida mais prático. Os dois também podem ser usados juntos.

Usage especifica o modelo de validação (se ainda é necessária a validação por CA ou se o certificado em si é fixado diretamente), Selector especifica se o hash é aplicado ao certificado completo ou apenas à chave pública, e Matching Type especifica o algoritmo de hash (como SHA-256 ou SHA-512). Combinações diferentes atendem a padrões operacionais diferentes.

Para proteção completa, todo host MX que possa ser escolhido como destino de entrega deveria ter um registro TLSA. Se apenas alguns hosts tiverem um, o e-mail entregue a um host sem registro não fica protegido.

Esta ferramenta verifica apenas um estado superficial: se um registro TLSA foi publicado. Ela não verifica se os dados de associação do certificado realmente correspondem ao certificado real do servidor, portanto use também uma ferramenta especializada se precisar de uma verificação rigorosa.
ツールくん

Curiosidade — Proteger a criptografia de e-mail com certificados, não apenas "evitar espionagem"

A criptografia de e-mail via SMTP (STARTTLS) tem uma fraqueza de longa data. A maioria dos servidores de e-mail usa TLS oportunista — voltando ao texto simples caso o outro lado não suporte criptografia —, o que abriu espaço para os "ataques STRIPTLS", nos quais um atacante man-in-the-middle remove silenciosamente o comando STARTTLS, fazendo a conexão ser rebaixada para texto simples sem que nenhum dos lados perceba.

O DANE (DNS-based Authentication of Named Entities, RFC 6698) responde a isso publicando registros TLSA no DNS. Ao fixar previamente no DNS o certificado de um servidor de e-mail (ou o hash de sua chave pública), o servidor remetente pode verificar se o host ao qual está se conectando realmente apresenta o certificado esperado. Diferentemente da validação comum de certificados SSL/TLS, o DANE não depende em nada da cadeia de confiança de uma autoridade certificadora — ele confia apenas na cadeia de assinaturas do DNSSEC.

A fraqueza do DANE é que ele só funciona se o próprio domínio estiver assinado com DNSSEC. Sem o DNSSEC, nada impede que o registro TLSA seja adulterado em trânsito, o que torna a garantia do DANE sem sentido. Por isso, a adoção do DANE acompanha de perto a do DNSSEC, tendo avançado mais cedo em alguns registros europeus (como .nl e .cz).