Certificados TLS falsos: como o DNS pode comprometer HTTPS

O ponto mais preocupante no caso não é apenas a emissão de certificados TLS falsos: é que um invasor conseguiu interferir na validação de domínio ao controlar temporariamente registros DNS. Segundo o Eurisko.com.br, que repercutiu a informação do Google, os domínios de nível superior .gh, .sl e .as foram comprometidos. A partir daí, os atacantes alteraram registros de domínios selecionados e obtiveram certificados não autorizados para sites de grandes empresas.

Na minha experiência, esse tipo de incidente expõe uma dependência que muitos times esquecem: a segurança de uma conexão HTTPS não depende só do servidor da aplicação. Ela também depende da cadeia de confiança que conecta o navegador, a autoridade certificadora, o DNS e o processo usado para provar quem controla um domínio.

O que aconteceu com os certificados TLS dos domínios .gh, .sl e .as

Um certificado TLS permite que o navegador valide a identidade de um site e negocie uma conexão criptografada. Quando você acessa https://exemplo.com, o servidor apresenta um certificado. O navegador confere, entre outros pontos, se ele foi emitido por uma autoridade certificadora confiável, se ainda está válido e se corresponde ao nome do domínio acessado.

Segundo o relato citado pelo Eurisko.com.br, os invasores assumiram o controle de três domínios de nível superior de código de país: .gh, de Gana; .sl, de Serra Leoa; e .as, da Samoa Americana. Depois, alteraram registros DNS autoritativos de domínios selecionados dentro dessas zonas.

Isso importa porque algumas autoridades certificadoras verificam o controle de um domínio por meio de desafios de DNS. Se o atacante consegue manipular a resposta DNS que a autoridade consulta, pode fazer a validação apontar para uma infraestrutura sob seu controle. O resultado pode ser a emissão de um certificado TLS válido para um domínio que o solicitante não deveria controlar.

Um certificado válido não significa que o site é confiável em todos os sentidos

HTTPS protege a conexão e ajuda a confirmar que o navegador está falando com o domínio indicado no certificado. Não prova que a empresa é honesta, que o conteúdo é seguro ou que o servidor não foi invadido. Também não impede, por si só, phishing em domínios parecidos, falhas na aplicação ou roubo de credenciais.

Quando um certificado fraudulento é aceito pelo navegador, o risco é mais específico: um intermediário que consiga interceptar o tráfego pode se apresentar como o domínio legítimo sem gerar o alerta que normalmente apareceria diante de um certificado inválido. Isso pode facilitar espionagem ou adulteração de dados, dependendo das condições do ataque. Não significa que todo usuário dos domínios afetados foi automaticamente interceptado.

Por que o DNS pode influenciar a emissão de certificados

O DNS transforma nomes legíveis, como api.exemplo.com, em informações usadas para localizar serviços. A hierarquia começa nos servidores raiz, passa pelos domínios de nível superior e chega aos servidores autoritativos da zona específica. Se uma parte dessa cadeia for comprometida, respostas DNS podem ser alteradas ou desviadas.

Uma autoridade certificadora precisa verificar que quem pede um certificado tem autorização sobre o domínio. Um método comum é publicar um valor temporário em um registro DNS, como um TXT, e pedir à autoridade que confira esse valor. Esse processo é útil para automação, mas depende de a consulta chegar à resposta autoritativa correta e de o solicitante realmente ter controle legítimo da zona.

Na prática, o incidente mostra que “a validação passou” não é uma garantia isolada. A confiança depende da integridade do mecanismo de validação e dos componentes que ele consulta. Um erro em um registrador ou em um registro de nível superior pode ter efeitos que vão além de um único servidor.

Validação por DNS, HTTP e CAA: o que cada mecanismo resolve

