Hoy en día vemos muchas conexiones HTTPS cifradas. Sin embargo, tener un certificado SSL/TLS válido no significa que el servidor esté configurado de forma segura. Las evaluaciones de seguridad a menudo revelan que los servidores web tienen habilitado un cifrado inseguro, admiten versiones TLS obsoletas o tienen certificados creados incorrectamente. A veces, estos problemas de configuración pasan desapercibidos durante años, hasta que un atacante los explota activamente o un escáner de seguridad activa una alarma.
Auditar la configuración TLS de un servidor consiste en revisar seis frentes antes de aplicar cambios: las versiones de protocolo activas, los conjuntos de cifrado, la implementación de los certificados, los encabezados de seguridad HTTP, el grapado de OCSP y ALPN, y una prueba externa que confirme cómo se expone el servidor desde fuera.
Antes de realizar cualquier cambio, revisa la configuración actual
Toda auditoría de la configuración TLS empieza por documentar el estado de seguridad actual del servidor, antes de hacer cualquier cambio. Para ello, un test de TLS resulta útil. Estas pruebas analizan la cadena de certificados, las versiones TLS compatibles, los conjuntos de cifrado disponibles y características de seguridad importantes como HSTS o el grapado de OCSP. Esto proporciona una visión amplia de la configuración actual y resalta posibles problemas antes de tocar nada.
Paso 1: ¿Qué versiones de TLS admite el servidor?
Normalmente, lo primero es revisar los protocolos compatibles. En la actualidad, solo TLS 1.2 y TLS 1.3 se consideran seguros. Las versiones más antiguas, como SSL 2.0, SSL 3.0, TLS 1.0 o TLS 1.1, deben estar deshabilitadas.
Por ejemplo, los servidores web y las aplicaciones más antiguas suelen haberse modificado a lo largo de los años sin que se altere toda la configuración original. Como resultado, todavía se utilizan protocolos obsoletos, incluso cuando ya no hay necesidad de ellos.
Paso 2: Verifica la lista de conjuntos de cifrado disponibles
Los distintos métodos de cifrado ofrecen diferentes niveles de seguridad. Algoritmos modernos como AES-GCM o ChaCha20-Poly1305 cumplen hoy con los requisitos de seguridad, mientras que RC4, DES y 3DES se consideran obsoletos.
En nuestras auditorías también confirmamos que PFS (Perfect Forward Secrecy, secreto perfecto hacia adelante) esté habilitado. PFS genera una clave de corta duración para cada conexión: aunque una clave privada se vea comprometida más adelante, las conexiones registradas previamente no se pueden descifrar de forma retroactiva.
Paso 3: Lee los certificados detenidamente
Muchos problemas de TLS no vienen solo del certificado emitido, sino de cómo se implementa dentro del servicio.
Cuando auditamos, verificamos:
- La validez del certificado.
- Si está presente la cadena completa de certificados.
- La fecha de vencimiento del certificado y los algoritmos de firma que se utilizan actualmente.
- Si el nombre de host y el certificado coinciden.
La falta de certificados intermedios es una de las razones más comunes por las que los navegadores y las aplicaciones móviles muestran advertencias o no logran conectarse.
Paso 4: Verifica los encabezados de seguridad HTTP
Un protocolo de enlace (handshake) TLS seguro no basta para proteger por completo un sitio web. Por eso la configuración HTTP —y en concreto revisar los encabezados de seguridad— debe formar parte de cada auditoría.
De especial importancia son los siguientes:
- HTTP Strict Transport Security (HSTS)
- Content Security Policy (CSP)
- X-Content-Type-Options
- X-Frame-Options
- Referrer-Policy
Entre otras cosas, estos encabezados mejoran la resistencia frente a ataques de intermediario (man-in-the-middle), clickjacking y la carga accidental de contenido peligroso, según el encabezado concreto y la política aplicada en cada caso.
Paso 5: Verifica el grapado de OCSP y ALPN
Muchos administradores solo se fijan en los certificados y el cifrado, por lo que funciones como ALPN y el grapado de OCSP a menudo se ignoran.
El grapado de OCSP (OCSP stapling) acelera la comprobación de certificados y mejora la privacidad del usuario, al evitar que el cliente consulte directamente al respondedor de la autoridad de certificación. Conviene tener presente que solo aporta si esa autoridad mantiene respondedores OCSP activos: algunas CA mayoritarias —como Let’s Encrypt— han retirado el soporte de OCSP en favor de las listas de revocación de certificados (CRL). ALPN determina la aplicabilidad de protocolos modernos como HTTP/2 y HTTP/3. Estas funciones mejoran la seguridad y el rendimiento de la conexión en planos distintos, aunque no mejoran el cifrado directamente.
Paso 6: Realiza una prueba de servidor externa
Una auditoría nunca debe basarse únicamente en los archivos de configuración internos. Es importante comprobar cómo se expone el servidor desde el exterior.
Por eso recomendamos probar el servidor con regularidad mediante herramientas externas para verificar SSL/TLS. Los escáneres externos suelen descubrir problemas como versiones de TLS obsoletas, cadenas de certificados faltantes o conjuntos de cifrado mal configurados que no son visibles desde dentro. Además, los fabricantes de navegadores y los grupos de seguridad actualizan sus especificaciones con frecuencia, así que conviene contrastar tu configuración con las últimas recomendaciones del Mozilla SSL Configuration Generator.
La ausencia de estas inspecciones genera peligros injustificados. Los fallos de seguridad pueden permanecer latentes durante meses, o incluso años. Las consecuencias pueden ser graves, como demostró el ciberataque de 2020 a la empresa de software estadounidense SolarWinds. Un virus malicioso se incrustó en una actualización de software de rutina descargada por miles de usuarios, incluidas grandes corporaciones y organismos gubernamentales. El suceso subrayó la importancia de realizar evaluaciones de seguridad periódicas y mantener una vigilancia continua de la infraestructura de TI.
