Antes, los certificados a menudo caducaban porque tenían que actualizarse manualmente. La gente simplemente olvidaba hacerlo. Con la llegada de Let’s Encrypt y el procedimiento de actualización automática, se suponía que el problema estaría resuelto. Pero una reciente demuestra que, en realidad, sigue siendo un problema actual. Desafortunadamente, los certificados continúan caducando.
Si alguien se perdió esta historia, a la medianoche del 4 de mayo de 2019, casi todas las extensiones de Firefox dejaron de funcionar de repente.
Como resultó, un fallo masivo ocurrió porque Mozilla , que se utilizaba para firmar las extensiones. Por lo tanto, se marcaron como "no válidas" y no pasaron la verificación (). En los foros, se sugirió como solución desactivar la verificación de firmas de extensiones en about:config o cambiar la hora del sistema.
Mozilla rápidamente lanzó un parche para Firefox 66.0.4, que soluciona el problema con el certificado no válido, y todas las extensiones volvieron a la normalidad. Los desarrolladores recomiendan instalarlo y ninguna solución alternativa para eludir la verificación de firmas, ya que pueden conflictuar con el parche.
Sin embargo, esta historia una vez más muestra que la expiración de certificados sigue siendo un problema actual hoy en día.
En este sentido, es interesante observar un enfoque bastante original que los desarrolladores del protocolo . Su solución se puede dividir en dos partes. Primero, se trata de certificados a corto plazo. En segundo lugar, la advertencia a los usuarios sobre la caducidad de los a largo plazo.
DNSCrypt
DNSCrypt es un protocolo de encriptación del tráfico DNS. Protege las comunicaciones DNS de interceptaciones y MiTM, y permite evitar bloqueos a nivel de consultas DNS.
El protocolo envuelve el tráfico DNS entre el cliente y el servidor en una estructura criptográfica, operando sobre los protocolos de transporte UDP y TCP. Para usarlo, tanto el cliente como el resolvedor DNS deben soportar DNSCrypt. Por ejemplo, desde marzo de 2016, Yandex lo habilitó en sus servidores DNS y en el navegador. Algunos otros proveedores, incluidos Google y Cloudflare, también anunciaron su soporte. Desafortunadamente, no son muchos (en el sitio web oficial se listan 152 servidores DNS públicos). Pero el programa se puede instalar manualmente en clientes bajo Linux, Windows y MacOS. También hay .
¿Cómo funciona DNSCrypt? En resumen, el cliente toma la clave pública del proveedor elegido y con ella verifica sus certificados. Allí se encuentran las claves públicas a corto plazo para la sesión y el identificador del conjunto de cifrados. Se recomienda a los clientes generar una nueva clave para cada solicitud, y a los servidores cambiar las claves cada 24 horas. Se utiliza el algoritmo X25519 para el intercambio de claves, EdDSA para la firma, y XSalsa20-Poly1305 o XChaCha20-Poly1305 para el cifrado por bloques.
Uno de los desarrolladores del protocolo, Frank Denis , observó que el cambio automático cada 24 horas resolvió el problema de los certificados caducados. En general, el cliente de referencia dnscrypt-proxy acepta certificados con cualquier duración, pero emite una advertencia "El período de claves dnscrypt-proxy para este servidor es demasiado largo" si es válido por más de 24 horas. Simultáneamente se lanzó una imagen de Docker que implementaría un cambio rápido de claves (y certificados).
En primer lugar, esto es extremadamente útil para la seguridad: si el servidor está comprometido o la clave se filtra, el tráfico de ayer no puede ser descifrado. La clave ya ha cambiado. Probablemente, esto representará un problema para la ejecución de la "ley Yarovaya", que obliga a los proveedores a almacenar todo el tráfico, incluido el cifrado. Se supone que más tarde podrá ser descifrado si es necesario, solicitando la clave al sitio. Pero en este caso, el sitio simplemente no podrá proporcionarla, porque utiliza claves temporales, eliminando 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 claves no están configurados o no funcionan, esto se detectará de inmediato.
Cuando la automatización cambia las claves cada varios años, no se puede confiar en ella, y las personas pueden olvidar la fecha de caducidad del certificado. Con el cambio diario de claves, esto se detectará de inmediato.
Al mismo tiempo, si la automatización está configurada correctamente, no importa con qué frecuencia se cambian las claves: cada año, cada trimestre o tres veces al día. Si todo funciona más de 24 horas, funcionará para siempre, escribe Frank Denis. Según él, la recomendación de cambiar las claves a diario en la segunda versión del protocolo, junto con una imagen de Docker implementada para ello, ha reducido efectivamente la cantidad de servidores con certificados caducados, al mismo tiempo que ha mejorado la seguridad.
Sin embargo, algunos proveedores decidieron, por razones técnicas, establecer un período de validez del certificado de 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 de mayor gravedad 7 días antes de la expiración y un mensaje crítico si le quedan menos de 24 horas al certificado. Esto se aplica solo a los certificados que originalmente tienen un largo período de validez.
Estos mensajes permiten a los usuarios informar a los operadores de DNS sobre la próxima expiración del certificado, antes de que sea demasiado tarde.
Quizás, si todos los usuarios de Firefox hubieran recibido dicho mensaje, alguien definitivamente habría informado a los desarrolladores y ellos no habrían permitido que el certificado expirara. 'No recuerdo ningún servidor DNSCrypt de la lista de servidores DNS públicos que haya tenido un certificado caducado en los últimos dos o tres años', escribe Frank Denis. En cualquier caso, es mejor advertir a los usuarios primero, en lugar de desactivar las extensiones sin previo aviso.
Fuente: habr.com
