¿La publicación de CRL a través de HTTP es una vulnerabilidad potencial?

No existe tal cosa como una CRL no firmada; el campo de la firma es obligatorio, y cualquier sistema que use la CRL verificará la firma.

En pure X.509 , una CRL se considerará "aceptable" como fuente de información sobre el estado de revocación de un certificado dado E si está firmado por un "emisor de revocación permitido": la firma de la CRL debe coincidir con la clave pública contenida en un certificado ya validado, cuyo subjectDN es igual al issuerDN de E (puede tener un DN distinto si E contiene la extensión de punto de distribución de CRL relevante y el CRL tiene una extensión de punto de distribución de Emisor coincidente; Pero olvidemos esta complejidad adicional. Las reglas completas están expuestas en sección 6.3 . Tenga en cuenta que se supone que "X.509 puro" funciona en el contexto del Directorio, el tipo de servidor LDAP mundial que hace referencia a todo lo que se encuentra bajo Nombres Distinguidos e inequívocos.

Dado que el Directorio realmente no funciona, porque no existe, las implementaciones existentes tienden a implementar reglas más estrictas y simples. En general, un navegador web que valida un certificado E emitido por CA C aceptará un CRL solo si también está firmado por la misma CA, con la misma clave. Esta regla mantiene la validación de ruta simple y acotada (de lo contrario, puede imaginar una situación en la que debe obtener una CRL para cada certificado en la ruta y cada CRL debe verificarse con otro certificado de emisor de CRL que requiere su propia validación de ruta, y así en). Por lo tanto, es poco probable que la producción de su propia CRL en relación con su propia CA raíz tenga algún efecto real.

Las CRL, al igual que los certificados, son objetos que siempre están firmados y nunca se usan sin verificar esa firma (*), por lo que se pueden servir a través de HTTP simple. Usar HTTPS para servir CRL es solo un desperdicio de recursos; incluso puede impedir que la descarga de CRL funcione, ya que algunas implementaciones (por ejemplo, Windows) se niegan a seguir la URL de HTTPS al validar certificados (ya sea para CRL, OCSP o descargas de CA intermedias adicionales), porque eso significaría SSL, luego otro certificado para validar, y posiblemente un bucle sin fin.

^{(*) Aquí excluyo "certificados" de CA raíz, tradicionalmente autofirmados; estos no son certificados reales en el sentido X.509, sino objetos que imitan las reglas de codificación de los certificados.}

Sobre el ataque de repetición, la CRL está marcada con la fecha de generación y una fecha para la próxima actualización . La siguiente fecha de actualización es obligatoria en el perfil PKIX. Si se revoca un certificado, el antiguo CRL se puede reproducir antes de nextUpdate si se usa un canal no seguro .

Me gustaría agregar que algunos (al menos) los navegadores Mozilla tienen una variable de configuración: security.OCSP.require (consulte IRL acerca de: config) que, de forma predeterminada, se establece en falso.

Parece que si security.OCSP.require se establece en "falso", el navegador debería recurrir a la verificación de la CRL en el URI del punto de distribución de la CRL nombrado, que es casualmente el mismo URI usado en el campo Acceso a la información de la autoridad donde probablemente se encontraría la firma de la AC y la CRL.

Empíricamente (al menos en Linux) si esta URL está bloqueada, al menos los navegadores Mozilla (Firefox, Sea Monkey, Chrome) aprobarán el certificado sin verificar si se ha revocado y reemplazado.

Tengo problemas para entender cómo esto no sería una vulnerabilidad, pero ese no era el quid de la pregunta original.

FYI: en Windows, la configuración de CRL y OCSP parece ser una función de la Política de grupo (Política de equipo local, Configuración de equipo, Configuración de Windows, Configuración de seguridad, Políticas de clave pública) y puede configurarse, pero al menos a partir de Windows 2003 no parece estar configurado de forma predeterminada. En Mac, esto podría ser mitigado aún más por Keychain, para aquellos inclinados a confiar en una tercera parte con sus contraseñas ...