¿Está utilizando HTTP para OCSP una vulnerabilidad potencial? [duplicar]

Question

¿Está utilizando HTTP para OCSP una vulnerabilidad potencial? [duplicar]

#1 de Steffen Ullrich (21 votos)
#2 de Mike Ounsworth (4 votos)

11

Al inspeccionar mi certificado aprobado por CA, noté las siguientes rarezas:

Extensiones / CRL Puntos de distribución:

  Not Critical
  URI: http://crl2.alphassl.com/gs/gsalphasha2g2.crl

Extensiones / Acceso a la información de la autoridad:

Not Critical
CA Issuers: URI: http://secure2.alphassl.com/cacert/gsalphasha2g2r1.crt
OCSP: URI: http://ocsp2.globalsign.com/gsalphasha2g2

¿No debería publicarse la información de OCSP a través de HTTPS (es decir, protegida con TLS), para protegerse contra MITM? ¿Es ese campo solo ruido que no debe ser utilizado por un cliente?

Sé que Es una vulnerabilidad potencial la publicación de CRL a través de HTTP ? explica que las CRL siempre están firmadas, por lo que no es una vulnerabilidad publicar las CRL a través de HTTP. ¿Qué pasa con OCSP?

(Algo relacionado con ¿Alguna tecnología funciona? ¿Impedir que una CA revoque unilateralmente un certificado? )

tls certificate-authority

pregunta Phil Lello 21.03.2016 - 14:15

fuente

2 respuestas

Lea otras preguntas en las etiquetas tls certificate-authority

¿Importa la fortaleza de la contraseña en bcrypt? ¿Qué hacen los “modos privados” de los distintos navegadores?

score 21 · Answer 1

21

Las respuestas de CRL y de OCSP están firmadas por la CA. Esto significa que cualquier tipo de manipulación ya será detectada incluso si la respuesta de CRL u OCSP se transfiere mediante un transporte inseguro. Por lo tanto, no es necesaria la protección contra manipulación indebida que ofrece https.

respondido por el Steffen Ullrich 21.03.2016 - 14:20

fuente

score 4 · Answer 2

CRL / OCSP es (en mi opinión) el eslabón débil en el modelo de seguridad de CA; el hecho de que estén firmados por la CA impide que un atacante haga que un certificado revocado parezca legítimo, pero siempre puede DOS un certificado legítimo interceptando / bloqueando la respuesta CRL / OCSP. Sin una CRL / OCSP válida, el certificado no debe validarse.

Para las CA públicas, no hay nada que puedas hacer al respecto, pero para las PKI corporativas privadas puedes alojar tus CRL en un recurso compartido de red autenticado dentro de una VPN (y trucos similares para OCSP) haciendo que sea casi imposible que el atacante sepa cuál devuelva el paquete al bloque, a menos que solo bloquee toda su conexión VPN.