Nota del traductor: para mayor comodidad de los lectores, las fechas se presentan en hora de Moscú
Recientemente, perdimos la fecha de caducidad de uno de los certificados utilizados para firmar complementos. Esto llevó a la desactivación de los complementos para los usuarios. Ahora que, en su mayoría, el problema se ha solucionado, me gustaría contarles los detalles de lo ocurrido y del trabajo realizado.
Contexto: complementos y firmas
Los complementos instalados deben tener una 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, ya que experimentamos graves problemas con complementos maliciosos.
Así es como funciona: cada copia de Firefox contiene un "certificado raíz". La clave de este "raíz" se almacena en un módulo de seguridad de hardware (HSM), que no tiene acceso a la red. Cada pocos años, esta clave firma un nuevo "certificado intermedio", que se utiliza al firmar complementos. Cuando un desarrollador envía un complemento, creamos un "certificado final" temporal y lo firmamos utilizando el certificado intermedio. Luego, el complemento en sí es firmado con el certificado final. Esquema se ve así.
Nota: cada certificado tiene un "sujeto" (a quien se le otorgó el certificado) y un "emisor" (quien emitió el certificado). En el caso del certificado raíz, "sujeto" = "emisor", pero para otros certificados, el emisor es el sujeto del certificado superior que lo firmó.
Un punto importante: cada complemento está firmado con un certificado final único, pero casi siempre estos certificados finales son firmados por el mismo certificado intermedio.
Nota del autor: la excepción son los complementos muy antiguos. En ese momento, se utilizaron diferentes certificados intermedios.
Este certificado intermedio causó problemas: cada certificado es válido durante un período específico. Antes o después de este período, el certificado es inválido y el navegador no utilizará complementos firmados con este certificado. Desafortunadamente, la validez del certificado intermedio expiró el 4 de mayo a las 4 a.m.
Las consecuencias no se manifestaron de inmediato. Firefox verifica las firmas de los complementos instalados no de manera continua, sino aproximadamente cada 24 horas, siendo el momento de la verificación individual para cada usuario. Como resultado, algunas personas tuvieron problemas de inmediato, mientras que a otras les ocurrió mucho después. Nos enteramos del problema por primera vez aproximadamente en el momento en que expiró el certificado y comenzamos a buscar una solución de inmediato.
Reduciendo el daño
Una vez que entendimos lo que había sucedido, intentamos evitar que la situación empeorara.
En primer lugar, dejamos de aceptar y firmar nuevos complementos. No tiene sentido usar un certificado vencido para ello. Mirando hacia atrás, diría que se podría haber dejado todo como estaba. Ahora se han reanudado las aceptaciones de complementos.
En segundo lugar, enviamos inmediatamente un arreglo que evitó la verificación diaria de las firmas. De esta manera, salvamos a aquellos usuarios cuyo navegador aún no había verificado los complementos en las últimas 24 horas. Actualmente, este arreglo ha sido retirado, ya no es necesario.
Trabajo paralelo
Teóricamente, la solución al problema parece simple: creamos un nuevo certificado intermedio válido y firmamos de nuevo cada complemento. Desafortunadamente, esto no funcionará:
- no podemos volver a firmar 15,000 complementos a la vez rápidamente, el sistema no está diseñado para esa carga
- después de firmar los complementos, las versiones actualizadas deben entregarse a los usuarios. La mayoría de los complementos se instalan desde los servidores de Mozilla, por lo que en las próximas 24 horas Firefox encontrará actualizaciones, pero algunos desarrolladores distribuyen complementos firmados a través de canales externos, por lo que los usuarios tendrían que actualizar esos complementos manualmente
En su lugar, intentamos desarrollar un arreglo que llegara a todos los usuarios, sin requerir (o casi sin requerir) acciones de su parte.
Pronto llegamos a dos estrategias principales, que utilizamos simultáneamente:
- Actualizar Firefox para cambiar el período de validez del certificado. Esto hará que las extensiones existentes funcionen mágicamente de nuevo, pero requerirá emitir y entregar una nueva versión de Firefox.
- Crear un certificado válido y de alguna manera convencer a Firefox de aceptarlo en lugar del existente, cuyo período de validez ha expirado.
Decidimos usar primero la primera opción, que parecía bastante viable. Al final del día, emitimos un segundo parche (nuevo certificado), del que hablaremos más adelante.
Sustitución del certificado
Como mencioné anteriormente, era necesario:
- crear un nuevo certificado válido
- instalarlo de forma remota en Firefox
Para entender por qué esto funcionará, analicemos más a fondo el proceso de verificación de la extensión. La propia extensión se entrega como un conjunto de archivos, incluida la cadena de certificación utilizada para la firma. Como resultado, la extensión puede ser verificada si el navegador conoce el certificado raíz, que se incrusta en Firefox durante la construcción. Sin embargo, como ya sabemos, el certificado intermedio ha caducado, por lo que es imposible verificar la extensión.
Cuando Firefox intenta verificar la extensión, no se limita a usar los certificados que contiene la extensión misma. En lugar de eso, el navegador intenta construir una cadena de certificación 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 encontramos el certificado cuyo sujeto es el emisor del certificado final (es decir, el certificado intermedio). Generalmente, este certificado intermedio se entrega junto con la extensión, pero también puede desempeñar este papel cualquier certificado del almacén del navegador. Si podemos agregar de forma remota un nuevo certificado válido al almacén de certificados, Firefox intentará usarlo. Situación antes y después de la instalación del nuevo certificado.
Después de instalar un nuevo certificado, Firefox tendrá dos opciones al verificar 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 la misma clave pública que el antiguo, por lo que su firma en el certificado final será válida. Firefox es lo suficientemente inteligente como para probar ambas opciones hasta que encuentre una que funcione, por lo que las extensiones volverán a estar verificadas. Tenga en cuenta que esta es la misma lógica que utilizamos para verificar certificados TLS.
Nota del autor: los lectores familiarizados con WebPKI notarán que los certificados cruzados funcionan de la misma manera.
Lo más notable de esta solución es que no requiere volver a firmar las extensiones existentes. Una vez que el navegador reciba el nuevo certificado, todas las extensiones volverán a funcionar. La dificultad radica en entregar el nuevo certificado a los usuarios (de forma automática y remota) y hacer que Firefox vuelva a verificar las extensiones desactivadas.
Normandy y el sistema de investigaciones
Irónicamente, este problema lo resuelve una extensión especial llamada "sistema". Para llevar a cabo investigaciones, hemos desarrollado un sistema llamado Normandy, que entrega investigaciones a los usuarios. Estas investigaciones se ejecutan automáticamente en el navegador y tienen acceso ampliado a las API internas de Firefox. Las investigaciones pueden agregar nuevos certificados al almacén de certificados.
Nota del autor: no estamos agregando un certificado con privilegios especiales; está firmado por un certificado raíz, por lo que Firefox confía en él. Simplemente lo agregamos al grupo de certificados que el navegador puede usar.
Por lo tanto, la solución consiste en crear una investigación:
- que establezca el nuevo certificado creado por nosotros para los usuarios
- que obligue al navegador a volver a verificar las extensiones desactivadas para que vuelvan a funcionar
"Pero espera", dirás, "las extensiones no funcionan, ¿cómo iniciar la extensión del sistema?" ¡Firmémosla con el nuevo certificado!
Reuniéndolo todo... ¿por qué tarda tanto?
Así que, el plan: lanzar un nuevo certificado para reemplazar el viejo, crear un complemento del sistema e instalarlo para los usuarios a través de Normandy. Los problemas, como mencioné, 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 una solución a Normandy. Se necesitaron otras 6-12 horas para que llegara a todos los usuarios. No está mal, pero los usuarios en Twitter preguntan por qué no pudimos actuar más rápido.
En primer lugar, se necesitó tiempo para emitir un nuevo certificado intermedio. Como ya mencioné anteriormente, la clave del certificado raíz se almacena de forma autónoma en un módulo de seguridad de hardware. Esto es bueno desde el punto de vista de la seguridad, ya que el raíz se usa muy raramente y debe estar bien protegido, pero es un poco incómodo cuando se necesita firmar urgentemente un nuevo certificado. Uno de nuestros ingenieros tuvo que ir al almacenamiento del HSM. Luego hubo intentos fallidos de emitir el certificado correcto, y cada intento costó una o dos horas dedicadas a las pruebas.
En segundo lugar, la creación del complemento del sistema tomó tiempo. Conceptualmente es muy simple, pero incluso los programas sencillos requieren atención. Queríamos asegurarnos de no empeorar la situación. La investigación necesita ser probada antes de enviarse a los usuarios. Además, el complemento debe estar firmado, pero nuestro sistema de firma de complementos estaba desactivado, tuvimos que buscar una solución alternativa.
Finalmente, después de que preparamos la investigación para el envío, se necesitó tiempo para su despliegue. El navegador verifica si hay actualizaciones de Normandy cada 6 horas. No todas las computadoras están constantemente encendidas y conectadas a Internet, por lo que se requiere tiempo para que la corrección se difunda entre 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 para Android (Fennec), donde no se admite la investigación en absoluto
- usuarios de compilaciones personalizadas de Firefox ESR en empresas donde no es posible habilitar la telemetría
- los usuarios detrás de proxies MitM, ya que nuestro sistema de instalación de complementos utiliza la vinculación de claves (key pinning), que no funciona con tales proxies
- los usuarios de versiones obsoletas de Firefox que no son compatibles con la investigación
No podemos hacer nada con la última categoría de usuarios; deben actualizarse a una versión nueva de Firefox, ya que las obsoletas tienen vulnerabilidades graves no cerradas. Sabemos que algunas personas se quedan en versiones antiguas de Firefox porque quieren ejecutar complementos antiguos, pero muchos de los complementos antiguos ya han sido portados a nuevas versiones del navegador. Para otros usuarios, hemos desarrollado un parche que instalará un nuevo certificado. Se lanzó como una versión de corrección de errores (nota del traductor: Firefox 66.0.5), por lo que las personas lo recibirán — lo más probable es que ya lo hayan recibido — a través del canal de actualización habitual. Si utiliza una versión personalizada de Firefox ESR, consulte a su mantenedor.
Entendemos que todo esto no es ideal. En algunos casos, los usuarios han perdido datos de complementos (por ejemplo, los datos del complemento Multi-Account Containers).
Este efecto secundario no se pudo evitar, pero creemos que hemos elegido la mejor solución para la mayoría de los usuarios a corto plazo. A largo plazo, buscaremos enfoques arquitectónicos más sofisticados.
Lecciones
Primero, nuestro equipo hizo un trabajo increíble creando y enviando la corrección en menos de 12 horas después de descubrir el problema. Como alguien que estuvo presente en las reuniones, puedo decir que en esta complicada situación, la gente trabajó muy duro y se perdió muy poco tiempo.
Es evidente que nada de esto debería haber ocurrido. Es necesario ajustar nuestros procesos para reducir la probabilidad de incidentes similares y facilitar la corrección de las consecuencias.
La próxima semana publicaremos el informe post-mortem oficial y la lista de cambios que planeamos implementar. Mientras tanto, compartiré mis pensamientos. En primer lugar, debe haber una mejor manera de rastrear el estado de lo que podría ser una bomba de tiempo. Debemos asegurarnos de no encontrarnos en una situación en la que una de ellas se activa repentinamente. Aún estamos trabajando en los detalles, pero, al menos, se requiere llevar un inventario de todas estas cosas.
En segundo lugar, necesitamos un mecanismo para entregar actualizaciones rápidamente a los usuarios, incluso cuando — especialmente cuando — todo lo demás no funciona. Fue genial que pudiéramos usar el sistema de 'investigaciones', pero es una herramienta imperfecta y tiene algunos efectos secundarios no deseables. En particular, sabemos que muchos usuarios tienen habilitada la actualización automática, pero preferirían no participar en las investigaciones (debo admitir que yo también las tengo desactivadas). Al mismo tiempo, necesitamos una forma de enviar actualizaciones a los usuarios, pero, sea cual sea la implementación técnica interna, los usuarios deben poder suscribirse a actualizaciones (incluyendo correcciones urgentes), pero rechazar todo lo demás. Además, el canal de actualización debe ser más receptivo que ahora. Incluso el 6 de mayo, había usuarios que no habían recibido ni la corrección ni la nueva versión. Ya estábamos trabajando en este problema, pero lo sucedido mostró cuán importante es.
Finalmente, revisaremos la arquitectura de seguridad de las extensiones para asegurarnos de que proporciona el nivel adecuado de seguridad con un riesgo mínimo de romper algo.
La próxima semana revisaremos los resultados de un análisis más detallado de lo ocurrido, pero mientras tanto estaré encantado de responder preguntas por correo electrónico: ekr-blog@mozilla.com
Fuente: linux.org.ru
