Resumen

  • Debian corrigió en mayo de 2008 un cambio específico de su paquete OpenSSL que había reducido de forma drástica la imprevisibilidad de las claves. La actualización protegía las creaciones futuras, no las claves SSH, OpenVPN, DNSSEC o X.509 ya copiadas a otros sistemas.
  • El cierre exigía una cadena distribuida: identificar la procedencia, bloquear lo reconocible, generar una clave sana, autenticar el reemplazo, borrar la autorización anterior o revocar el certificado y comprobar que los actores relevantes rechazaban de verdad la credencial antigua.

«Desconocida» no quería decir «segura»

Entre todas las instrucciones publicadas tras CVE-2008-0166, una palabra describe mejor el problema: Unknown.

El nuevo programa ssh-vulnkey comparaba claves con listas de material débil conocido. Si encontraba una coincidencia, el diagnóstico era útil y accionable. Si devolvía Unknown (no blacklist information), Ubuntu advertía que no poseía información suficiente para clasificar esa clave. No era un visto bueno. Cuando la procedencia no podía establecerse con mucha certeza, había que sustituirla.

Esa diferencia permite entender por qué el incidente no terminó con una versión corregida de OpenSSL. El paquete sabía cómo generar el siguiente secreto. No llevaba un inventario de los secretos producidos durante los dos años anteriores. Tampoco conocía los servidores remotos que contenían la parte pública, los clientes que recordaban una clave de host, los pares VPN que compartían material ni las autoridades que habían emitido certificados sobre esas claves.

Una credencial débil podía tener un formato impecable. El servidor SSH podía verificar la prueba. Un certificado podía estar firmado y no haber caducado. El defecto no aparecía como un byte roto: estaba en el proceso histórico que había elegido el secreto dentro de un universo demasiado pequeño.

El origen fue local; la exposición viajó

El expediente Debian #363516 comenzó en abril de 2006 por los avisos de Valgrind sobre lecturas de memoria no inicializada en el generador de OpenSSL. La conversación técnica consideró cómo reducir esos avisos. El propio registro aclaró después que la modificación vulnerable realmente compilada apareció a partir de 0.9.8c-1, cuando el archivo modificado pasó a la ubicación utilizada por la construcción.

DSA-1571-1, publicado el 13 de mayo de 2008, calificó el fallo como específico de Debian. Recomendó recrear desde cero todo material criptográfico generado por las versiones afectadas. También separó el caso DSA: una clave sana podía quedar comprometida si se había usado para firmar en un sistema con el generador roto, porque la firma necesita un valor secreto aleatorio.

La documentación SSLkeys describió un modelo operativo de 32.767 identificadores de proceso para cada una de tres clases de arquitectura, 98.301 flujos posibles. No es una cuenta universal de claves ni de ataques. Las aplicaciones, longitudes y llamadas variaban. Sí demuestra que, para familias comunes, un atacante podía preparar candidatos y asociar una clave pública observada con una mitad privada calculable.

Ubuntu señaló la consecuencia más importante para el perímetro. Sus sistemas derivados estaban afectados directamente, pero una máquina con un OpenSSL sano podía importar y aceptar una clave creada en una máquina vulnerable. La exposición acompañaba a la credencial a través de una migración, una copia o un certificado. No respetaba la frontera del sistema operativo.

La infraestructura Debian aplicó un veto propio

Debian no esperó que el parche actuara como una revocación imaginaria. Poco después del aviso, deshabilitó el acceso por clave pública en los sistemas del proyecto. Los servicios que utilizaban claves para transferencias o reconstrucciones debían demostrar que la clave era segura o reemplazarla.

Al día siguiente, DSA-1576-1 añadió tres mecanismos distintos. Primero, una dependencia garantizaba que OpenSSH recibiera la biblioteca corregida. Segundo, openssh-blacklist permitía rechazar localmente claves débiles enumeradas. Tercero, ssh-vulnkey ayudaba a revisar claves de usuario, claves de host y archivos de autorización.

Ninguno de esos mecanismos distribuía por sí solo una identidad nueva. Regenerar la clave de host hacía que los clientes vieran el aviso de identidad modificada. El operador debía comunicar la nueva huella por un canal fiable. Desactivar la alerta habría agilizado el cambio al precio de eliminar la defensa local contra un intermediario.

Las claves de usuario viajaban en sentido contrario. El usuario creaba un par nuevo; luego había que colocar la parte pública en todos los servidores y eliminar la línea antigua de cada authorized_keys. Conservar ambas claves podía mantener la continuidad, pero también preservaba el acceso del secreto adivinable.

