O Firefox é agora o primeiro e único navegador a implementar uma verificação rápida e abrangente de revogação de certificados que não revela sua atividade de navegação a ninguém (nem mesmo à Mozilla).
Dezenas de milhões de certificados de servidor TLS são emitidos todos os dias para proteger as comunicações entre navegadores e sites. Esses certificados são os pilares da criptografia onipresente e uma parte fundamental da nossa visão para a web. Embora um certificado possa ser válido por até 398 dias, ele também pode ser revogado a qualquer momento durante sua vida útil. Um certificado revogado representa um sério risco de segurança e não deve ser confiável para autenticar um servidor.
Identificar um certificado revogado é difícil porque as informações precisam fluir do emissor do certificado para cada navegador. Existem basicamente duas maneiras de lidar com isso. O navegador precisa perguntar a uma autoridade em tempo real sobre cada certificado que encontra ou precisa manter uma lista atualizada frequentemente de certificados revogados. O novo mecanismo do Firefox, CRLite, tornou esta última estratégia viável pela primeira vez.
Com o CRLite, o Firefox baixa periodicamente uma codificação compacta do conjunto de todos os certificados revogados que aparecem nos logs de Transparência de Certificados. O Firefox armazena essa codificação localmente, atualiza-a a cada 12 horas e consulta-a de forma privada sempre que uma nova conexão TLS é criada.
Você pode ter ouvido falar que a revogação foi quebrada ou que a revogação não funciona. Por muito tempo, a web ficou presa a escolhas ruins entre segurança, privacidade e confiabilidade neste espaço. Esse não é mais o caso. Habilitamos o CRLite para todos os usuários do Firefox desktop (Windows, Linux, MacOS) a partir do Firefox 137 e vimos que ele torna a verificação de revogação funcional, confiável e de alto desempenho. Temos esperança de poder replicar o nosso sucesso também noutros ambientes mais limitados.
Melhor privacidade e desempenho
Antes da versão 137, o Firefox usava o Online Certificate Status Protocol (OCSP) para perguntar às autoridades sobre o status de revogação em tempo real. As autoridades certificadoras já não são obrigadas a apoiar o OCSP, e algumas das principais autoridades certificadoras já anunciaram a sua intenção de encerrar os seus serviços OCSP. Existem vários motivos para isso, mas o principal é que o OCSP é um vazamento de privacidade. Quando um usuário solicita um certificado a um servidor OCSP, ele revela ao servidor que pretende visitar um determinado domínio. Como as solicitações OCSP normalmente são feitas em HTTP não criptografado, essas informações também vazam para todos os observadores no caminho.
Tendo ganhado confiança na robustez, precisão e desempenho de nossa implementação CRLite, desabilitaremos o OCSP para certificados validados por domínio no Firefox 142. Selar o vazamento de privacidade do OCSP complementa nossos esforços contínuos para criptografar tudo na Internet, implementando HTTPS-First, DNS sobre HTTPS e Cliente Criptografado Hello.
Desabilitar o OCSP também traz benefícios de desempenho: descobrimos que as solicitações OCSP bloqueiam o handshake TLS por 100 ms na mediana. À medida que implementamos o CRLite, vimos melhorias notáveis nos tempos de handshake do TLS.
Requisitos de largura de banda do CRLite
Os usuários com CRLite baixam em média 300 KB de dados de revogação por dia: um instantâneo de 4 MB a cada 45 dias e uma sequência de “atualizações delta” entre eles. (Os tamanhos exatos dos instantâneos e das atualizações delta variam dia a dia. Você pode explorar os dados reais em nosso painel.)
Para ter uma ideia de quão compactos são os artefatos CRLite, vamos compará-los com Listas de Revogação de Certificados (CRLs). Uma CRL é uma lista de números de série em que cada um identifica um certificado revogado de um único emissor. As autoridades certificadoras no armazenamento raiz da Mozilla divulgaram aproximadamente três mil CRLs ativas no Common CA Database. No total, essas três mil CRLs têm 300 MB e a única maneira de manter uma cópia delas atualizada é baixá-las novamente regularmente. CRLite codifica o mesmo conjunto dinâmico de certificados revogados em 300 KB por dia. Em outras palavras, CRLite é um mil vezes mais eficiente em termos de largura de banda do que downloads diários de CRL.
É claro que nenhum navegador realiza downloads diários de todas as CRLs. Para uma comparação mais significativa, podemos considerar os CRLSets do Chrome. Esses são conjuntos de revogações escolhidos a dedo e entregues diariamente aos usuários do Chrome. CRLSets recentes pesam 600 kB e incluem cerca de 1% de todas as revogações (trinta e cinco mil do total de quatro milhões). A implementação CRLite do Firefox usa metade da largura de banda, atualiza duas vezes mais frequentemente e inclui todos revogações.
Incluir todas as revogações é essencial para a segurança, pois atualmente não existe uma maneira confiável de distinguir as revogações críticas para a segurança das revogações administrativas. Aproximadamente metade de todas as revogações são feitas sem um código de razão especificado, e algumas dessas revogações são provavelmente devido a questões de segurança que o proprietário do certificado não quis destacar. Quando os códigos de motivo são usados, eles são frequentemente usados de uma forma ambígua que não mapeia claramente o risco de segurança. Neste ambiente, a única abordagem segura é verificar todas as revogações, o que agora é possível com o CRLite.
Tecnologia de lista de bloqueio de última geração
Você deve se lembrar de uma série de postagens de blog sobre nossos experimentos com CRLite em 2020. Seguimos esses experimentos com implantações bem-sucedidas para usuários Nightly, Beta e 1% dos usuários do Release. Mas os requisitos de largura de banda para esse projeto inicial do CRLite revelaram-se proibitivos.
Resolvemos nosso problema de largura de banda desenvolvendo uma nova estrutura de dados – o teste de adesão ao conjunto “Clubcard”. Enquanto o design original do CRLite usava “cascatas multiníveis de filtros Bloom”, o CRLite baseado em Clubcard usa uma “cascata particionada de dois níveis de filtros Ribbon”. A ideia da “cascata de dois níveis” foi apresentada por Mike Hamburg no RWC 2022, e o “particionamento” é uma inovação nossa que apresentamos em um artigo no IEEE S&P 2025 e em uma palestra no RWC 2025.
Melhorias futuras
Estamos trabalhando para tornar o CRLite ainda mais eficiente em termos de largura de banda. Estamos desenvolvendo novas estratégias de particionamento do Clubcard que irão comprimir eventos de revogação em massa de forma mais eficiente. Também estamos integrando suporte para transporte de dicionário de compactação HTTP, que compactará ainda mais as atualizações delta. E defendemos com sucesso períodos de validade de certificado mais curtos, o que reduzirá o número de artefatos CRLite que precisam codificar qualquer revogação. Com essas melhorias, esperamos que os requisitos de largura de banda do CRLite diminuam nos próximos anos, mesmo que o próprio ecossistema TLS continue a crescer.
Nossa biblioteca de lista de bloqueio Clubcard, nossa instanciação de Clubcards para CRLite e nosso backend CRLite estão disponíveis gratuitamente para qualquer pessoa usar. Esperamos que o nosso sucesso na construção de uma verificação de revogação rápida, privada e abrangente para o Firefox encoraje outros fornecedores de software a adotarem esta tecnologia.
Mais artigos de John Schanck…
