Nota traductor: para comodidad de los lectores, las fechas se dan en la hora de Moscú
Recientemente se nos pasó la caducidad de uno de los certificados utilizados para firmar complementos. Esto resultó en que los complementos se deshabilitaran para los usuarios. Ahora que el problema se ha solucionado en su mayor parte, me gustaría compartir los detalles de lo que sucedió y el trabajo que se realizó.
Antecedentes: adiciones y firmas
Los complementos instalados deben tener firma digital, que protege a los usuarios de complementos maliciosos y requiere una revisión mínima de los complementos por parte del personal de Mozilla. Introdujimos este requisito en 2015 porque estábamos experimentando problemas serios con complementos maliciosos.
Cómo funciona: Cada copia de Firefox contiene un "certificado raíz". La clave de esta “raíz” se almacena en Módulo de seguridad de hardware (HSM)sin acceso a la red. Cada pocos años, se firma un nuevo "certificado intermedio" con esta clave, que se utiliza al firmar complementos. Cuando un desarrollador envía un complemento, creamos un "certificado final" temporal y lo firmamos utilizando un certificado intermedio. Luego, el complemento en sí se firma con el certificado final. Esquemáticamente se parece a esto.
Tenga en cuenta que cada certificado tiene un "sujeto" (a quien se emitió el certificado) y un "emisor" (que emitió el certificado). En el caso de un certificado raíz, "sujeto" = "emisor", pero para otros certificados, el emisor del certificado es el sujeto del certificado principal por el que está firmado.
Un punto importante: cada complemento está firmado por un certificado final único, pero casi siempre estos certificados finales están firmados por el mismo certificado intermedio.
Nota del autor: La excepción son las adiciones muy antiguas. En aquella época se utilizaban varios certificados intermedios.
Este certificado intermedio causó problemas: cada certificado es válido por un período determinado. Antes o después de este período, el certificado no es válido y el navegador no utilizará complementos firmados por este certificado. Lamentablemente, el certificado intermedio expiró el 4 de mayo a las 4 am.
Las consecuencias no aparecieron de inmediato. Firefox no comprueba constantemente las firmas de los complementos instalados, sino aproximadamente una vez cada 24 horas, y el tiempo de verificación es individual para cada usuario. Como resultado, algunas personas experimentaron problemas inmediatamente, mientras que otras los experimentaron mucho más tarde. Nos dimos cuenta del problema por primera vez cuando expiró el certificado e inmediatamente comenzamos a buscar una solución.
Reducir el daño
Una vez que nos dimos cuenta de lo sucedido, intentamos evitar que la situación empeorara.
En primer lugar, dejaron de aceptar y fichar nuevas incorporaciones. No tiene sentido utilizar un certificado caducado para ello. Mirando hacia atrás, diría que podríamos haber dejado todo como estaba. Ahora hemos reanudado la aceptación de suplementos.
En segundo lugar, enviaron inmediatamente una solución que impedía comprobar las firmas a diario. Así, salvamos a aquellos usuarios cuyo navegador aún no había tenido tiempo de comprobar los complementos en las últimas XNUMX horas. Esta solución ya se ha retirado y ya no es necesaria.
Operación paralela
En teoría, la solución al problema parece simple: crear un nuevo certificado intermedio válido y volver a firmar cada complemento. Desafortunadamente esto no funcionará:
- No podemos volver a firmar rápidamente 15 mil complementos a la vez, el sistema no está diseñado para tal carga.
- Después de firmar las adiciones, las versiones actualizadas deben entregarse a los usuarios. La mayoría de los complementos se instalan desde los servidores de Mozilla, por lo que Firefox encontrará actualizaciones dentro de las próximas XNUMX horas, pero algunos desarrolladores distribuyen complementos firmados a través de canales de terceros, por lo que los usuarios tendrían que actualizar dichos complementos manualmente.
En lugar de ello, intentamos desarrollar una solución que llegara a todos los usuarios sin requerir mucha o ninguna acción de su parte.
Muy rápidamente llegamos a dos estrategias principales, que utilizamos en paralelo:
- Actualice Firefox para cambiar el período de validez del certificado. Esto hará que los complementos existentes vuelvan a funcionar mágicamente, pero requerirá lanzar y enviar una nueva versión de Firefox.
- Genere un certificado válido y de alguna manera convenza a Firefox para que lo acepte en lugar del existente que ha caducado
Decidimos utilizar primero la primera opción, que parecía bastante viable. Al final del día, lanzaron una segunda solución (un nuevo certificado), de la que hablaremos más adelante.
Reemplazo de un certificado
Como mencioné anteriormente, se requería:
- crear un nuevo certificado válido
- instalarlo de forma remota en Firefox
Para entender por qué funciona esto, echemos un vistazo más de cerca al proceso de verificación de complementos. El complemento en sí viene como un conjunto de archivos, incluida una cadena de certificados utilizados para firmar. Como resultado, el complemento se puede verificar si el navegador conoce el certificado raíz, que está integrado en Firefox en el momento de la compilación. Sin embargo, como ya sabemos, el certificado intermedio ha caducado, por lo que es imposible verificar el complemento.
Cuando Firefox intenta verificar un complemento, no se limita a utilizar los certificados contenidos en el propio complemento. En cambio, el navegador intenta crear una cadena de certificados válida, comenzando con el certificado final y continuando hasta llegar a la raíz. En el primer nivel, comenzamos con el certificado final y luego buscamos el certificado cuyo sujeto es el emisor del certificado final (es decir, el certificado intermedio). Normalmente, este certificado intermedio se proporciona con el complemento, pero cualquier certificado del almacenamiento del navegador también puede servir como certificado intermedio. Si podemos agregar de forma remota un nuevo certificado válido al almacén de certificados, Firefox intentará usarlo. La situación antes y después de instalar un nuevo certificado..
Después de instalar el nuevo certificado, Firefox tendrá dos opciones al validar la cadena de certificados: usar el antiguo certificado no válido (que no funcionará) o el nuevo certificado válido (que funcionará). Es importante que el nuevo certificado contenga el mismo nombre de sujeto y clave pública que el certificado anterior, para que su firma en el certificado final sea válida. Firefox es lo suficientemente inteligente como para probar ambas opciones hasta que encuentra una que funciona, por lo que los complementos se vuelven a probar. Tenga en cuenta que esta es la misma lógica que utilizamos para validar los certificados TLS.
Nota del autor: Los lectores familiarizados con WebPKI notarán que los certificados cruzados funcionan exactamente de la misma manera.
Lo mejor de esta solución es que no requiere que vuelvas a firmar los complementos existentes. Tan pronto como el navegador reciba el nuevo certificado, todos los complementos volverán a funcionar. El desafío restante es entregar el nuevo certificado a los usuarios (de forma automática y remota), así como lograr que Firefox vuelva a verificar los complementos deshabilitados.
Normandía y el sistema de investigación
Irónicamente, este problema se resuelve mediante un complemento especial llamado "sistema". Para realizar investigaciones, desarrollamos un sistema llamado Normandy que ofrece investigaciones a los usuarios. Estos estudios se realizan automáticamente en el navegador y tienen acceso mejorado a las API internas de Firefox. La investigación puede agregar nuevos certificados al almacén de certificados.
Nota del autor: No agregamos un certificado con privilegios especiales; está firmado por el certificado raíz, por lo que Firefox confía en él. Simplemente lo agregamos al conjunto de certificados que puede utilizar el navegador.
Entonces la solución es crear un estudio:
- instalando el nuevo certificado que creamos para los usuarios
- obligar al navegador a volver a comprobar los complementos deshabilitados para que vuelvan a funcionar
"Pero espera", dices, "los complementos no funcionan, ¿cómo puedo iniciar un complemento del sistema?" ¡Firmamos con un nuevo certificado!
Poniéndolo todo junto... ¿por qué tarda tanto?
Entonces, el plan: emitir un nuevo certificado para reemplazar el antiguo, crear un complemento del sistema e instalarlo para los usuarios a través de Normandy. Los problemas, como dije, comenzaron el 4 de mayo a las 4:00, y ya a las 12:44 del mismo día, menos de 9 horas después, enviamos un arreglo a Normandía. Le tomó entre 6 y 12 horas más llegar a todos los usuarios. No está nada mal, pero la gente en Twitter se pregunta por qué no pudimos haber actuado más rápido.
Primero, tomó tiempo emitir un nuevo certificado intermedio. Como mencioné anteriormente, la clave del certificado raíz se almacena sin conexión en el módulo de seguridad del hardware. Esto es bueno desde el punto de vista de la seguridad, ya que la raíz se usa muy raramente y debe estar protegida de manera confiable, pero es un poco inconveniente cuando necesita firmar urgentemente un nuevo certificado. Uno de nuestros ingenieros tuvo que desplazarse hasta el almacén de HSM. Luego hubo intentos fallidos de emitir el certificado correcto, y cada intento costó una o dos horas de prueba.
En segundo lugar, el desarrollo del complemento del sistema llevó algún tiempo. Conceptualmente es muy sencillo, pero incluso los programas sencillos requieren cuidado. Queríamos asegurarnos de no empeorar la situación. La investigación debe probarse antes de enviarse a los usuarios. Además, el complemento debe estar firmado, pero nuestro sistema de firma de complementos estaba deshabilitado, por lo que tuvimos que buscar una solución.
Finalmente, una vez que tuvimos la investigación lista para enviarla, la implementación llevó tiempo. El navegador busca actualizaciones de Normandy cada 6 horas. No todas las computadoras están siempre encendidas y conectadas a Internet, por lo que la solución tardará un tiempo en llegar a los usuarios.
Pasos finales
La investigación debería solucionar el problema para la mayoría de los usuarios, pero no está disponible para todos. Algunos usuarios requieren un enfoque especial:
- usuarios que han desactivado la investigación o la telemetría
- usuarios de la versión de Android (Fennec), donde la investigación no es compatible en absoluto
- usuarios de compilaciones personalizadas de Firefox ESR en empresas donde no se puede habilitar la telemetría
- usuarios sentados detrás de proxies MitM, ya que nuestro sistema de instalación de complementos utiliza fijación de claves, que no funciona con dichos proxies
- usuarios de versiones heredadas de Firefox que no admiten la investigación
No podemos hacer nada con respecto a la última categoría de usuarios; aún así deberían actualizar a la nueva versión de Firefox, porque las obsoletas tienen vulnerabilidades graves sin parches. Sabemos que algunas personas permanecen en versiones anteriores de Firefox porque quieren ejecutar complementos antiguos, pero muchos de los complementos antiguos ya se han adaptado a versiones más nuevas del navegador. Para otros usuarios, hemos desarrollado un parche que instalará un nuevo certificado. Fue lanzado como una versión de corrección de errores (nota del traductor: Firefox 66.0.5), por lo que la gente lo obtendrá (probablemente ya lo haya recibido) a través del canal de actualización habitual. Si está utilizando una versión personalizada de Firefox ESR, comuníquese con su responsable de mantenimiento.
Entendemos que esto no es lo ideal. En algunos casos, los usuarios perdieron datos adicionales (por ejemplo, datos adicionales Contenedores multicuenta).
Este efecto secundario no se pudo evitar, pero creemos que a corto plazo hemos elegido la mejor solución para la mayoría de usuarios. A largo plazo buscaremos otros enfoques arquitectónicos más avanzados.
Lecciones
Primero, nuestro equipo hizo un trabajo increíble al crear y enviar una solución en menos de 12 horas después de que se descubrió el problema. Como alguien que asistió a las reuniones, puedo decir que en esta difícil situación la gente trabajó muy duro y se perdió muy poco tiempo.
Obviamente, nada de esto debería haber sucedido en absoluto. Está claro que vale la pena ajustar nuestros procesos para reducir la probabilidad de que se produzcan este tipo de incidentes y facilitar su remediación.
La próxima semana publicaremos una autopsia oficial y una lista de los cambios que pretendemos realizar. Por ahora, compartiré mis pensamientos. Primero, debe haber una mejor manera de monitorear el estado de lo que es una potencial bomba de tiempo. Necesitamos estar seguros de no encontrarnos en una situación en la que uno de ellos funcione de repente. Todavía estamos trabajando en los detalles, pero como mínimo es necesario tener en cuenta todas esas cosas.
En segundo lugar, necesitamos un mecanismo para entregar rápidamente actualizaciones a los usuarios, incluso cuando (especialmente cuando) todo lo demás falla. Fue fantástico que pudiéramos utilizar el sistema de "investigación", pero es una herramienta imperfecta y tiene algunos efectos secundarios no deseados. En particular, sabemos que muchos usuarios tienen activadas las actualizaciones automáticas, pero preferirían no participar en la investigación (lo admito, ¡yo también las tengo desactivadas!). Al mismo tiempo, necesitamos una forma de enviar actualizaciones a los usuarios, pero cualquiera que sea la implementación técnica interna, los usuarios deberían poder suscribirse a las actualizaciones (incluidas las correcciones urgentes) pero optar por no recibir todo lo demás. Además, el canal de actualización debería responder mejor que actualmente. Incluso el 6 de mayo, todavía había usuarios que no aprovecharon ni la solución ni la nueva versión. Este problema ya se ha trabajado, pero lo sucedido demostró lo importante que es.
Finalmente, analizaremos más de cerca la arquitectura de seguridad del complemento para asegurarnos de que proporcione el nivel adecuado de seguridad con un riesgo mínimo de romper algo.
La próxima semana veremos los resultados de un análisis más exhaustivo de lo sucedido, pero mientras tanto estaré encantado de responder preguntas por correo electrónico: [email protected]
Fuente: linux.org.ru