¿Deben los servidores web incluir las respuestas de OCSP sin éxito?

4

Mi comprensión primitiva de OCSP es que:

  • Las afirmaciones están firmadas por la CA y son válidas por un período corto.
  • Grapado se refiere a la práctica de insertar el trabajo de solicitud de OCSP en el servidor web, y luego almacenar en caché la respuesta (firmada por CA) y escupirla a los clientes mediante la extensión de "solicitud de estado".
  • Es posible que el servidor OCSP esté inactivo, en cuyo caso es posible que no se pueda obtener una respuesta correcta para grapar.

Estoy viendo el informe de OpenSSL de que el servidor está enviando estos datos de OCSP:

OCSP response: 
======================================
OCSP Response Data:
    OCSP Response Status: trylater (0x3)
======================================

¿Por qué sucedería esto alguna vez ? Seguramente, el servidor web debería enviar el último válido , ¿respuesta OCSP exitosa que haya almacenado en caché? Demonios, ¿no es preferible no enviar nada (y hacer que el navegador haga la solicitud por sí mismo) es preferible a grapar el trylater?

    
pregunta Adam Williams 15.08.2017 - 10:15
fuente

2 respuestas

4

El comportamiento del servidor web descrito es indeseable y parece deberse a una configuración predeterminada de Apache para la configuración SSLStaplingReturnResponderErrors . Ha habido numerosos en línea mensajes cuestionando la lógica detrás de estos valores predeterminados de configuración.

Además, las implementaciones de servidor web alternativas no siguen el ejemplo . Caddy no proporcionará respuestas grapadas si se produjo un error al llamar a ParseResse desde un ResponseStatus no exitoso, como TryLater . Esto garantiza que el usuario obtenga la última grapa de OCSP disponible que sea válida.

El enfoque es claramente óptimo para garantizar que el usuario mantenga el acceso al sitio, incluso cuando los respondedores de OCSP están fuera de línea o tienen dificultades. Existe una compensación entre la seguridad y la disponibilidad del sitio, pero dada la corta vida útil de las respuestas de OCSP, esta parece una solución bastante razonable. El navegador puede decidir si está dispuesto a aceptar la última respuesta buena conocida.

Una respuesta de "la CA dijo que el certificado era válido en $ timestamp" permitirá al agente de usuario tomar una decisión mucho mejor, informada que un "servidor OCSP que no nos dio nada, intente más tarde "respuesta.

    
respondido por el Adam Williams 15.08.2017 - 11:40
fuente
0

La clave es dar al cliente de autenticación la mayor cantidad de información para que ese cliente pueda determinar qué es aceptable. Un estado positivo de tryLater es información que puede ser útil para el cliente: puede elegir intentarlo más tarde, proceder pero registrar la excepción, usar otro mecanismo / respondedor (por ejemplo, CRL) o denegar la conexión.

Si el respondedor está inactivo, el servidor simplemente no sabe cuáles son los requisitos de seguridad del cliente, y dado que esto podría ser un acto malicioso por parte de MitM, el cliente no debe suponer que el servidor sabe mejor. >

Este comportamiento parece correcto.

    
respondido por el Liam Dennehy 15.08.2017 - 11:13
fuente

Lea otras preguntas en las etiquetas