Mozilla Company
Verificação de certificado usando serviços externos baseados no protocolo que ainda é usado
Para bloquear certificados que foram comprometidos e revogados pelas autoridades de certificação, o Firefox usa uma lista negra centralizada desde 2015
Por padrão, caso não seja possível verificar via OCSP, o navegador considera o certificado válido. O serviço pode estar indisponível devido a problemas de rede e restrições nas redes internas, ou bloqueado por invasores - para contornar a verificação OCSP durante um ataque MITM, basta bloquear o acesso ao serviço de verificação. Parcialmente para prevenir tais ataques, uma técnica foi implementada
O CRLite permite consolidar informações completas sobre todos os certificados revogados em uma estrutura de fácil atualização, de apenas 1 MB, o que possibilita armazenar um banco de dados CRL completo no lado do cliente.
O navegador poderá sincronizar diariamente sua cópia dos dados sobre certificados revogados, e esse banco de dados estará disponível sob quaisquer condições.
CRLite combina informações de
Para eliminar falsos positivos, o CRLite introduziu níveis de filtro corretivos adicionais. Após a geração da estrutura, todos os registros de origem são pesquisados e eventuais falsos positivos são identificados. Com base nos resultados desta verificação, é criada uma estrutura adicional, que é cascata sobre a primeira e corrige os falsos positivos resultantes. A operação é repetida até que os falsos positivos durante a verificação do controle sejam completamente eliminados. Normalmente, a criação de 7 a 10 camadas é suficiente para cobrir completamente todos os dados. Como o estado do banco de dados, devido à sincronização periódica, fica um pouco atrás do estado atual da CRL, a verificação dos novos certificados emitidos após a última atualização do banco de dados CRLite é realizada utilizando o protocolo OCSP, inclusive utilizando o
Usando filtros Bloom, a fatia de informações de dezembro do WebPKI, cobrindo 100 milhões de certificados ativos e 750 mil certificados revogados, pôde ser compactada em uma estrutura de 1.3 MB. O processo de geração da estrutura consome bastante recursos, mas é realizado no servidor Mozilla e o usuário recebe uma atualização pronta. Por exemplo, no formato binário, os dados de origem usados durante a geração requerem cerca de 16 GB de memória quando armazenados no DBMS Redis e, no formato hexadecimal, um despejo de todos os números de série do certificado leva cerca de 6.7 GB. O processo de agregação de todos os certificados revogados e ativos leva cerca de 40 minutos, e o processo de geração de uma estrutura de pacote baseada no filtro Bloom leva mais 20 minutos.
Atualmente, a Mozilla garante que o banco de dados CRLite seja atualizado quatro vezes ao dia (nem todas as atualizações são entregues aos clientes). A geração de atualizações delta ainda não foi implementada - o uso do bsdiff4, usado para criar atualizações delta para lançamentos, não fornece eficiência adequada para CRLite e as atualizações são excessivamente grandes. Para eliminar esta desvantagem, está planejado retrabalhar o formato da estrutura de armazenamento para eliminar reconstruções desnecessárias e exclusão de camadas.
O CRLite atualmente funciona no Firefox em modo passivo e é usado em paralelo com o OCSP para acumular estatísticas sobre o correto funcionamento. O CRLite pode ser alternado para o modo de varredura principal; para fazer isso, você precisa definir o parâmetro security.pki.crlite_mode = 2 em about:config.
Fonte: opennet.ru