En el pasado, los certificados a menudo expiraban porque tenían que actualizarse manualmente. La gente simplemente se olvidó de hacerlo. Con la llegada de Let's Encrypt y un procedimiento de actualización automática, el problema parece estar resuelto. Pero una
historia reciente
con Firefox muestra que, de hecho, sigue siendo relevante. Lamentablemente, los certificados siguen caducando.
Si alguien se perdió esta historia, casi todas las extensiones de Firefox dejaron de funcionar a la medianoche del 4 de mayo de 2019.
Al final resultó que, una falla masiva surgió porque Mozilla había
expirado el certificado que se utilizó para firmar las extensiones. Por lo tanto, se marcaron como "no válidas" y no pasaron la prueba (
detalles técnicos ). En los foros, como solución alternativa, recomendamos deshabilitar la verificación de firmas de extensión en
about: config o traduciendo el reloj del sistema.
Mozilla lanzó rápidamente el parche Firefox 66.0.4, que resuelve el problema con un certificado no válido, y todas las extensiones vuelven a su forma normal. Los desarrolladores recomiendan instalarlo y
no utilizar ninguna solución alternativa para evitar la verificación de firma, ya que 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 problema urgente hoy.
En este sentido, es interesante observar de una manera bastante original cómo los desarrolladores del protocolo
DNSCrypt hicieron frente a esta tarea. Su solución se puede dividir en dos partes. En primer lugar, se trata de certificados a corto plazo. En segundo lugar, advertir a los usuarios sobre el vencimiento de los a largo plazo.
DNSCrypt
DNSCrypt: protocolo de cifrado de tráfico DNS. Protege las comunicaciones DNS de las intercepciones y MiTM, y también le permite evitar el bloqueo a nivel de consultas DNS.
El protocolo envuelve el tráfico DNS entre el cliente y el servidor en un diseño criptográfico, trabajando en los protocolos de transporte UDP y TCP. Para usarlo, tanto el cliente como el solucionador DNS deben admitir DNSCrypt. Por ejemplo, desde marzo de 2016, se habilitó en sus servidores DNS y en el navegador Yandex. El soporte fue anunciado por varios otros proveedores, incluidos Google y Cloudflare. Desafortunadamente, no hay muchos de ellos (152 servidores DNS públicos están listados en el sitio web oficial). Pero el programa
dnscrypt-proxy se puede instalar manualmente en clientes en Linux, Windows y MacOS. Hay
implementaciones de servidor .
¿Cómo funciona DNSCrypt? En resumen, el cliente toma la clave pública del proveedor seleccionado y con su ayuda verifica sus certificados. Ya hay claves públicas a corto plazo para la sesión y el identificador de la suite de cifrado. Se aconseja a los clientes que generen una nueva clave para cada solicitud, y se alienta a los servidores a cambiar las claves
cada 24 horas . Al intercambiar claves, se utiliza el algoritmo X25519, EdDSA para firmar y XSalsa20-Poly1305 o XChaCha20-Poly1305 para el cifrado de bloques.
Frank Denis, uno de los desarrolladores de protocolos,
escribe que el reemplazo automático cada 24 horas resolvió el problema de los certificados caducados. En principio, el cliente de referencia dnscrypt-proxy acepta certificados con cualquier período de validez, pero muestra 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 implementaron 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 pierde la clave, entonces el tráfico de ayer no se puede descifrar. La clave ya ha cambiado. Esto probablemente será un problema para la implementación de la "Ley de Primavera", que obliga a los proveedores a almacenar todo el tráfico, incluido el tráfico encriptado. Se entiende que más adelante se puede descifrar si es necesario solicitando una clave del sitio. Pero en este caso, el sitio simplemente no podrá proporcionarlo, ya que utiliza claves a corto plazo, eliminando las antiguas.
Pero lo más importante, escribe Denis, 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á de inmediato.
Cuando la automatización cambia las claves cada pocos años, no puede confiar en ella y las personas pueden olvidarse de la caducidad del certificado. Con un cambio diario de clave, esto se detectará instantáneamente.
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 un cambio de clave diario en la segunda versión del protocolo, junto con la imagen de Docker ya preparada que implementa esto, redujo efectivamente el número de servidores con certificados caducados, al tiempo que mejora la seguridad.
Sin embargo, algunos proveedores aún decidieron, por algunas razones técnicas, establecer el período de validez del certificado en más de 24 horas. Este problema se resolvió principalmente con unas pocas líneas de código en dnscrypt-proxy: los usuarios reciben una advertencia informativa 30 días antes de que expire el certificado, otro mensaje con un nivel de gravedad más alto 7 días antes de que expire el certificado y un mensaje crítico si el certificado permanece Menos de 24 horas. Esto solo se aplica a los certificados que inicialmente tienen un largo período de validez.
Dichos mensajes permiten a los usuarios informar a los operadores de DNS de la próxima caducidad del certificado antes de que sea demasiado tarde.
Quizás si todos los usuarios de Firefox recibieran ese mensaje, alguien probablemente habría informado a los desarrolladores y no hubieran permitido que el certificado caduque. "No recuerdo un solo servidor DNSCrypt de la lista de servidores DNS públicos que han expirado un certificado en los últimos dos o tres años", escribe Frank Denis. En cualquier caso, probablemente sea mejor advertir a los usuarios primero, y no desactivar las extensiones sin previo aviso.
