A empresa Mozilla sobre o início dos testes nas versões noturnas do Firefox do novo mecanismo de verificação de certificados revogados — . O CRLite permite organizar uma verificação eficaz dos certificados revogados usando uma base de dados hospedada no sistema do usuário. A implementação do CRLite desenvolvida na Mozilla é de código aberto sob a licença MPL 2.0. O código para gerar a base de dados e os componentes do servidor foram escritos em e Go. As partes do cliente adicionadas ao Firefox para leitura de dados da base de dados são escritas em Rust.
A verificação de certificados ainda utilizada, com a ajuda de serviços externos com base no protocolo (Online Certificate Status Protocol), requer acesso de rede garantido, resulta em um atraso perceptível no processamento da solicitação (em média 350 ms) e apresenta problemas de privacidade (os servidores que respondem às solicitações OCSP recebem informações sobre certificados específicos, permitindo inferir quais sites o usuário está acessando). Também existe a possibilidade de verificação local utilizando listas (Certificate Revocation List), mas a desvantagem desse método é o grande tamanho dos dados a serem baixados — atualmente, a base de dados de certificados revogados ocupa cerca de 300 MB e continua a crescer.
Para bloquear certificados comprometidos e revogados por autoridades certificadoras, o Firefox usa uma lista negra centralizada desde 2015 em conjunto com o serviço para detectar possíveis atividades maliciosas. O OneCRL, assim como no Chrome, atua como um intermediário que agrega listas CRL de autoridades certificadoras e fornece um serviço OCSP centralizado para verificar certificados revogados, possibilitando que não sejam enviadas solicitações diretamente para as autoridades certificadoras. Apesar do grande trabalho para aumentar a confiabilidade do serviço de verificação online de certificados, dados de telemetria mostram que mais de 7% das solicitações OCSP terminam em timeout (alguns anos atrás, essa taxa era de 15%).
Por padrão, se a verificação via OCSP não puder ser realizada, o navegador considera o certificado como válido. O serviço pode ficar indisponível devido a problemas de rede ou restrições em redes internas, ou pode ser bloqueado por atacantes — para contornar a verificação OCSP durante um ataque MITM, basta bloquear o acesso ao serviço de verificação. Parte da prevenção contra esses ataques é tecnicamente implementada. , permitindo interpretar um erro de solicitação ao OCSP ou a indisponibilidade do OCSP como um problema com o certificado, mas essa possibilidade é opcional e requer um tipo especial de certificado.
O CRLite permite compilar informações completas sobre todos os certificados revogados em uma estrutura facilmente atualizável, com apenas 1 MB, possibilitando armazenar todo o banco de dados de CRL no lado do cliente.
O navegador poderá sincronizar diariamente sua cópia dos dados dos certificados revogados, e esse banco de dados estará disponível sob quaisquer condições.
O CRLite combina informações de , um log público de todos os certificados emitidos e revogados, e os resultados da varredura de certificados na internet (são coletadas diferentes listas CRL de autoridades certificadoras e é agregada informação sobre todos os certificados conhecidos). Os dados são compactados usando estruturas , de probabilidade que permitem a falsa identificação de elementos ausentes, mas excluem a omissão de elementos existentes (ou seja, com uma certa probabilidade, pode haver um falso positivo para um certificado válido, mas os certificados revogados serão garantidamente identificados).
Para eliminar falsos positivos no CRLite, foram introduzidos níveis de correção adicionais de filtragem. Após a geração da estrutura, ocorre uma varredura de todos os registros originais para identificar os falsos positivos. Com base nos resultados dessa verificação, é criada uma estrutura adicional que se sobrepõe à primeira e corrige os falsos positivos. A operação é repetida até que os falsos positivos sejam completamente eliminados na verificação de controle. Normalmente, para cobrir todos os dados, é suficiente criar de 7 a 10 camadas. Como o estado do banco de dados, devido à sincronização periódica, fica um pouco defasado em relação ao estado atual do CRL, a verificação de novos certificados emitidos após a última atualização do banco de dados CRLite é realizada através do protocolo OCSP, incluindo técnicas de (a resposta OCSP autenticada pelo centro certificador é transmitida pelo servidor que atende o site durante o estabelecimento da conexão TLS).
Com o uso de filtros de Bloom, o corte de informações de dezembro do WebPKI, cobrindo 100 milhões de certificados ativos e 750 mil certificados revogados, foi compactado em uma estrutura de 1,3 MB. O processo de geração da estrutura é bastante intensivo em recursos, mas é realizado no servidor da Mozilla, e o usuário recebe uma atualização pronta. Por exemplo, em forma binária, os dados usados na geração requerem cerca de 16 GB de memória quando armazenados no banco de dados Redis, e em forma hexadecimal, o dump de todos os números de série dos certificados ocupa cerca de 6,7 GB. O processo de agregação de todos os certificados revogados e ativos leva cerca de 40 minutos, enquanto o processo de geração da estrutura compactada baseada no filtro de Bloom leva mais 20 minutos.
Atualmente, a Mozilla garante a atualização do banco de dados CRLite 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 — a aplicação do bsdiff4, que é utilizado para criar atualizações delta de lançamentos, não oferece a eficiência necessária para o CRLite, resultando em atualizações injustificavelmente grandes. Para resolver essa deficiência, está previsto uma reestruturação do formato de armazenamento para evitar reestruturações desnecessárias e a remoção de camadas.
O CRLite atualmente funciona no Firefox em modo passivo e é utilizado em paralelo com o OCSP para coletar estatísticas sobre a precisão do funcionamento. O CRLite pode ser alterado para o modo de verificação principal, para isso, é necessário definir o parâmetro security.pki.crlite_mode = 2 em about:config.
Fonte: opennet.ru
