Como o Let's Encrypt pode verificar a identidade em http inseguro?

Como o Let's Encrypt pode verificar a identidade em http inseguro?

Acabei de começar a usar o Let's Encrypt. O desafio http-01 é bastante simples:

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 CAAos registros.

Para realmente assumir o controle, o proprietário do domínio pode seguir estas etapas:

  1. Assine DNSSEC na zona para garantir que os CAAdados não sejam adulterados
    (também protege o próprio desafio no caso de DNS-01)
  2. Adicione um ou mais CAAregistros para limitar a emissão de certificados
    (particularmente CAAregistros 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 CAAregistro 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 accounturiparâmetro nos CAAdados, é isso que torna a política específica para a conta do proprietário do domínio com a CA especificada.
Um CAAregistro 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.

informação relacionada