• Validação por DNS: permite provar controle publicando um desafio na zona. É prática para certificados automatizados e ambientes sem servidor web público, mas exige proteção rigorosa das credenciais DNS.
• Validação por HTTP: exige disponibilizar um desafio em uma URL do domínio. É simples para serviços web, mas pode ser inadequada quando a infraestrutura ainda não está acessível ou quando o roteamento está mal configurado.
• CAA: permite declarar quais autoridades certificadoras estão autorizadas a emitir certificados para um domínio. Ajuda a limitar emissores, mas não impede um emissor autorizado de cometer um erro nem substitui a segurança do DNS.

Esses mecanismos têm objetivos diferentes. CAA reduz a superfície de emissão, enquanto DNS e HTTP são métodos de validação. Nenhum deles, sozinho, substitui monitoramento, controle de acesso e resposta a incidentes.

O que desenvolvedores e equipes de infraestrutura devem revisar

Para quem mantém aplicações, o caso não exige pânico, mas justifica uma revisão objetiva. Comece pelo inventário: quais domínios e subdomínios existem, quem controla o DNS, quais autoridades emitem certificados e como a renovação está automatizada? Em muitas empresas, esse conhecimento está espalhado entre plataforma, redes, segurança e fornecedores externos.

Eu também revisaria quem pode alterar registros DNS e como essas alterações são auditadas. Contas de registrador com autenticação fraca, usuários antigos ainda ativos ou tokens de automação sem rotação aumentam o risco. Uma conta com permissão para mudar servidores autoritativos pode afetar não só a disponibilidade, mas também a identidade percebida pelos clientes.

Verifique certificados e configuração TLS com ferramentas disponíveis

O comando abaixo consulta o servidor, solicita o certificado apresentado e pede ao OpenSSL que verifique a cadeia e o nome do domínio. Troque o domínio pelo serviço que você administra. A opção -servername envia SNI, necessário em hospedagens que servem vários domínios no mesmo endereço IP.

DOMAIN="api.exemplo.com"

openssl s_client \
  -connect "${DOMAIN}:443" \
  -servername "${DOMAIN}" \
  -verify_hostname "${DOMAIN}" \
  -verify_return_error \
  </dev/null

# Consulte políticas CAA publicadas para o domínio
dig CAA "${DOMAIN}" +short

Uma verificação local não prova que o DNS ou a autoridade certificadora nunca foram comprometidos. Ela ajuda a detectar problemas comuns: nome incompatível, cadeia incompleta, certificado expirado ou ausência de uma política CAA esperada. Para acompanhar a emissão de certificados em escala, equipes também podem consultar os registros públicos de Certificate Transparency e configurar alertas para nomes da própria organização.

Na Prática: passo a passo para reduzir o risco

1. Inventarie os domínios. Inclua domínios principais, subdomínios, ambientes de teste e nomes ainda registrados por equipes antigas. Sem inventário, você não consegue monitorar emissões inesperadas.
2. Proteja a conta do registrador. Use autenticação multifator, limite usuários, remova acessos obsoletos e ative bloqueios contra transferências não autorizadas quando disponíveis.
3. Revise as permissões do DNS. Separe acesso de leitura e escrita, proteja tokens de automação e mantenha histórico de alterações. Uma conta de deploy não precisa necessariamente alterar toda a zona.
4. Publique CAA com cuidado. Autorize apenas as autoridades que sua organização realmente usa. Antes de restringir, confirme todos os fluxos de emissão, inclusive certificados de fornecedores e ambientes de contingência.
5. Monitore Certificate Transparency. Configure alertas para certificados emitidos para seus domínios. Isso pode revelar nomes inesperados ou emissores que não fazem parte do processo aprovado.
6. Defina um procedimento de resposta. Saiba quem contatar na autoridade certificadora, no registrador e no provedor DNS. Em um incidente, velocidade de revogação e comunicação faz diferença.

Não copie uma política CAA genérica sem testar. Se você bloquear uma autoridade necessária, a renovação automática pode falhar e derrubar um serviço quando o certificado expirar. O motivo de aplicar mudanças por etapas é simples: controles de segurança mal planejados também podem causar indisponibilidade.

Erros comuns ao lidar com certificados e DNS

