Emisión comprometida CA

Lo has adivinado bien: la revocación es asíncrona . Cuando revoca un certificado, esto se vuelve realmente efectivo solo cuando expira la última CRL anterior a la revocación. Si emite CRL que son válidos por un año, otros sistemas pueden confiar en un certificado revocado hasta por un año.

Uno debería imaginar la CRL como una característica de contención de daños : con la CRL, puede tener un límite explícito sobre el tiempo durante el cual el compromiso afectará a sus sistemas. Los CRL de larga duración son más fáciles de emitir (ya que lo haces con menos frecuencia), pero, en consecuencia, tómate más tiempo para contener el daño. Esta es una compensación.

La única mitigación, dentro del contexto de una PKI X.509, es emitir CRL más a menudo, con una vida más corta. Sin embargo, dado que su CA raíz está fuera de línea (y eso es, en igualdad de condiciones, una muy buena idea), emitir una CRL implica una operación manual, por lo tanto, costos. Soy consciente de dos soluciones:

1. Podría hacer una CRL indirecta : mientras que la CA raíz está fuera de línea, el poder de firmar una CRL podría confiarse a un sistema en línea distinto con su propio par de claves. X.509 tiene soporte para eso, con extensiones relevantes (consulte esta respuesta ). Desafortunadamente, las CRL indirectas no están bien soportadas por el software existente.

2. Uno podría hacer que la CA raíz esté en línea. En una configuración que he ayudado a desarrollar y actualmente se implementa en producción, la CA raíz "fuera de línea" produce un CRL semanalmente y lo envía a través de ... su salida de audio. La idea es que el conector de "línea de salida" es físicamente unidireccional, por lo que incluso si hay un cable que va de ese enchufe al conector de "línea de entrada" de otra máquina (en línea), la CA raíz todavía se puede considerar como "desconectado". Además, una inspección visual puede notar fácilmente que el cable está en el enchufe correcto (el verde).

   Esta solución requiere algún software para codificar la nueva CRL como sonido y descodificarla en el otro extremo; El código simple que escribí ofrecía un rendimiento muy malo (alrededor de 300 bits / s), pero era muy robusto y el CRL semanal es muy corto (ya que, en condiciones normales, está completamente vacío). Como no hay confirmación (el enlace es realmente unidireccional), el remitente debe enviar el mismo archivo repetidamente, una y otra vez, con un encabezado reconocible para la sincronización y una suma de comprobación para la detección de errores (para una CRL, puede verificar la firma, eso es tan bueno como cualquier suma de control puede obtener). De esa manera, puede tener una CA raíz fuera de línea y aún así obtener una publicación de CRL automatizada semanalmente (incluso podría ser diaria).

   (Mi diseño inicial requería un altavoz y un micrófono reales, pero eso podría resultar problemático en un entorno ruidoso, y las salas de servidores son muy ruidosas. Las personas con algunos conocimientos de electrónica podrían construir un circuito con un LED y un fotodetector. Sin embargo, Otra forma es usar un cable Ethernet de par trenzado con solo un par conectado, pero esto puede dejar de funcionar con interfaces Ethernet que intentan hacer una detección de medios, y es más difícil de verificar visualmente, ya que tiene que desconectar el cable para verificar el cableado.)

Sí, la máquina puede confiar en el certificado de la CA Emisora hasta noviembre de 2016. Hay algunas "soluciones" en uso, principalmente en los navegadores web, cuando hay un certificado que "debe ser revocado":

• Iniciar una nueva versión del navegador, incluida la revocación. Realmente ineficiente, pero funciona.

• Chrome empuja las listas de revocación ( crlsets ) por separado en su canal de actualización.

• OCSP proporciona una manera de verificar en línea que el certificado no ha sido revocado. De esa manera, solo necesita enviar la revocación al servidor que maneja el OCSP. El problema es que el servidor OCSP se convierte en un punto único de falla, ya que debe tratar el certificado como no válido si no recibe una respuesta OCSP. Si falla, un MITM solo necesita bloquear la comprobación de OCSP (que, dado que son MITM, a menudo pueden) y la conexión se realizará correctamente. Consulte [1]

Un modelo de validación basado en CA falla ya que no es capaz de realizar la revocación de sí mismo; no hay agilidad de confianza cuando una CA raíz está comprometida, ya que tiene que reemplazar su ancla de confianza. Si esto es simplemente una CA emisora en lugar de una raíz, el evento de revocación puede tener éxito. Sin embargo, revisemos los enfoques básicos para la validación:

• Listas de revocación de certificados: una lista negra de certificados revocados Distribuido como un archivo. Los CRL grandes son difíciles de consumir y causar problemas de desempeño.

• OCSP sin Nonce: se puede producir en masa una respuesta repetible y en caché Pequeño, rápido y eficiente.

• OCSP con Nonce: una solicitud y respuesta de OCSP que incluye una nonce criptográfico; El OCSP sin experiencia siempre está activo. Pequeño, rápido, pero introduciendo un poco más de un éxito de rendimiento que un OCSP de vainilla solicitud / respuesta.

Anteriormente, OCSP estaba más orientado a ser una versión en vivo de los CRL, una lista negra. Sin embargo, los RFC más nuevos para OCSP también permiten el uso de OCSP como lista blanca también. Los enfoques combinados de lista negra y lista blanca para la validación son mucho más seguros.

Cuando piense en la validación, tenga en cuenta que puede, y debe considerar otras alternativas a los modelos de confianza basados en CA, particularmente para redes más grandes o redes donde se necesita la posibilidad de compromiso o flexibilidad de CA.

Si tengo la opción de producir CRL, OCSP, o ambos, siempre planeo utilizar ambos modelos, con preferencia al OCSP cerrado a prueba de fallas, complementado con CRL. En general, prefiero los esquemas de validación basados en VA, ya que tienen la capacidad de revocar CA comprometidas.

Ahora que he escrito todo esto, voy a responder tus preguntas

La validación basada en CRL casi siempre debería ser menos preferida que la validación basada en OCSP

Las CRL se pueden eliminar de un producto de TI, por ejemplo, en Windows

certutil -setreg chain\ChainCacheResyncFiletime @now