¿Cómo aumentan la seguridad los certificados de corta duración?

4

Después de leer una publicación de blog sobre el nuevo protocolo Roughtime, no estoy convencido de la premisa original de que el certificado sea más corto Las vidas aumentan la seguridad. La afirmación es que un menor tiempo de alguna manera reduce la exposición si se compromete una clave secreta. Pero, ¿qué tan realista es ese escenario?

Si el protocolo criptográfico es débil y así se comprometió la clave, no tiene sentido cambiar la clave por una nueva igualmente débil. A la inversa, si el protocolo es bueno, un atacante solo podrá comprometer la clave secreta de violar el sistema (o explotar a personas débiles). Y sabemos por la larga experiencia con violaciones que lo primero que hace un atacante es abrir una puerta trasera para retener el acceso si su vulnerabilidad explotada originalmente está cerrada. La cantidad de tiempo entre una violación y el proceso de puerta trasera se mide generalmente en segundos o minutos, lo que probablemente no ayude una política de rotación.

Finalmente, hemos comenzado a aceptar con contraseñas que la rotación frecuente no tiene sentido (y es arriesgada). Las recomendaciones del NIST son evidencia de ese cambio. Creer en las frecuentes rotaciones de los certificados parece ser un remanente supersticioso de las ideas de seguridad de los años ochenta.

Así que estoy pidiendo pruebas. ¿Se han realizado estudios sobre la eficacia de los certificados de corta duración como medida de seguridad? ¿Hay alguna prueba de que las rotaciones frecuentes de certificados mejoren la seguridad en lugar de simplemente causar inconvenientes frustrantes (y un tiempo de inactividad significativo a medida que caducan los certificados) para todos los involucrados? Otra forma de hacer la pregunta es ¿cuáles son los beneficios reales que ofrece un breve período de rotación de certificados?

    
pregunta John Deters 22.09.2018 - 20:51
fuente

2 respuestas

2

Un documento que no me resisto a mostrarle aquí es draft-nir-saag-star de Yoav Nir (el presidente del grupo de trabajo ACME ) y la discusión posterior a través de saag lista de correo .

Un problema importante en el que se levanta Yoav es que ni los respondedores de OCSP ni los puntos de distribución de CRL son ampliamente reconocidos como partes de red confiables. Quiero decir, obviamente tampoco hay pruebas de que estén constantemente caídas, pero, dado el enfoque de falla suave actualmente en uso, no es necesario que haya una infraestructura de autoridad de certificación actual disponible y monitoreada las 24 horas del día, los 7 días de la semana, lo que dificulta la transición a falla (con los gustos de Must-Staple, etc.) mucho más difícil.

Y, de todos modos, CRL y OCSP constituyen un punto único de falla adicional, mientras que el servicio de Internet de hoy hace todo lo posible por evitarlos.

De hecho, un certificado de corta duración solo es válido si la rotación es automática; sin embargo, para un servicio de red lo suficientemente escalable, implementado entre decenas y cientos a miles de instancias físicas y / o virtuales, esto es cierto.

También algunos comentarios rápidos sobre el resto de la pregunta,

  

A la inversa, si el protocolo es bueno, un atacante solo podrá comprometer la clave secreta para que no pueda violar el sistema

- Pero no necesariamente el sistema donde se implementan el certificado y la clave privada para manejar el tráfico de producción. También podría ser el servidor central Ansible , o su almacenamiento de red, o un servidor utilizado para la renovación del certificado, o Algo más. También podría ser solo una pequeña parte de los servidores de producción, ni siquiera en uso (por ejemplo, cuando un servicio de red se implementa en unos pocos proveedores de nube y uno de ellos ha permitido una violación). En algunos modelos de amenazas (¿más obsoletos?), También podría haber sido una computadora portátil personal (robada) de un empleado responsable de la renovación del certificado.

En todos los casos anteriores, no habrá ningún beneficio inmediato para un atacante por instalar una puerta trasera, mientras que aún pueden desaparecer fácilmente con la clave privada y usarla para MitM, etc.

  

Finalmente, hemos comenzado a aceptar con contraseñas que la rotación frecuente no tiene sentido (y es arriesgada)

Bueno, no exactamente . P.ej. NIST SP 800-63B sugiere que "los verificadores NO DEBEN requerir los secretos memorizados se cambiarán arbitrariamente (por ejemplo, periódicamente) ", donde un secreto memorizado es " un tipo de autenticador que consta de una cadena de caracteres destinada a ser memorizada o memorable por el suscriptor, permitiendo que el suscriptor demuestre algo que ellos saben como parte de un proceso de autenticación ".

Sin embargo, esto no se aplica a una clave privada que nunca se espera que sea memorizada o memorable en ningún escenario de uso contemporáneo. De hecho, también hay inconvenientes de una rotación frecuente de certificados (como la necesidad de automatizar correctamente las cosas), pero ni siquiera están cerca de las desventajas de una rotación frecuente de contraseñas memorables.

    
respondido por el ximaera 24.09.2018 - 00:24
fuente
1

La revocación es más fácil.

Si no hace nada, el certificado se invalidará por sí solo después de un corto período de tiempo, lo que lo hace menos peligroso que uno con una larga vida útil.

Cuando realmente emplea infraestructura de revocación, obtiene enormes listas de revocación de certificados (CRL) y mucho tráfico en los servidores de OCSP para verificar si se revocó un certificado. Esta es una gran cantidad de costos de administración e infraestructura, que por ejemplo, puede haber evitado letoncrypt.
Por lo tanto, utilizan una vida útil corta para los certificados, por lo que sus listas de revocación son siempre muy cortas, ya que pueden eliminar los certificados caducados de las listas.

    
respondido por el allo 24.09.2018 - 15:43
fuente

Lea otras preguntas en las etiquetas