• Tratar o cadeado como selo de segurança total. Ele indica uma conexão protegida e uma identidade validada segundo a cadeia de certificados. Não é uma auditoria da aplicação nem uma garantia de boa-fé.
• Ignorar o registrador porque “o DNS está no provedor”. A conta que controla o domínio pode permitir alterações nos servidores autoritativos. Proteja tanto o registrador quanto o serviço DNS.
• Confiar apenas na revogação de certificados. Navegadores e sistemas podem tratar mecanismos de revogação de maneiras diferentes, e a propagação nem sempre é imediata. Revogar é importante, mas prevenção e monitoramento também são necessários.
• Adicionar CAA sem mapear dependências. Uma regra restritiva pode impedir emissões legítimas. Levante primeiro quais emissores são usados por aplicações, CDN, hospedagem e serviços terceirizados.
• Usar certificados curingas sem avaliar o impacto. Um certificado para *.exemplo.com pode cobrir vários subdomínios de primeiro nível. Se a chave privada vazar, o impacto pode ser maior do que o de um certificado limitado a um único serviço.
• Guardar chaves privadas em repositórios ou imagens. Certificados podem ser públicos; chaves privadas, não. Armazene-as em um gerenciador de segredos ou serviço apropriado e planeje rotação.

O impacto para quem desenvolve aplicações web

Para um desenvolvedor, a principal lição é que HTTPS não começa no código da aplicação. A configuração de TLS pode estar correta no servidor e ainda depender de um processo de emissão vulnerável, de um DNS mal protegido ou de uma conta de registrador sem controles adequados.

Também vale evitar correções improvisadas no cliente. Desativar a validação de certificados para “resolver” um erro, aceitar qualquer certificado em código de integração ou instalar uma autoridade desconhecida como confiável remove justamente a proteção que o TLS deveria fornecer. Em testes, use certificados de desenvolvimento e autoridades locais controladas; em produção, mantenha a validação padrão habilitada.

Segundo o Eurisko.com.br, o Google informou que certificados não autorizados foram obtidos para domínios da empresa e de outras marcas. O caso reforça por que autoridades certificadoras, operadores de DNS e navegadores precisam trabalhar com monitoramento e resposta coordenados. Para nós, que construímos e operamos sistemas, a resposta prática é tratar certificados, DNS e identidade de domínio como parte da infraestrutura crítica.

Perguntas frequentes sobre certificados TLS falsos

Um certificado TLS falso permite ler qualquer conexão HTTPS?

Não automaticamente. O atacante também precisa conseguir interceptar ou redirecionar a conexão da vítima e apresentar o certificado fraudulento. Se isso ocorrer e o navegador confiar no certificado, a proteção de identidade pode ser contornada naquela conexão.

O que é validação de domínio para emissão de certificado?

É o processo pelo qual uma autoridade certificadora verifica se o solicitante controla o domínio. A validação pode usar um desafio DNS, um arquivo acessível por HTTP ou outro método aprovado. A segurança depende de o desafio ser verificado no domínio correto e de ninguém não autorizado controlar essa resposta.

CAA impede a emissão de certificados falsos?

CAA permite indicar quais autoridades certificadoras podem emitir certificados para um domínio. Isso reduz emissores possíveis, mas não impede falhas de uma autoridade autorizada nem protege uma zona DNS comprometida por si só.

Como posso saber se emitiram um certificado inesperado para meu domínio?

Monitore os registros públicos de Certificate Transparency e configure alertas para os nomes da sua organização. Combine isso com inventário de domínios e revisão periódica dos emissores usados. Um alerta só ajuda se alguém souber investigá-lo e responder.

Devo desativar HTTPS se houver suspeita de certificado comprometido?

Em geral, não. Desativar HTTPS remove criptografia e autenticação da conexão. O caminho é verificar o certificado, acionar a autoridade certificadora e os fornecedores envolvidos, substituir ou revogar certificados conforme necessário e comunicar os usuários quando houver risco confirmado.

Gostou? Me segue no GitHub e deixa um comentário se tiver dúvida ou quiser aprofundar algum ponto.