La compañía Mozilla sobre el inicio de las pruebas en las compilaciones nocturnas de Firefox de un nuevo mecanismo para determinar los certificados revocados — . CRLite permite organizar una verificación eficiente de la revocación de certificados a través de una base de datos alojada en el sistema del usuario. La implementación de CRLite que se desarrolla en Mozilla bajo la licencia MPL 2.0. El código para generar la base de datos y los componentes del servidor están escritos en y Go. Las partes del cliente añadidas a Firefox para leer datos de la base de datos están en el lenguaje Rust.
La verificación de certificados que todavía se aplica, utilizando servicios externos basados en el protocolo (Online Certificate Status Protocol) requiere acceso a una red garantizada, provoca un retraso significativo en el procesamiento de la solicitud (en promedio 350 ms) y tiene problemas de privacidad (los servidores OCSP que responden a las solicitudes reciben información sobre certificados específicos, lo que permite inferir qué sitios está visitando el usuario). También existe la posibilidad de verificación local a través de listas (Certificate Revocation List), pero la desventaja de este método es el gran tamaño de los datos a cargar — actualmente la base de datos de certificados revocados ocupa alrededor de 300 MB y sigue creciendo.
Para bloquear certificados comprometidos y revocados por las autoridades de certificación, Firefox ha estado utilizando una lista negra centralizada junto con el servicio para identificar posibles actividades maliciosas. OneCRL, al igual que en Chrome, actúa como un eslabón intermedio que agrega listas CRL de las autoridades de certificación y proporciona un servicio OCSP centralizado para la verificación de certificados revocados, lo que permite no enviar solicitudes directamente a las autoridades de certificación. A pesar del gran trabajo realizado para aumentar la fiabilidad del servicio de verificación de certificados en línea, los datos de telemetría muestran que más del 7% de las solicitudes OCSP finalizan en tiempo de espera (hace unos años, esta cifra era del 15%).
Por defecto, si no se puede realizar la verificación a través de OCSP, el navegador considera que el certificado es válido. El servicio puede estar inactivo debido a problemas de red y restricciones en redes internas, o puede ser bloqueado por atacantes; para eludir la verificación de OCSP en un ataque MITM, basta con bloquear el acceso al servicio de verificación. En parte, para prevenir ataques de este tipo se implementa la técnica , que permite interpretar el error en la consulta a OCSP o la inaccesibilidad de OCSP como un problema con el certificado, pero esta opción es opcional y requiere un formato especial del certificado.
CRLite permite consolidar información completa sobre todos los certificados revocados en una estructura fácilmente actualizable de solo 1 MB, lo que permite mantener una base completa de CRL del lado del cliente.
El navegador podrá sincronizar diariamente su copia de los datos sobre certificados revocados, y esta base de datos estará disponible en cualquier condición.
CRLite combina información de , un registro público de todos los certificados emitidos y revocados, y los resultados de escaneo de certificados en Internet (se recopilan diversas listas CRL de autoridades de certificación y se agrega información sobre todos los certificados conocidos). Los datos se empaquetan utilizando estructuras en cascada , una estructura probabilística que permite determinar erróneamente la ausencia de un elemento, pero excluye la omisión de un elemento existente (es decir, hay cierta probabilidad de un falso positivo en un certificado válido, pero los certificados revocados serán detectados garantizadamente).
Para evitar falsas alarmas en CRLite se han introducido niveles de ajuste adicionales en el filtro. Después de la generación de la estructura, se lleva a cabo una revisión de todos los registros originales y se determina la aparición de falsas alarmas. A partir de esta verificación, se crea una estructura adicional que se superpone a la primera y corrige las falsas alarmas generadas. La operación se repite hasta que las falsas alarmas en la revisión de control se eliminen por completo. Generalmente, la creación de 7 a 10 capas es suficiente para cubrir todos los datos. Dado que el estado de la base de datos, debido a la sincronización periódica, está un poco desfasado respecto al estado actual de CRL, la verificación de nuevos certificados emitidos después de la última actualización de la base de datos CRLite se realiza mediante el protocolo OCSP, incluyendo el uso de la técnica (la respuesta OCSP certificada por una autoridad de certificación se entrega al servidor que atiende el sitio durante el establecimiento de la conexión TLS).
Con el uso de filtros de Bloom, el corte de información de diciembre de WebPKI, que abarca 100 millones de certificados activos y 750 mil certificados revocados, se logró empaquetar en una estructura de 1.3 MB. El proceso de generación de la estructura es bastante intensivo en recursos, pero se realiza en el servidor de Mozilla y se envía al usuario una actualización ya lista. Por ejemplo, en forma binaria, los datos originales utilizados durante la generación requieren alrededor de 16 GB de memoria cuando se almacenan en la base de datos Redis, y en formato hexadecimal, el volcado de todos los números de serie de los certificados ocupa alrededor de 6.7 GB. El proceso de agregación de todos los certificados revocados y activos toma alrededor de 40 minutos, y el proceso de generación de la estructura empaquetada basada en el filtro de Bloom requiere otros 20 minutos.
En la actualidad, Mozilla proporciona actualizaciones de la base de datos CRLite cuatro veces al día (no todas las actualizaciones se envían a los clientes). La generación de actualizaciones delta aún no se ha implementado; el uso de bsdiff4, que se utiliza para crear actualizaciones delta de lanzamientos, no proporciona la eficiencia adecuada para CRLite y las actualizaciones resultan ser injustificadamente grandes. Para solucionar esta desventaja, se planea rehacer el formato de almacenamiento para evitar reestructuraciones innecesarias y eliminación de capas.
CRLite ahora funciona en Firefox en modo pasivo y se utiliza junto con OCSP para acumular estadísticas sobre la corrección de su funcionamiento. CRLite se puede cambiar a modo de verificación principal; para ello, en about:config, debe establecer el parámetro security.pki.crlite_mode = 2.
Fuente: opennet.ru
