Acabei de começar a usar o Let's Encrypt. O desafio http-01 é bastante simples:
- Faça um servidor web responder ahttp://exemplo.com
- Peça ao Let's Encrypt um arquivo de desafio
- Forneça o arquivo abaixohttp://example.com/.well-known/acme-challenge
- Receba o certificado TLS para example.com
Funciona como um encanto. Mas como eles podem ter certeza de que sou realmente o proprietário de example.com usando uma conexão http insegura?
Algum administrador do meu data center (ou do meu ISP) não poderia simplesmente solicitar um certificado e interceptar as solicitações http que o Let's Enrypt envia para verificar a identidade do servidor?
Responder1
Na verdade, não existe proteção infalível contra um ataque man-in-the-middle para o desafio HTTP-01.
Alguém que possa interceptar o tráfego entre os nós de validação do Let's Encrypt e seu servidor PODE passar no desafio e obter um certificado emitido. Se eles conseguirem usar os truques do BGP, eles podem não estar necessariamente no meio, no sentido normal.
Isso se aplica ao desafio HTTP-01 e, para domínios não assinados, também ao desafio DNS-01.
Vale ressaltar que esse problema não é exclusivo do Lets Encrypt, a validação feita por CAs tradicionais para certificados DV geralmente apresenta o mesmo problema; eles normalmente oferecem opções de validação de HTTP, DNS e e-mail, todas suscetíveis a ataques MITM.
O queVamos criptografartemfeito para mitigar o problema, é executar cada validação de vários nós de teste em data centers diferentes, exigindo que todos os resultados do teste estejam de acordo para emitir o certificado. (O que eu suspeito que os torna menos suscetíveis a este tipo de abuso do que a maioria dos CAs tradicionais.)
Isto pelo menos reduz o escopo de quem pode estar no "meio", já que grandes partes do "meio" serão diferentes conforme visto. dos diferentes nós de teste.
Trata-se do comportamento padrão da validação automatizada de domínio da Let's Encrypt (e das CAs em geral), mas o proprietário do domínio recebeu algum controle adicional com a exigência de que as CAs públicas verifiquem CAA
os registros.
Para realmente assumir o controle, o proprietário do domínio pode seguir estas etapas:
- Assine DNSSEC na zona para garantir que os
CAA
dados não sejam adulterados
(também protege o próprio desafio no caso de DNS-01) - Adicione um ou mais
CAA
registros para limitar a emissão de certificados
(particularmenteCAA
registros que não apenas nomeiam a CA que tem permissão para emitir, mas também qual conta com essa CA que tem permissão)
Com um CAA
registro parecido com isto:
example.com. IN CAA 0 issue "letsencrypt.org; accounturi=https://acme-v02.api.letsencrypt.org/acme/acct/12346789"
o problema é muito reduzido, pois um impostor não pode iniciar o desafio trivialmente.
Preste atenção especial ao accounturi
parâmetro nos CAA
dados, é isso que torna a política específica para a conta do proprietário do domínio com a CA especificada.
Um CAA
registro que especifique apenas a CA, mas não uma conta, embora válido, seria de ajuda limitada, pois tal política ainda permite que qualquer outro cliente dessa CA solicite a emissão de certificados.
Responder2
Justificativa para usar httpao obter o desafio HTTP-01 está na especificação:
Como muitos servidores Web alocam um host virtual HTTPS padrão para um determinado usuário locatário de baixo privilégio de maneira sutil e não intuitiva, o desafio deve ser concluído por HTTP, não por HTTPS.
Este desafio é diferente das mensagens do protocolo ACME. A especificação exige https. A ACME também possuiintegridadeerepetirproteções em suas mensagens assinadas. Mesmo que o tráfego tenha sido capturado, há mais coisas para comprometê-lo do que apenas o desafio não criptografado. É claro que há algum risco nisso, mas qual é a alternativa para um melhor procedimento de verificação de domínio?
Uma abordagem mais completa ao monitoramento de certificados não autorizados pode envolver a transparência dos certificados. Pesquise ou configure alertas em registros de CT para seus nomes. A emissão da CA, o número de série e a data devem ser familiares.