OCSP, CRLs, crlset - Entrega de revocación y ataques

1

Las respuestas de OCSP tienen un campo 'nextUpdate', que es el tiempo esperado para la nueva actualización de revocación y que la revocación actual puede considerarse válida. Las revocaciones pueden ser almacenadas en caché por los servidores de certificados intermedios, que he visto utilizados en diseños que proporcionan respuestas grapadas. He leído que las revocaciones se envían inmediatamente desde la CA raíz a la CA intermedia.

En este caso, ¿qué pasaría si hubiera un ataque DoS al servidor de la CA raíz para evitar que entregue la revocación? Esto podría exponer una ventana de oportunidad, utilizando la entrada de revocación en caché del servidor intermedio, que avisaría incorrectamente al cliente de un usuario final que un certificado de sitio web es válido, cuando puede no ser válido. El cliente o navegador del usuario podría interactuar con un sitio malicioso hasta que se detenga el DoS, se haga una llamada telefónica a todos los servidores intermedios, etc ... hasta 7 días.

Ha habido al menos tres ataques DoS en servidores de nombres raíz que duraron al menos una hora, sin embargo, no estoy seguro de cómo afectaría la capacidad de un servidor de CA para enviar tráfico saliente. Quizás tienen canales laterales para sacar la lista de revocaciones.

¿Alguien tiene más información sobre los aspectos técnicos de esto y la posibilidad de que ocurra este tipo de ataque? Además, tengo curiosidad por saber si alguien conoce la infraestructura de almacenamiento en caché para las CRL y el tiempo para esperar que aparezca una revocación en una CA intermedia típica.

Chrome utiliza su propio método de rastreo de CRL y Google los empuja al navegador en fragmentos, llamados crlset. A primera vista, OCSP tiene una mejor ventaja de tiempo en comparación con crlset, ya que contacta directamente a los respondedores autorizados para obtener el estado de las revocaciones, sin embargo, después de encontrar que algunos proveedores han implementado períodos de actualización de caché de CRL definidos de forma variable, no estoy seguro de que sea realmente mejor. Google afirma que su lista de revocaciones se actualiza diariamente y esto es más frecuente que otras soluciones.

¿Alguien conoce las ventajas y desventajas de la seguridad entre OCSP y el método crlset de Google? Específicamente, ¿cuál tiene mejor sincronización y confiabilidad para obtener la respuesta de revocación? ¿La afirmación de Google está respaldada por evidencia?

    
pregunta Nick 27.09.2018 - 08:10
fuente

1 respuesta

0

Hice una pregunta sobre CRL y OCSP ayer y luego leí el informe y llegué a la conclusión de que no hay una solución "perfecta" en este momento.

En un sistema perfecto, el navegador verificará el estado de revocación en la propia CA al menos una vez CADA sesión, pero para que funcione, cada CA deberá crear enormes clústeres de servidores con excelentes conexiones redundantes en todo el mundo para garantizar tiempos de respuesta mínimos. .

Porque eso no es realmente factible (no se puede esperar que cada CA cree una infraestructura tan grande) el engrapado OCSP se creó en primer lugar con los inconvenientes que mencionó.

Crlset de Google es básicamente algo intermedio, actúa como un caché de CRL. La ventaja es que Google tiene una gran infraestructura de servidores que es menos propensa a los ataques DoS, por lo que en teoría esto es bueno. El inconveniente es que depende de Google con todas las preocupaciones de privacidad y otros problemas que se presentan con él.

En mi opinión, los certificados deberían incluir un campo booleano "comprobación de revocación obligatoria en cada solicitud" que obliga al cliente a actualizar el estado de revocación en cada solicitud. Así que, básicamente, la infraestructura crítica y las aplicaciones de alta seguridad como los sitios bancarios siempre imponen un estado de revocación actualizado al inicio de cada sesión y los sitios menos críticos simplemente no lo hacen y optan por la usabilidad en lugar de la seguridad (más alta). Además, los usuarios deberían tener la opción de configurar esto individualmente para cada sitio (como las opciones de cookies, etc.) a menos que el servidor lo aplique (por lo tanto, desactivarlo cuando el servidor lo obliga no debería ser posible).

Esto es tanto una cuestión política como técnica, necesita una regulación para establecer algo como esto.

Pero, de nuevo, el vector de ataque para este escenario es bastante delgado en realidad si lo piensas. Básicamente, primero debe atacar el servidor y corromper el certificado (lo que debería ser muy improbable para las aplicaciones de alta seguridad) Y, al mismo tiempo, DoS la CA raíz con un gran ataque para que no llegue nada y luego usar esa pequeña ventana para ejecutar su ataque, esto es muy, muy improbable y se puede migrar aún más si el siguiente período de Actualización era aún más pequeño (que debería estar en entornos de alta seguridad).

Por lo tanto, también se trata de "¿Quién es responsable de la integridad de un servidor?" porque cuando alguien se apodera de la clave privada de su servidor, el estado de revocación de su certificado no es exactamente el mayor problema que tiene, sino alguien que tiene acceso de root a su servidor (o, lo que es peor, obtener su clave sin acceso de root).

    
respondido por el Broco 27.09.2018 - 10:33
fuente