Si sirves HTTPS, tu servidor casi con seguridad funciona sobre OpenSSL (o una implementación compatible). Nunca lo tocas directamente y, sin embargo, cuando se descubre un fallo, se ven afectados muchísimos servidores. Esto es lo que hace la biblioteca y cómo defenderla.
Dónde se usa
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 práctico: el cifrado se deja a una implementación compartida escrita por expertos. Pero cuando esa biblioteca compartida tiene una vulnerabilidad, todos los que la usan se ven afectados a la vez. Eso es lo que significa que un fallo de una biblioteca fundamental tenga un impacto amplio.
OpenSSL frente a SSL/TLS y los certificados
Los nombres se parecen y se confunden, pero cada uno cumple un papel distinto.
| Término | Qué es | Ejemplo |
|---|---|---|
| SSL / TLS | Las reglas (protocolo) para cifrar una conexión. SSL es la versión antigua; hoy se usa TLS 1.2 / 1.3 | HTTPS es HTTP envuelto en TLS |
| OpenSSL | El programa (biblioteca) que realiza las operaciones TLS y criptográficas, más una herramienta de línea de comandos incluida | Nginx y Apache la llaman internamente |
| Certificado | Datos con los que una autoridad de certificación garantiza que eres el titular de un dominio. Contiene una clave pública | Let's Encrypt los emite gratis |
Es decir, OpenSSL es una herramienta que implementa las reglas de TLS, y un certificado son datos que esa herramienta usa durante una conexión. Otras bibliotecas también implementan TLS (LibreSSL, BoringSSL, Schannel de Windows y más), y cuál usas depende del sistema operativo y del software.
Por qué el impacto es tan amplio: un solo fallo puso en riesgo las claves de muchos servidores
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 clara: cuanto más abajo en la pila está una dependencia, más amplio es el 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 las bibliotecas fundamentales
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. Si sigues ejecutando una versión EOL, las vulnerabilidades quedan sin corregir incluso después de descubrirse. Planifica las actualizaciones hacia una línea soportada.
Incluye las bibliotecas fundamentales 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 las bibliotecas fundamentales puedan desplegarse el mismo día cuando la gravedad lo exija, no «en la próxima actualización programada».
Versiones con soporte (a octubre de 2026)
El proyecto OpenSSL publica una versión de soporte a largo plazo (LTS) en abril de los años impares y le da soporte durante al menos cinco años. Las versiones no LTS publicadas después de 3.5 tienen soporte durante 13 meses desde su publicación.
| Línea | Tipo | Fin del soporte |
|---|---|---|
| 4.0 | Normal | 14 de mayo de 2027 |
| 3.6 | Normal | 1 de noviembre de 2026 |
| 3.5 | LTS | 8 de abril de 2030 |
| 3.4 | Normal | 22 de octubre de 2026 |
| 3.0 / 1.1.1 / 1.0.2 | — | Terminado (solo soporte extendido de pago de OpenSSL Corporation) |
El OpenSSL que trae tu sistema operativo es otra historia. Muchas distribuciones Linux, entre ellas las basadas en Red Hat, incorporan correcciones sin subir el número de versión (retroportado o backporting). Durante el periodo de soporte del sistema operativo, un paquete que sigue indicando 3.0 puede seguir recibiendo correcciones del proveedor del sistema. No juzgues «viejo significa vulnerable» ni «nuevo significa seguro» solo por el número; consulta los avisos de seguridad del proveedor de tu sistema operativo.
Cómo comprobar tu propio entorno
Comprueba el OpenSSL del sistema operativo
openssl version -a para ver la versión. Para la versión del paquete, usa dpkg -l 'libssl*' openssl en Debian/Ubuntu o rpm -q openssl en sistemas basados en Red Hat. Compara esa versión del paquete con los avisos de seguridad del proveedor de tu sistema operativo para ver si incluye la corrección.Comprueba qué usan realmente tus aplicaciones
nginx -V para Nginx, python3 -c "import ssl; print(ssl.OPENSSL_VERSION)" para Python y node -p process.versions.openssl para Node.js muestran la versión integrada.Comprueba también las imágenes de contenedor
Suscríbete a los anuncios de seguridad de OpenSSL
Cómo interpretar la gravedad de una vulnerabilidad
El proyecto OpenSSL clasifica sus propias vulnerabilidades en cuatro niveles y cambia la forma de publicar las correcciones según el nivel.
| Gravedad | Significado aproximado | Cómo se publica la corrección |
|---|---|---|
| Critical | Afecta a configuraciones habituales y es fácil de explotar (fuga importante de memoria del servidor, robo de claves privadas, etc.) | Se publica de inmediato una corrección para todas las versiones con soporte |
| High | Menos arriesgada que Critical pero aun así grave (configuraciones menos habituales, solo del lado del cliente, etc.) | Se prepara en privado y luego se publica para todas las versiones con soporte |
| Moderate | Limitada a denegación de servicio, protocolos poco habituales y similares | Se incluye en la siguiente versión programada |
| Low | Solo herramientas de línea de comandos, combinaciones de condiciones improbables y similares | Se incluye en la siguiente versión programada |
Un fallo como Heartbleed, en el que la memoria del servidor puede leerse desde fuera, encaja en la definición de Critical. En los casos Critical y High, empieza a preparar la actualización en cuanto veas el aviso previo.
Nuestra postura: monitoriza las bibliotecas fundamentales con máquinas
No puedes rastrear los fallos de las bibliotecas fundamentales con la memoria humana. Este sitio pone sus propias dependencias y bibliotecas fundamentales 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 listar las bibliotecas fundamentales en las que nunca piensas y monitorizarlas es la forma más directa de prevenir incidentes de gran alcance.
Sigue leyendo
- Aprende de un incidente: Heartbleed (un fallo de OpenSSL que puso en riesgo las claves privadas de muchos servidores)
- 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
Fuentes (primarias)
- OpenSSL Library, "Release Strategy" — openssl-library.org (política LTS, fechas de fin de soporte de cada línea)
- OpenSSL Library, "Security Policy" — openssl-library.org (cuatro niveles de gravedad, aviso previo)
- Red Hat, "Backporting Security Fixes" — access.redhat.com (por qué el número de versión por sí solo no indica si eres vulnerable)
- NIST NVD, "CVE-2014-0160" — nvd.nist.gov (Heartbleed)