El 16 de mayo, DSA-1576-2 corrigió el propio detector. Las entradas con opciones al principio —por ejemplo, un comando forzado— podían quedar fuera del primer análisis. La herramienta podía declarar una visión incompleta mientras el servidor seguía aceptando la clave. Las posteriores actualizaciones de Ubuntu ampliaron tamaños RSA, solicitudes de certificados, módulos y otros formatos.

La automatización defensiva funcionó, pero solo dentro de un contrato estrecho: corpus conocido, analizador correcto, formato cubierto y aplicación receptora actualizada.

No existía un botón universal de revocación

CERT enumeró SSH, OpenVPN, DNSSEC y material X.509 entre las clases afectadas. Compartían una fuente defectuosa, no un mecanismo común de retiro.

En SSH de usuario, la autoridad residía en cada archivo remoto que admitía la clave. La prueba final consistía en intentar autenticar la clave antigua y observar su rechazo. En SSH de servidor, la confianza residía en la memoria de los clientes y en la autenticidad con que se comunicaba la nueva huella.

En OpenVPN, una clave compartida debía cambiar en todos los pares. Si se utilizaban certificados, además hacían falta una clave nueva, una emisión nueva y una política que impidiera aceptar el certificado viejo. USN-612-3 subrayó que el material generado para otros sistemas tenía que localizarse y reemplazarse en esos destinos.

En X.509, emitir un certificado de sustitución no borraba el anterior. El emisor podía revocarlo y publicar el estado; el servidor debía desplegar la nueva cadena; el cliente tenía que consultar o recibir información fresca. RFC 5280 define la lógica de certificados y listas de revocación, pero no obliga mágicamente a cada aplicación instalada a usar el estado más reciente.

En DNSSEC, una clave podía estar presente en delegaciones firmadas y cachés. En sistemas de automatización, podía esconderse dentro de imágenes, copias de seguridad, robots de despliegue o equipos de socios. Borrar un archivo en el generador original no cambiaba ninguna de esas decisiones externas.

Por eso la unidad de reparación era una relación, no una máquina: quién creó la clave, dónde se copió, qué afirmación firmaba, qué sistema la aceptaba y qué acto podía retirarla.

Cuando una prueba correcta dejó de probar lo que importaba

La criptografía verificaba una relación matemática entre la clave pública y la prueba ofrecida. No verificaba que el secreto siguiera siendo exclusivo de su propietario legítimo. Un atacante que hubiese reconstruido la clave privada podía producir una autenticación formalmente correcta.

La validez sobrevivía a la legitimidad.

La tesis de Lu Heng sobre el código en ejecución sirve aquí como lente declarada, no como fuente del relato histórico. Un boletín, una lista negra o una revocación son estados publicados. Producen efecto cuando el servidor, el par o el cliente aplica la regla. Debian controlaba sus paquetes y su infraestructura; no controlaba cada archivo de autorización al que había viajado una clave. Una máquina no afectada controlaba su propia puerta y seguía dentro del incidente si aceptaba un secreto importado.

Esto no convierte a cada actor en soberano ilimitado. Define competencias limitadas. El mantenedor corrige la producción. El detector aporta evidencia parcial. El operador reemplaza. El emisor modifica el estado del certificado. El sistema receptor conserva el veto final. La rendición de cuentas depende de que ninguna de esas funciones se haga pasar por la cadena completa.

El inventario que faltaba

La respuesta necesitaba registrar cuatro cosas enlazadas. La primera era la generación: fecha, versión de paquete, biblioteca, aplicación, arquitectura, algoritmo y tamaño. La segunda era la distribución: claves privadas, certificados, servidores, autorizaciones, pares, imágenes y copias.

La tercera era el reemplazo: huella vieja, huella nueva, canal usado para autenticar el cambio, responsable y fecha. La cuarta era el rechazo: prueba de que la clave anterior ya no entraba, el certificado viejo no era aceptado por los clientes probados y cualquier excepción tenía un alcance y una caducidad.

Un porcentaje de parches describe el primer paso. Solo el registro de rechazo describe el fin de la autoridad.

Límites de la evidencia

Las fuentes oficiales no ofrecen un censo total de claves débiles ni de explotaciones. Los 98.301 flujos son un modelo acotado, no un corpus universal. Unknown no demuestra seguridad ni debilidad. Las fechas de archivo pueden cambiar por copias o relojes incorrectos. GnuPG y GnuTLS no usaban esa fuente. La regeneración automática dependía del paquete y de la decisión administrativa. La reemisión de un certificado no demuestra que todos los clientes consultaran la revocación.

Lo probado es más útil que una cifra espectacular: la actualización cerró la generación futura por esa ruta; la autoridad pasada sobrevivió hasta que cada punto de aceptación la retiró.

Fuentes