¿Cómo verificar que el parche Heartbleed de OpenSSL es el correcto?

Question

¿Cómo verificar que el parche Heartbleed de OpenSSL es el correcto?

#1 de Lekensteyn (2 votos)

2

Al enterarme de la vulnerabilidad de Heartbleed, fui a https://www.openssl.org/source/ para descargar el último parche, pero me sorprendió bastante que el certificado de seguridad de ese sitio no se haya actualizado desde que se descubrió el exploit ("no es válido antes" la fecha es el martes 30 de agosto de 2011, 5:30:50 AM CT).

Entonces, ¿cómo puedo estar seguro de que lo que estoy viendo es el verdadero sitio de OpenSSL y no un impostor que robó su certificado (incluso antes de que se revelara la vulnerabilidad)?

En otras palabras, descargué https://www.openssl.org/source/openssl-1.0.1g.tar.gz , que dice que el mismo sitio tiene un MD5 de de62b43dfcd858e66a74bee1c834e959 , que sí, pero ¿es esa la huella digital correcta para ese parche? ¿O estoy descargando algo malicioso que tiene una nueva puerta trasera codificada?

ACTUALIZACIÓN: Tras la sugerencia de @Lekensteyn, verifiqué que la firma PGP proporcionada para esa descarga era válida y estaba firmada por la clave 0xFA40E9E2 , que parece ser la clave de Dr Stephen N Henson <[email protected]> (que el sitio web está de acuerdo con). Pero para estar seguro, asumo que no puedo confiar en el sitio web en este momento. ¿De qué otras maneras puedo obtener fe de que la clave 0xFA40E9E2 es la que debería estar firmando ese lanzamiento?

¿Alguien tiene una descarga de OpenSSL de la rama 0.9.8 (que no fue comprometida por Heartbleed y sería lo suficientemente antigua como para haber sido distribuida antes de la explotación), que puedan verificar que esté firmada por esa misma clave?

Preocupación: encontré this aviso de una actualización del sitio web de OpenSSL, justo antes de que se revelara la vulnerabilidad (2 de abril), y el cambio en el sitio fue para marcar la clave del Dr. Henson como caducada, y agregar 0xFA40E9E2 como su nueva clave, pero esa clave fue creado en 2005? Entonces, es una nueva clave para identificar al Dr. Henson, pero ¿esa es la clave que eligieron para firmar este parche súper importante para Heartbleed? ¿Eso le parece a alguien?

openssl heartbleed

pregunta MidnightLightning 11.04.2014 - 13:15

fuente

1 respuesta

Lea otras preguntas en las etiquetas openssl heartbleed

¿Debería cada proveedor de identidad de SAML proporcionar un certificado público único al proveedor de servicios? Falló la conexión segura (OCSP)

score 2 · Answer 1

Tu pregunta es en realidad:

¿Cómo puedo estar seguro de la autenticidad del archivo descargado?

Comencemos con los detalles que mencionaste. La suma de comprobación (MD5, SHA1, lo que sea) es una huella digital del archivo que le permite verificar la integridad del archivo. Es decir, si los datos han cambiado desde que se tomó la huella digital. Si obtiene la suma de comprobación de una fuente confiable, entonces puede asumir con seguridad que el archivo descargado es válido.

Si no confía en la suma de comprobación y desea autenticar el archivo, use la firma GPG si está disponible. Para el archivo de su pregunta, está disponible en enlace . Si confía en el firmante y la firma coincide con el archivo, puede asumir que el archivo descargado es válido. Si no conoces a nadie en su llavero, puedes buscar a otros que confíen en él. Por ejemplo, Debian tiene una copia de la clave de firma en enlace . Este secuencia de comandos Tor que contiene una huella digital de GPG de correo privado del Dr. Stephen Henson que ha firmado el openssl.org address.

Si eres realmente paranoico y tienes fuentes antiguas disponibles, puedes descargar el archivo, extraerlo y comparar las fuentes:

# Assume openssl-1.0.1f to be a known good source
tar xf openssl-1.0.1g.tar.gz
diff -Nur openssl-1.0.1f/ openssl-1.0.1g/

Esto requiere un cierto conocimiento del idioma en el que se escribió el programa (C para OpenSSL). Si alguien coloca una puerta trasera, es probable que no sea tan obvio como // backdoor requested by the NSA .

Otra alternativa es evitar la descarga única por completo y obtener las fuentes del repositorio de código fuente en enlace . Algunos archivos pueden ser diferentes entre el lanzamiento de tarball y el repositorio de git (como el script configure ), pero las fuentes deben ser las mismas.