De la descripción, uno puede inferir que el ataque funciona de la siguiente manera (advertencia: escribí "inferir" y lo digo en serio, no lo he intentado):

• El atacante está en posición de interceptar todo el tráfico de red de la víctima (por ejemplo, el atacante opera el punto de acceso WiFi al que la víctima está conectada de manera imprudente).

• El atacante posee (¡legítimamente!) un dominio, llamémoslo "evilattacker.com" y compró un certificado completamente válido con ese nombre en él; a saber, el atacante posee un certificado A , que contiene el nombre www.evilattacker.com , y está firmado por alguna raíz de confianza V . El atacante inserta una copia de ese certificado (la clave pública) en un sitio web de acceso público, por ejemplo, su propio sitio; la URL correspondiente puede ser (por ejemplo) http://www.evilattacker.com/cert.crt (también podría estar en cualquier tipo de alojamiento público, no importa).

• La víctima desea conectarse a su sitio bancario. Su navegador intenta abrir una sesión SSL con www.bank.com .

• El atacante intercepta esa conexión y pretende ser el banco. A tal efecto, el atacante envía una cadena de certificado C , X (en ese orden) donde:

  • C es un certificado sintético que contiene el nombre www.bank.com y está firmado con la propia clave privada del atacante y contiene un Authority Information Access extension con una URL igual a http://www.evilattacker.com/cert.crt (es decir, apuntando a donde el atacante ha publicado su propio certificado C ).
  • X es basura aleatoria.

• El cliente (el navegador de la víctima) no podrá validar la cadena C , X , ya que X es basura aleatoria. Si el navegador usa un OpenSSL antiguo, entonces las cosas se detienen allí y se informa un error de conexión. Sin embargo, si el navegador usa una nueva versión afectada de OpenSSL, intentará reconstruir una cadena alternativa, siguiendo la URL que se encuentra en C . En particular, el navegador descargará A (el certificado del atacante) y luego V (la autoridad de certificación externa y de confianza), y terminará con C , A , V chain.

• Si no hubiera ningún error, entonces el cliente rechazaría esa nueva cadena C , A , V porque aunque todos las firmas criptográficas coinciden, el certificado del medio A carece de Basic Constraints extension con el indicador cA establecido en TRUE : el certificado del atacante no es un certificado de CA, por lo que no puede aparecer en medio de una cadena válida. Sin embargo, debido al error, en esa situación específica, las versiones afectadas de OpenSSL no pueden verificar el indicador cA en la extensión Basic Constraints , y aceptan que C , A , V la cadena como válida. El navegador está convencido de que habla con el servidor de banco original y continúa sin previo aviso. El atacante ahora puede ejecutar un ataque Man-in-the-Middle y saquear la cuenta bancaria de la víctima .

Irónicamente, el hecho de que no se haya verificado la extensión Basic Constraints para los certificados intermedios también fue un error en Windows / Internet Explorer alrededor de 2003, y Microsoft fue debidamente burlado por eso; los desarrolladores de OpenSSL, por lo tanto, simplemente perdieron todos los derechos a semejante burla.

El error afecta a todas las aplicaciones que usan una versión afectada de OpenSSL (no muchas, ya que el código de error se agregó recientemente) y está en posición de procesar una cadena de certificados enviada por un par potencialmente hostil. Esto significa SSL clientes (al validar un certificado de servidor); esto también significa que los servidores SSL en sí mismos, cuando (y solo cuando) estos servidores solicitan certificados a los clientes (la autenticación de clientes basada en certificados es bastante raro en la web de todos los días).