Escenario de hombre en el medio para TLS

10

Considere el siguiente escenario: desea comunicarse de forma segura con a.com y solo confía en el certificado raíz de VeriSign.

a.com presenta un certificado firmado por VeriSign con CN = a.com, por lo que confía en que se está comunicando con a.com.

Eve también ha obtenido un certificado de VeriSign para su sitio b.com. De esta manera, podría crear un nuevo certificado con CN = a.com y firmarlo con el certificado que obtuvo de VeriSign.

De esta manera, Eve tiene un certificado para CN = a.com firmado por su certificado para b.com, el cual está firmado por VeriSign, por lo que también confiaría. ¿Qué es impedir que Eve realice un ataque de hombre en el medio?

    
pregunta Georgios Bitzes 03.04.2013 - 03:01
fuente

4 respuestas

11

Eve podría firmar un certificado que indique "a.com" como nombre, con su clave privada, pero el navegador de Bob no lo aceptará. Cuando el navegador de Bob valida una cadena de certificados, verifica todas las firmas, pero no solo la firma. El algoritmo de validación completo es intrincado; Consulte el estándar . En este caso, el navegador de Bob levantará una ceja metafórica cuando aplique el cheque (k) de la sección 6.1.4: el certificado de Eve es un certificado de "versión 3", pero no contiene una extensión Basic Constraints , o su extensión Basic Constraints tiene el indicador cA establecido en FALSE .

En pocas palabras, aunque la certificación es un tipo de delegación de poder, el poder para emitir certificados se especifica para requerir una delegación explícita, y no se realiza de forma predeterminada. Como dice @Terry, la CA comercial puede otorgar certificados de sub-CA, con el indicador cA establecido en TRUE , pero cobrarán mucho por eso. De hecho, vincularán por contrato a la sub-CA para cumplir con la Declaración de Práctica de Certificación de la CA (consulte allí para el CPS de Verisign). Las obligaciones contractuales incluyen muchas conversaciones con grandes cantidades de dinero con seguros y cosas por el estilo, de modo que una víspera sub-CA que emitiría certificados falsos sería arrastrada al olvido por la represalia legal de Verisign. No hacen ningún prisionero.

Las cosas no funcionaban de esa manera en el pasado. La primera versión de X.509 no admitía extensiones, por lo que los clientes tenían que encontrar alguna otra forma de verificar si una entidad dada tenía el poder de CA o no. Esto fue un inconveniente, ya que los navegadores tenían que elegir entre incrustar una lista creciente de "sub-CA permitidos", o simplemente confiar en todos los certificados con poder de CA (permitiendo así su ataque). Tenga en cuenta que hasta el año 2003 más o menos, hubo un error en Internet Explorer: ¡IE no comprobó la extensión Basic Constraints en absoluto! Cuando se descubrió esto, se reparó rápidamente, por supuesto ...

    
respondido por el Thomas Pornin 03.04.2013 - 14:58
fuente
6

Tiene un malentendido sobre cómo funciona el proceso de firma de certificados.

En la mayoría de las situaciones, Eve no puede firmar certificados con el certificado que obtiene de Verisign. El navegador rechazará el certificado firmado por Eve.

Para que Eve firme los certificados con el certificado que obtiene de Verisign, debe obtener un certificado que contenga la extensión de Restricción básica con el indicador cA establecido en TRUE . No hace falta decir que tales certificados son mucho más caros.

    
respondido por el Ayrx 03.04.2013 - 03:44
fuente
5

Estos certificados que podrían permitirle a Eve firmar un certificado para a.com a veces están disponibles, aunque son altamente controvertido . "Algunas CA han sido menos responsables en la emisión de dichos certificados (Trustwave, Turktrust , etc.), mientras que otros tienen controles estrictos (contractuales, políticas, auditorías) para evitar la creación de certificados que podrían usarse para los ataques MiTM.

GlobalSign, por ejemplo, tiene un producto que podría usarse para ataques MiTM en teoría, pero los requisitos contractuales y técnicos y las auditorías impiden tal uso (también, en teoría). En los casos en que los controles técnicos no son posibles, el cliente sería auditado y tendría los mismos requisitos técnicos que un CA independiente.

El mayor riesgo de crear certificados MiTM es una CA que está siendo pirateada (directamente a través de un distribuidor de confianza). Ha ocurrido en el pasado ( Comodo , DigiNotar ), y probablemente vuelva a suceder.

Sin embargo, como dijo Terry, los certificados normales que obtiene de una CA no pueden firmar otros certificados.

    
respondido por el Adam Caudill 03.04.2013 - 04:16
fuente
0

Básicamente, no puede firmar un certificado utilizando otro certificado. Los certificados solo contienen claves públicas.

  • Un certificado está firmado digitalmente mediante la clave privada (y algunos otros parámetros según el estándar que esté usando) del remitente.
    • VeriSign firma un certificado con su clave privada. Y su navegador valida el certificado usando el certificado de VeriSign (clave pública).
    • Si Eve quiere firmar un certificado, usará su clave privada, pero su navegador considerará que el certificado no es válido ya que no tiene el certificado digital de Eve en la lista de CA confiables.
respondido por el Shurmajee 03.04.2013 - 06:22
fuente

Lea otras preguntas en las etiquetas