Quando um certificado se torna não confiável, esse certificado deve ser revogado e essa informação divulgada para que ninguém confie nele no futuro
Por Adriano Frare
Este mês, a Let’s Encrypt está ativando uma nova infraestrutura para dar suporte à revogação de certificados por meio de Listas de Revogação de Certificados.
Apesar de ter sido amplamente suplantado pelo Online Certificate Status Protocol há mais de uma década, as CRLs estão ganhando nova vida com as recentes atualizações do navegador.
Ao coletar e resumir CRLs para seus usuários, os navegadores estão tornando a revogação confiável de certificados uma realidade, melhorando a segurança e a privacidade na web.
Vamos falar exatamente sobre o que essa nova infraestrutura faz e por que ela é importante.
Uma Breve História da Revogação
Quando um certificado se torna não confiável (por exemplo, porque sua chave privada foi comprometida), esse certificado deve ser revogado e essa informação divulgada para que ninguém confie nele no futuro.
No entanto, é um ditado muito usado no mundo da Web Public Key Infrastructure (a Web PKI) que a revogação está quebrada.
Ao longo da história da Web PKI, houve dois mecanismos principais para declarar que um certificado TLS/SSL não deve mais ser confiável: Listas de Revogação de Certificados (CRLs) e o Online Certificate Status Protocol (OCSP). Infelizmente, ambos têm grandes desvantagens.
As CRLs são basicamente apenas listas de todos os certificados que uma determinada Autoridade de Certificação (CA) emitiu e que foram revogados.
Isso significa que eles geralmente são muito grandes – facilmente do tamanho de um filme inteiro.
É ineficiente para o seu navegador baixar uma lista gigantesca de certificados revogados apenas para verificar se o único certificado do site que você está visitando agora foi revogado.
Esses downloads e verificações lentos tornaram o carregamento de páginas da Web lento, então o OCSP foi desenvolvido como uma alternativa.
O OCSP é como “e se houvesse uma CRL separada para cada certificado”: quando você deseja verificar se um determinado certificado foi revogado, seu navegador pode verificar o status de apenas um certificado entrando em contato com o serviço OCSP da CA.
Mas como a infraestrutura OCSP precisa estar em execução constante e pode sofrer inatividade como qualquer outro serviço da Web, a maioria dos navegadores trata a ausência de resposta como equivalente a obter uma resposta “não revogada”.
Isso significa que os invasores podem impedir que você descubra que um certificado foi revogado simplesmente bloqueando todas as suas solicitações de informações OCSP.
Para ajudar a reduzir a carga nos serviços OCSP de uma CA, as respostas OCSP são válidas e podem ser armazenadas em cache por cerca de uma semana.
Mas isso significa que os clientes não recuperam atualizações com muita frequência, e muitas vezes continuam a confiar em certificados por uma semana depois de revogados.
E talvez o pior de tudo: como seu navegador faz uma solicitação OCSP para cada site que você visita, uma CA maliciosa (ou legalmente obrigada) pode rastreie seu comportamento de navegação acompanhando os sites para os quais você solicita o OCSP.
Portanto, ambas as soluções existentes realmente não funcionam: as CRLs são tão ineficientes que a maioria dos navegadores não as verifica, e o OCSP é tão pouco confiável que a maioria dos navegadores não as verifica. Precisamos de algo melhor.
CRLs resumidas do navegador
Uma possível solução que vem avançando recentemente é a ideia de CRLs proprietárias e específicas para navegadores. Embora diferentes navegadores estejam implementando isso de forma diferente (por exemplo, Mozilla chama o seu CRLite e o Chrome é CRLSets ), a ideia básica é a mesma.
Em vez de fazer com que o navegador de cada usuário baixe CRLs grandes quando quiser verificar a revogação, o fornecedor do navegador baixa as CRLs centralmente.
Eles processam as CRLs em um formato menor, como um filtro Bloom e, em seguida, enviam o novo objeto compactado para todas as instâncias do navegador instaladas usando mecanismos de atualização rápida pré-existentes. O Firefox, por exemplo, está enviando atualizações a cada 6 horas.
Isso significa que os navegadores podem baixar listas de revogação com antecedência, mantendo o carregamento da página rápido e mitigando os piores problemas de CRLs vanilla.
Ele mantém as verificações de revogação locais, e as atualizações enviadas podem ter efeito imediato sem esperar que um cache OCSP com duração de alguns dias expire, evitando todos os piores problemas com o OCSP.
Graças à promessa dessas CRLs resumidas do navegador, os programas raiz da Apple e da Mozilla estão exigindo que todas as CAs comecem a emitir CRLs antes de 1º de outubro de 2022.
Especificamente, eles estão exigindo que as CAs comecem a emitir uma ou mais CRLs que, juntas, cobrem todos os certificados emitido por essa AC, e que a lista de URLs que apontam para essas CRLs seja divulgada no Common CA Database (CCADB). Isso permitirá que o Safari e o Firefox passem a usar a verificação de revogação da CRL resumida do navegador.
Nossa Nova Infraestrutura
Quando a Let’s Encrypt foi fundada, tomamos uma decisão explícita de oferecer suporte apenas ao OCSP e não produzir CRLs.
Isso ocorreu porque os requisitos do programa raiz na época exigiam apenas o OCSP, e a manutenção de ambos os mecanismos de revogação aumentaria o número de locais onde um bug poderia levar a um incidente de conformidade.
Quando nos propusemos a desenvolver a infraestrutura CRL, sabíamos que precisávamos construir para escala e fazê-lo de uma maneira que refletisse nossa ênfase em eficiência e simplicidade.
Nos últimos meses, desenvolvemos algumas novas peças de infraestrutura para nos permitir publicar CRLs em conformidade com os requisitos futuros.
Cada componente é leve, dedicado a realizar uma única tarefa e fazê-la bem, e será capaz de dimensionar muito além de nossas necessidades atuais.
A Let’s Encrypt atualmente tem mais de 200 milhões de certificados ativos em qualquer dia. Se tivéssemos um incidente em que precisássemos revogar cada um desses certificados ao mesmo tempo, a CRL resultante seria superior a 8 gigabytes.
Para tornar as coisas menos complicadas, dividiremos nossas CRLs em 128 fragmentos, cada um chegando ao máximo de 70 megabytes no pior caso.
Usamos uma matemática cuidadosamente construída para garantir que – contanto que o número de estilhaços não mude – todos os certificados permaneçam dentro de seus mesmos estilhaços quando as CRLs forem reemitidas, para que cada estilhaço possa ser tratado como uma mini-CRL com alcance consistente.
De acordo com as mesmas práticas recomendadas que seguimos para a emissão de nossos certificados, todas as nossas CRLs serão verificadas quanto à conformidade com a RFC 5280 e os Requisitos de Linha de Base antes de serem assinadas por nossos intermediários emissores.
Embora a popular biblioteca de linting zlint ainda não suporte CRLs de linting, escrevemos nossa própria coleção de verificações e esperamos fazer o upstream delas para zlint no futuro.
Essas verificações ajudarão a evitar incidentes de conformidade e garantirão um ciclo contínuo de emissão e renovação.
Como parte do desenvolvimento desses novos recursos, também fizemos várias melhorias na implementação da biblioteca padrão Go de geração e análise de CRL.
Esperamos contribuir com mais melhorias à medida que nós e o restante da comunidade Go trabalharmos com CRLs com mais frequência no futuro.
Embora estejamos produzindo CRLs que cobrem todos os certificados que emitimos, não incluiremos esses URLs na extensão CRL Distribution Point de nossos certificados.
Por enquanto, conforme exigido pelos Requisitos de Linha de Base, nossos certificados continuarão a incluir um URL OCSP que pode ser usado por qualquer pessoa para obter informações de revogação para cada certificado.
Nossos novos URLs de CRL serão divulgados apenas no CCADB, para que os programas raiz da Apple e Mozilla possam consumi-los sem expô-los a tráfego de download potencialmente grande do resto da Internet em geral.
O Futuro da Revogação
Ainda há um longo caminho a percorrer antes que a revogação na Web PKI seja realmente corrigida. As preocupações com a privacidade em torno do OCSP só serão mitigadas quando todos os clientes pararem de confiar nele, e ainda precisamos desenvolver boas maneiras para clientes não navegadores verificarem de forma confiável as informações de revogação.
Esperamos continuar trabalhando com o restante da comunidade Web PKI para tornar a verificação de revogação privada, confiável e eficiente para todos.
Se você está animado com nosso trabalho desenvolvendo mecanismos de revogação mais robustos e privados, você pode nos apoiar com uma doação ou incentivar sua empresa ou organização a patrocinar nosso trabalho. Como um projeto sem fins lucrativos, 100% de nosso financiamento vem de contribuições de nossa comunidade e apoiadores, e dependemos do seu apoio.
Monitoramento da Expiração do Certificado em SSL – Por Adriano Frare
Rússia cria sua própria Autoridade Certificadora
Apple – Atualiza de suspensão de uso do TLS 1.0 e 1.1. Por Adriano Frare
Sobre Certificados Digitais do Tipo A1 e LCR – pequenas considerações
Sobre o Adriano V.L. Frare
Adriano V.L. Frare é graduado em Bacharelado em Matemática com ênfase em Processamento de Dados FSA – Centro Universitário Fundação Santo André, com curso de especialização na Universidade de Stanford na área de criptografia, detém certificações internacionais em ITIL, Ethical Hacking, LPI Linux Security e CISSP.
Nos últimos 15 anos vem desenvolvendo projetos na área de segurança da informação e certificação digital, onde trabalhou na iniciativa pública e privada.
Leia outros artigos de Adriano. Acesse aqui!
