En el pasado, los certificados caducaban a menudo porque debían renovarse manualmente. La gente simplemente se olvidó de hacerlo. Con la llegada de Let's Encrypt y el procedimiento de actualización automática, parece que el problema debería solucionarse. Pero reciente muestra que, de hecho, sigue siendo relevante. Lamentablemente, los certificados siguen caducando.
En caso de que te perdiste la historia, a la medianoche del 4 de mayo de 2019, casi todas las extensiones de Firefox dejaron de funcionar repentinamente.
Al final resultó que, el fallo masivo se produjo debido al hecho de que Mozilla , que se utilizaba para firmar extensiones. Por lo tanto, fueron marcados como “no válidos” y no fueron verificados (). En los foros, como solución alternativa, se recomendó deshabilitar la verificación de firma de extensión en about: config o cambiar el reloj del sistema.
Mozilla lanzó rápidamente el parche Firefox 66.0.4, que resuelve el problema del certificado no válido y todas las extensiones vuelven a la normalidad. Los desarrolladores recomiendan instalarlo y No hay soluciones para eludir la verificación de firmas porque pueden entrar en conflicto con el parche.
Sin embargo, esta historia muestra una vez más que la caducidad de los certificados sigue siendo un tema apremiante en la actualidad.
En este sentido, es interesante observar de una manera bastante original cómo los desarrolladores del protocolo abordaron esta tarea. . Su solución se puede dividir en dos partes. En primer lugar, se trata de certificados de corta duración. En segundo lugar, advertir a los usuarios sobre la caducidad de los de larga duración.
DNSCrypt
DNSCrypt es un protocolo de cifrado de tráfico DNS. Protege las comunicaciones DNS contra intercepciones y MiTM, y también le permite evitar el bloqueo en el nivel de consulta DNS.
El protocolo envuelve el tráfico DNS entre el cliente y el servidor en una construcción criptográfica, que opera sobre los protocolos de transporte UDP y TCP. Para usarlo, tanto el cliente como el solucionador de DNS deben admitir DNSCrypt. Por ejemplo, desde marzo de 2016 está habilitado en sus servidores DNS y en el navegador Yandex. Varios otros proveedores también han anunciado soporte, incluidos Google y Cloudflare. Desafortunadamente, no hay muchos (152 servidores DNS públicos figuran en el sitio web oficial). Pero el programa Se puede instalar manualmente en clientes Linux, Windows y MacOS. También hay .
¿Cómo funciona DNSCrypt? En resumen, el cliente toma la clave pública del proveedor seleccionado y la utiliza para verificar sus certificados. Las claves públicas a corto plazo para la sesión y el identificador del conjunto de cifrado ya están ahí. Se anima a los clientes a generar una nueva clave para cada solicitud y a los servidores a cambiar las claves. cada 24 horas. Al intercambiar claves, se utiliza el algoritmo X25519, para firmar - EdDSA, para cifrado de bloques - XSalsa20-Poly1305 o XChaCha20-Poly1305.
Uno de los desarrolladores del protocolo, Frank Denis. ese reemplazo automático cada 24 horas solucionó el problema de los certificados caducados. En principio, el cliente de referencia dnscrypt-proxy acepta certificados con cualquier período de validez, pero emite una advertencia "El período de clave dnscrypt-proxy para este servidor es demasiado largo" si es válido por más de 24 horas. Al mismo tiempo, se lanzó una imagen de Docker, en la que se implementó un cambio rápido de claves (y certificados).
En primer lugar, es extremadamente útil para la seguridad: si el servidor se ve comprometido o se filtra la clave, el tráfico de ayer no se podrá descifrar. La clave ya ha cambiado. Esto probablemente planteará un problema para la implementación de la Ley Yarovaya, que obliga a los proveedores a almacenar todo el tráfico, incluido el cifrado. La implicación es que luego se puede descifrar si es necesario solicitando la clave al sitio. Pero en este caso, el sitio simplemente no puede proporcionarlo, porque utiliza claves de corta duración y elimina las antiguas.
Pero lo más importante, escribe Denis, es que las claves a corto plazo obligan a los servidores a configurar la automatización desde el primer día. Si el servidor se conecta a la red y los scripts de cambio de clave no están configurados o no funcionan, esto se detectará inmediatamente.
Cuando la automatización cambia las claves cada pocos años, no se puede confiar en ella y la gente puede olvidarse de la caducidad del certificado. Si cambias las claves a diario, esto se detectará al instante.
Al mismo tiempo, si la automatización se configura normalmente, no importa con qué frecuencia se cambien las claves: cada año, cada trimestre o tres veces al día. Si todo funciona durante más de 24 horas, funcionará para siempre, escribe Frank Denis. Según él, la recomendación de la rotación diaria de claves en la segunda versión del protocolo, junto con una imagen Docker ya preparada que lo implementa, redujo efectivamente la cantidad de servidores con certificados caducados, al mismo tiempo que mejoró la seguridad.
Sin embargo, algunos proveedores decidieron, por razones técnicas, establecer el período de validez del certificado en más de 24 horas. Este problema se resolvió en gran medida con unas pocas líneas de código en dnscrypt-proxy: los usuarios reciben una advertencia informativa 30 días antes de que caduque el certificado, otro mensaje con un nivel de gravedad más alto 7 días antes de la caducidad y un mensaje crítico si al certificado le queda algo restante. Validez inferior a 24 horas. Esto sólo se aplica a los certificados que inicialmente tienen un período de validez prolongado.
Estos mensajes brindan a los usuarios la oportunidad de notificar a los operadores DNS sobre la inminente caducidad del certificado antes de que sea demasiado tarde.
Quizás si todos los usuarios de Firefox recibieran ese mensaje, entonces alguien probablemente informaría a los desarrolladores y no permitirían que el certificado caduque. "No recuerdo ni un solo servidor DNSCrypt en la lista de servidores DNS públicos cuyo certificado haya caducado en los últimos dos o tres años", escribe Frank Denis. En cualquier caso, probablemente sea mejor advertir a los usuarios primero que deshabilitar las extensiones sin previo aviso.
Fuente: habr.com