Detalles y dudas de grapado OCSP

Question

Detalles y dudas de grapado OCSP

#1 de StackzOfZtuff (1 votos)

0

Estoy tratando de averiguar los detalles del grapado OCSP y cómo funciona. Como a menudo la mejor manera es, inicié Wireshark e hice una solicitud simple a un servidor que tiene habilitado el grapado OCSP.

¿Puede alguien aclarar las dudas que tengo a continuación?

Solicitud
Datos de la extensión de saludo del cliente:

En Wireshark veo la extensión de saludo del cliente como se muestra a continuación
```
Extension: status_request
  Type: status_request (0x0005)
  Length: 5
  Certificate Status Type: OCSP (1)
  Responder ID list Length: 0
  Request Extensions Length: 0
```
Entiendo la presencia de los dos primeros campos. Pero, ¿por qué necesitamos los siguientes 3 ( Certificate Status Type , Responder ID list Length , Request Extensions Length ), ya que son 0 de todos modos. ¿Qué tipo de datos pueden contener y cómo se supone que el servidor procesa los datos en estos campos?
Respuesta
Parte de la respuesta es:
```
Certificate Status Type: OCSP (1)
ResponseType Id: 1.3.6.1.5.5.7.48.1.1 (id-pkix-ocsp-basic)
BasicOCSPResponse
tbsResponseData
responderID: byKey (2)
  byKey: f2026c2ad426a4a59cb2505b3962446034151e5b
```
¿Qué son los campos byKey y ResponseType ID ? ¿Y cómo se supone que el cliente procese lo mismo? ¿El cliente necesita hacer coincidir el Certificate status type con lo que se envió en el cliente hola?
¿Cadena?
Entiendo que se deben realizar comprobaciones de revocación para todos los certificados de la cadena. ¿Cómo encaja esto con el grapado? Estamos haciendo un apretón de manos sólo una vez. ¿Es el servidor responsable de mantener el estado de revocación de todos los certificados de la cadena?

tls ocsp

pregunta Lazy Getter 08.01.2016 - 00:11

fuente

1 respuesta

Lea otras preguntas en las etiquetas tls ocsp

Asegurar las claves de inicio de sesión de HSM ¿El proveedor de autenticación de terceros incluido a través de iframe se considera (in) seguro de manera predeterminada?

score 1 · Accepted Answer

1. Solicitud

[...] ¿por qué necesitamos los 3 siguientes (Tipo de estado del certificado, Longitud de la lista de identificadores de respondedores, Longitud de solicitud de extensiones) [...]?

El status_request se define en RFC 6066, sección 8. Solicitud de estado del certificado .

Certificate Status Type: OCSP (1)

Aburrido. Es el único valor definido en este momento. El campo es para la extensibilidad futura, supongo.

Responder ID list Length: 0

Desde el RFC:

En el OCSPStatusRequest, el "ResponderIDs" proporciona una lista de OCSP Respondedores que el cliente confía. Un "respondedor_id_list" de longitud cero secuencia tiene el significado especial de que los respondedores son implícitamente conocido por el servidor, por ejemplo, por acuerdo previo.

Y esto está destinado especialmente para "clientes restringidos", como los sistemas integrados, que solo conocen un puñado de CA.

Desde el RFC:

"Extensiones" se importa desde [RFC5280]. UNA El valor de "request_extensions" de longitud cero significa que no hay extensiones (a diferencia de una SECUENCIA ASN.1 de longitud cero, que no es válido para el tipo "Extensiones").

No sé. Realmente no entiendo el importado de RFC5280 . Pero supongo que podría referirse específicamente a sección 5.2.1 de ese RFC5280 . Pero tampoco entiendo realmente esa sección.

2. Respuesta

[...] ¿Qué son los campos byKey y ResponseType ID ? [...]

El campo byKey es solo un identificador para el respondedor OCSP. Para que el cliente pueda decidir si confía en el respondedor / firmante o no . Y puede ser ya sea byName o byKey

¿El cliente necesita hacer coincidir el tipo de estado del Certificado con lo que se envió en el cliente?

Absolutamente. Pero solo hay un tipo definido en este momento, de todos modos, nada más que OCSP (1) será indefinido / incorrecto / inútil.

3. ¿Cadena?

Comprendo que es necesario realizar verificaciones de revocación para todos los certificados de la cadena. ¿Cómo encaja esto con el grapado?

AFAIK: no demasiado bien. Pero hay un esfuerzo por introducir "Multiaplante" (a partir de 2013) :

Con el soporte necesario en los clientes y servidores TLS, también sería posible utilizar el grapado OCSP para los certificados de CA intermedios. La verificación de esta información en relación con una respuesta OCSP grapada se conoce como "grapado múltiple".

El grapado múltiple debería haber sido tan simple como definir un nuevo método para la extensión del Estado del certificado e incluir ese método en la lista de métodos admitidos por el cliente. Desafortunadamente, ese no fue el caso.