Glosario
Qué es OpenSSL — la biblioteca bajo HTTPS, y cómo defenderla
OpenSSL es la biblioteca de código abierto que sustenta HTTPS (TLS/SSL) y el cifrado. La mayoría la usa de forma indirecta —heredada vía servidor web o sistema operativo—, así que un fallo se propaga por todo el mundo (Heartbleed).
Si sirves HTTPS, tu servidor casi con seguridad funciona sobre OpenSSL (o una implementación compatible). Nunca lo tocas directamente y, sin embargo, sus fallos llegan a todo el mundo: esto es lo que es esa biblioteca fundamental y cómo defenderla.
Dónde se sitúa — unos cimientos que «heredas»
Lo complicado de OpenSSL es que lo usas sin haberlo elegido nunca. Tu aplicación delega TLS en el servidor web, el servidor web delega el cifrado en OpenSSL, y ese OpenSSL lo trae el sistema operativo: una pila anidada.
Normalmente esto es una bendición: el cifrado se deja a una implementación compartida escrita por expertos. Pero cuando esos cimientos compartidos tienen un agujero, todos los que se apoyan encima se ven afectados a la vez. Eso es lo que significa que «un fallo de una biblioteca fundamental tiene un radio de impacto enorme».
Por qué da miedo: un solo fallo amenazó claves en todo el mundo
El Heartbleed de 2014 (CVE-2014-0160) vino de un pequeño error de implementación de OpenSSL (confiar en una longitud declarada sin validarla) que dejaba a un externo leer la memoria del servidor —que podía incluir claves privadas y datos de sesión— poco a poco. Como OpenSSL se usaba tan ampliamente, una enorme cantidad de servidores de todo el mundo se convirtió en objetivo simultáneamente (la historia completa → Heartbleed).
La lección es contundente: cuanto más fundamental es la dependencia, más amplio es el radio de impacto. Así que no se trata solo de las dependencias que tu aplicación importa directamente: las bibliotecas fundamentales como OpenSSL que corren por debajo merecen la misma seriedad en la monitorización y el parcheo.
Cómo defenderla: evita el EOL, monitoriza los cimientos
Conoce qué OpenSSL usa tu pila
No puedes defender lo que no puedes ver. Inventaría de qué OpenSSL (línea de versión y versión) dependen cada uno de tus servidores, imágenes base de contenedor y entornos de ejecución de lenguajes.
No ejecutes versiones en fin de soporte (EOL)
Una vez que una línea de versión queda sin soporte, las nuevas vulnerabilidades que se descubran en ella no reciben ninguna corrección. Ejecutar una versión EOL es dejar una puerta que no se cerrará ni siquiera tras encontrarse un agujero. Planifica las actualizaciones hacia una línea soportada.
Incluye los cimientos en la monitorización de CVE
Las dependencias de la aplicación son fáciles de rastrear con osv-scanner y similares, pero el OpenSSL que trae el sistema operativo es fácil de pasar por alto. Asegúrate de que también afloren los nuevos CVE de las bibliotecas fundamentales (→ el manual de remediación de CVE).
Parchea con rapidez cuando sea grave
Los fallos de la categoría de Heartbleed se atacan en el momento en que se divulgan. Mantén tu vía de actualización lo bastante ligera como para que los parches de los cimientos puedan desplegarse el mismo día cuando la gravedad lo exija, no «en la próxima actualización programada».
Nuestra postura: vigila los cimientos con máquinas
No puedes rastrear los fallos de las bibliotecas fundamentales con la memoria humana. Este sitio pone sus propias dependencias y cimientos bajo monitorización de CVE automatizada. Los certificados que sirves vía Let's Encrypt ejecutan igualmente su cifrado por debajo a través de una implementación de la familia OpenSSL, así que inventariar los «cimientos invisibles» y ponerlos bajo vigilancia es el camino más corto para prevenir incidentes de gran radio de impacto.
Lee a continuación
- Aprende de un incidente: Heartbleed (un fallo de OpenSSL que amenazó claves en todo el mundo)
- Relacionado: Qué es Let's Encrypt (certificados TLS gratuitos + renovación automática) / Glosario: Qué es un CVE
- En la práctica: el manual de remediación de CVE / monitoriza dependencias con osv-scanner
FAQ
QNunca instalé OpenSSL, ¿podría estar usándolo igualmente?
Casi con seguridad sí. OpenSSL es una biblioteca fundamental que usan internamente los servidores web (Nginx/Apache), los sistemas operativos y los entornos de ejecución de lenguajes. Aunque nunca lo referencies en tu código, si sirves HTTPS es muy probable que OpenSSL (o una implementación compatible) esté ejecutándose por debajo. Suponer «yo no lo uso» es exactamente como se pasan por alto las vulnerabilidades de las bases fundamentales.
Q¿En qué se diferencia de LibreSSL o BoringSSL?
Ambos son forks de OpenSSL. LibreSSL lo creó el proyecto OpenBSD tras Heartbleed para limpiar el código base; BoringSSL es la variante de Google para su propio uso. La mayoría de las personas no necesita elegir entre ellos: lo que importa mucho más es mantener la implementación que trae tu plataforma en una versión soportada y al día.
Q¿Cómo compruebo la versión o la actualizo?
En muchos sistemas `openssl version` la muestra, y la actualizas a través del gestor de paquetes de tu sistema operativo o reconstruyendo la imagen base de tu contenedor. Lo clave es no seguir ejecutando una versión en fin de soporte (EOL): una vez que una línea de versión llega a EOL, las nuevas vulnerabilidades que se descubran en ella no reciben corrección. Vigila tus dependencias fundamentales igual que vigilas las dependencias de tu aplicación.