Fundamentos de TLS
Transport Layer Security (TLS) es el protocolo que pone la “S” en HTTPS. Proporciona cifrado, autenticación e integridad de datos para comunicaciones de red. Para ingenieros QA, entender TLS es esencial porque certificados mal configurados causan caídas, los headers de seguridad previenen ataques y el contenido mixto rompe la funcionalidad de páginas.
TLS 1.2 vs TLS 1.3
TLS 1.2 ha sido el estándar desde 2008, pero TLS 1.3 (2018) trajo mejoras significativas:
| Característica | TLS 1.2 | TLS 1.3 |
|---|---|---|
| Handshake | 2 round-trips | 1 round-trip |
| 0-RTT | No soportado | Soportado (sesiones resumidas) |
| Cipher suites | Muchos (incluyendo débiles) | Solo 5 suites fuertes |
| Forward secrecy | Opcional | Obligatorio |
El handshake de TLS 1.3 es más rápido y simple. El cliente envía su key share en el primer mensaje, permitiendo al servidor derivar la clave de cifrado inmediatamente.
El Proceso de Handshake
Cada conexión HTTPS comienza con un handshake TLS:
- ClientHello: El cliente envía versiones TLS soportadas, cipher suites y un valor aleatorio
- ServerHello: El servidor selecciona versión TLS y cipher suite, envía su certificado
- Verificación de certificado: El cliente valida la cadena de certificados contra CAs confiables
- Intercambio de claves: Ambos lados generan claves secretas compartidas
- Finished: Comienza la comunicación cifrada
Cadena de Certificados
Una cadena de certificados establece confianza desde el servidor hasta una autoridad reconocida:
- Certificado leaf: Instalado en el servidor, contiene el nombre de dominio
- Certificado(s) intermedio(s): Emitidos por la CA, conectan leaf con root
- Certificado raíz: Pre-instalado en el trust store del SO/navegador
Si falta algún certificado intermedio, algunos clientes fallan al validar la cadena — un bug común que solo aparece en dispositivos o navegadores específicos.
Checklist de Testing SSL/TLS
Validez del Certificado
- Certificado no expirado (verificar fecha
notAfter) - Nombre de dominio coincide con Subject o campos SAN del certificado
- Cadena de certificados completa (sin intermedios faltantes)
- Certificado emitido por una CA confiable (no self-signed en producción)
- Estado de revocación limpio (verificación OCSP/CRL)
Configuración de Protocolo
- TLS 1.2 y 1.3 habilitados
- TLS 1.0 y 1.1 deshabilitados
- SSL 2.0 y 3.0 deshabilitados
- Solo cipher suites fuertes (sin RC4, 3DES o cifrados export)
- Forward secrecy habilitado (intercambio de claves ECDHE)
Headers de Seguridad
- Header HSTS presente con
max-ageapropiado - Sin contenido mixto (recursos HTTP en páginas HTTPS)
- Atributos de cookie seguros (
Secure,HttpOnly,SameSite) - Redirect HTTP a HTTPS configurado
Herramientas de Testing SSL
openssl s_client
# Conectar y mostrar detalles del certificado
openssl s_client -connect example.com:443 -servername example.com
# Verificar expiración
openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
# Verificar cadena de certificados
openssl s_client -connect example.com:443 -showcerts
# Testear versión TLS específica
openssl s_client -connect example.com:443 -tls1_2
openssl s_client -connect example.com:443 -tls1_3
Qualys SSL Labs
El escáner online gratuito en ssllabs.com/ssltest proporciona calificación integral (A+ a F) y análisis detallado de configuración TLS, cipher suites, cadena de certificados y vulnerabilidades conocidas.
Testing TLS Avanzado
Certificate Pinning (Apps Móviles)
Certificate pinning incrusta el certificado esperado o clave pública en la app móvil, rechazando cualquier otro certificado. El testing requiere:
- Verificar que la app rechace conexiones con certificados incorrectos
- Testear rotación de pin: cuando el certificado cambia, ¿la app se actualiza correctamente?
- Verificar network security config en Android (
network_security_config.xml)
Mutual TLS (mTLS)
En mTLS, tanto cliente como servidor presentan certificados:
# Testear con certificado de cliente
openssl s_client -connect api.example.com:443 \
-cert client.crt -key client.key
Escenarios de test: Cert de cliente válido, expirado, CA incorrecta, sin cert de cliente, cert revocado.
Testing de Auto-Renovación Let’s Encrypt
Si tu aplicación usa certificados Let’s Encrypt (validez 90 días), testea:
- El proceso de renovación funciona antes de la expiración
- El certificado se recarga sin reiniciar el servidor
- OCSP stapling continúa después de la renovación
- Sin downtime durante la rotación de certificados
Ejercicio Práctico
Audita la configuración SSL de un sitio web:
- Ejecuta un escaneo SSL Labs y documenta la calificación
- Usa openssl para verificar detalles del certificado, cadena y expiración
- Identifica vulnerabilidades (cifrados débiles, intermedios faltantes)
- Documenta hallazgos con niveles de severidad
- Recomienda correcciones específicas
Enfoque de Solución
# Detalles del certificado
openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -text | head -30
# Verificar expiración
echo | openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates
# Verificar protocolos soportados
for proto in tls1 tls1_1 tls1_2 tls1_3; do
echo -n "$proto: "
echo | openssl s_client -connect example.com:443 -$proto 2>/dev/null | grep "Protocol"
done
Pro Tips
- Configura alertas de expiración de certificados — certificados expirados causan caídas, no solo advertencias
- Testea con TLS 1.0/1.1 deshabilitados para asegurar que nada se rompa
- Verifica que los SANs del certificado coincidan con todos los dominios esperados
- Verifica redirect HTTP a HTTPS y header HSTS en cada despliegue
- Testea desde múltiples clientes (navegador, móvil, herramienta API)
Puntos Clave
- La configuración SSL/TLS es un área de testing crítica — misconfigurations causan caídas y vulnerabilidades
- La gestión del ciclo de vida del certificado necesita testing continuo
- Herramientas como SSL Labs proporcionan una primera pasada fácil; openssl proporciona investigación manual detallada
- El testing de contenido mixto es esencial para cualquier migración o despliegue HTTPS