Estoy leyendo la presentación de Black Hat de Jarmoc en Proxies de intercepción SSL / TLS y confianza transitiva . Tengo algunas preguntas sobre algunas de las prácticas clave de gestión.
En el documento, Jarmoc afirma:
Para actuar como servidor para la sesión SSL del lado del cliente, El proxy de intercepción debe tener acceso a la clave privada que Corresponde al certificado que está presentando. Porque el servidor la clave privada del punto final no está disponible, el proxy de intercepción debe genere un nuevo certificado y un par de claves para usar en esta sesión.
Jarmoc no explica el razonamiento detrás de su declaración "el proxy de intercepción debe generar un nuevo certificado y un par de claves para usar en la sesión". Y no define una "sesión" per se .
Pregunta : según la descripción de Jarmoc a continuación, ¿es justo leer una "sesión"? Es la conexión punto a punto [encriptada] entre el usuario y el proxy (y, por el contrario, el proxy y el servidor real)?
... los proxies de intercepción se insertan en el flujo de tráfico y terminar la solicitud del cliente. El proxy de intercepción hace un segundo. Solicitud en nombre del cliente al servidor. Este comportamiento causa lo que fue una sesión de extremo a extremo, en lugar de ser dos separadas, pero Relacionado, sesiones punto a punto. El objetivo es permitir el acceso a la contenidos de la sesión de texto sin formato mientras se transfiere entre los dos sesiones cifradas.
¿O debería leer la "sesión" para tener el significado de extremo a extremo?
¿Se pueden multiplexar "conexiones múltiples de un solo usuario" (flujo de usuario a proxy) y "conexiones de múltiples usuarios" (flujo de proxy a servidor) en una sola sesión?
Pregunta : ¿Por qué un proxy de intercepción debe generar un par de claves nuevo y un certificado para cada sesión?
Estos son los casos de uso que estaba ejecutando y no veo el beneficio de claves y certificados distintos:
-
dos usuarios distintos visitan example.com.
-
un solo usuario visita example.com , cierra el navegador y luego visita example.com de nuevo.
Proporcionar el mismo certificado y la misma clave pública para example.com es la forma en que funcionan las cosas sin un proxy de intercepción. ¿Cómo un certificado distinto y una clave pública para cada visitante y visita mejoran el paisaje?
He experimentado esto último, y puedo decirte que no hay nada "sigiloso" en la práctica (especialmente cuando la página web tiene muchos enlaces externos). CertPatrol lanzó tantos diálogos de advertencia que el navegador se volvió inutilizable.
Pregunta : ¿qué tiene de malo certificar una clave privada única (por ejemplo, 7 o 30 días) y luego emitir todos los certificados de servidor usando la clave única?
La generación de claves sobre la marcha es costosa y puede llevar a un DoS bajo carga. Dado que la práctica puede destruir la disponibilidad, no veo el beneficio.
No importa si hay 1 clave privada o 10,000 claves privadas. Un compromiso del host / compromiso clave en el proxy significa salida clave. No importa si hay 1 de ellos o 10,000 de ellos. Una vez más, no veo el beneficio.
Si algo más que una relación 1: 1 es mala, ¿por qué se usa la práctica en certificados de firma intermedios y CA subordinadas?
Pregunta : ¿significa Jarmoc que cada conexión de red (dirección IP de origen) debe recibir su propia clave privada utilizada para todos los certificados? (Aquí, "sesión" significa la interacción entre el usuario y el proxy).
Si el proxy va a reutilizar las claves privadas por usuario, ¿por qué no se puede reutilizar una clave privada para todos los usuarios?
¿Cómo maneja el proxy las conexiones NAT'd, donde los usuarios se agrupan en una única dirección IP orientada hacia adelante?
(Si hay algún error con la reutilización, es probable que los certificados de firma intermedios infrinjan la regla citada porque la clave de firma del intermediario certifica una cantidad de certificados de entidad final).
Pregunta : ¿cuáles son los detrimentos de la reutilización de la clave privada en las sesiones?
¿La clave privada reutiliza herramientas de ruptura como herramientas como HTTPS Everywhere y CertPatrol; ¿Y estrategias de diversificación de la seguridad como la fijación de claves públicas y perspectivas?
Mi preocupación aquí es una implementación ingenua de la fijación de claves públicas dentro de una organización, donde la implementación confía solo en la {clave pública}, y no en el par {host, clave pública}. Pero la implementación ingenua puede no romperse en la práctica mientras la clave privada en el proxy permanezca secreta. Es difícil de decir sin una implementación concreta.