Cómo funcionan realmente HTTPS y TLS: Guía práctica

Por qué HTTPS es importante (y por qué deberías entenderlo)

Probablemente hayas visto el icono del candado en tu navegador y sepas que HTTPS cifra el tráfico. Pero cuando aparece un error de certificado o una llamada a la API falla con un error TLS, ¿sabes exactamente qué está pasando? Muchos desarrolladores tratan HTTPS como una caja negra, hasta que algo se rompe. Esta guía desglosa cómo funcionan realmente HTTPS y TLS, desde el handshake hasta la cadena de certificados, para que puedas depurar problemas con confianza.

Lo básico: HTTPS = HTTP + TLS

HTTPS es simplemente HTTP sobre TLS (Transport Layer Security). TLS proporciona tres garantías:

• Cifrado: Los datos se codifican para que los espías no puedan leerlos.
• Autenticación: Estás hablando con el servidor real, no con un impostor.
• Integridad: Los datos no pueden modificarse en tránsito sin ser detectados.

Antes de TLS 1.3, el protocolo se llamaba SSL (Secure Sockets Layer), pero SSL está obsoleto. Hoy en día, TLS 1.2 y 1.3 son los estándares.

El handshake TLS: paso a paso

El handshake es donde ocurre la magia. Es una conversación que establece un canal seguro antes de que se envíen datos HTTP. Aquí tienes una versión simplificada para TLS 1.2 (TLS 1.3 es más rápido pero similar en concepto):

1. Client Hello: El cliente envía las versiones de TLS compatibles, las suites de cifrado y un valor aleatorio (Client Random).
2. Server Hello: El servidor elige una versión de TLS y una suite de cifrado, envía su propio valor aleatorio (Server Random) y presenta su certificado.
3. Verificación del certificado: El cliente comprueba el certificado contra las CA raíz de confianza, la expiración y el nombre de dominio.
4. Intercambio de claves: Usando algoritmos como ECDHE, ambas partes derivan un secreto compartido (pre-master secret) sin enviarlo nunca por la red.
5. Finished: Ambos lados verifican la integridad del handshake y cambian a comunicación cifrada usando claves simétricas derivadas del secreto compartido.

En TLS 1.3, el handshake se reduce a un solo viaje de ida y vuelta (1-RTT) e incluso admite 0-RTT para sesiones reanudadas, mejorando la latencia.

Por qué el cifrado asimétrico solo se usa inicialmente

La criptografía asimétrica (como RSA o ECDSA) es lenta y computacionalmente costosa. TLS la usa solo para intercambiar de forma segura una clave de sesión simétrica, que luego se utiliza para el cifrado masivo (por ejemplo, AES-GCM o ChaCha20-Poly1305). Este enfoque híbrido equilibra seguridad y rendimiento.

Certificados y la cadena de confianza

Un certificado vincula una clave pública a un nombre de dominio y está firmado por una Autoridad de Certificación (CA). Los navegadores y sistemas operativos incluyen un almacén de CA raíz de confianza. Cuando un servidor presenta su certificado, el cliente construye una cadena desde el certificado del servidor hasta una CA intermedia y finalmente hasta una raíz de confianza.

Los errores de certificado comunes incluyen:

• Certificado expirado: El período de validez del certificado ha terminado.
• Nombre de host no coincide: El Nombre Alternativo del Sujeto (SAN) del certificado no coincide con el dominio solicitado.
• Emisor no confiable: La CA raíz no está en el almacén de confianza del cliente (por ejemplo, certificados autofirmados).
• Cadena incompleta: El servidor no envió los certificados intermedios, por lo que el cliente no puede construir una ruta hasta una raíz de confianza.

Herramientas como openssl s_client o verificadores SSL en línea ayudan a diagnosticar estos problemas.

Depuración de conexiones HTTPS

Cuando HTTPS falla, necesitas inspeccionar el handshake. Aquí tienes comandos prácticos:

# Check certificate details and chain
openssl s_client -connect example.com:443 -servername example.com -showcerts

# Verify TLS version and cipher
openssl s_client -connect example.com:443 -tls1_3

# Test certificate expiration
openssl s_client -connect example.com:443 2>/dev/null | openssl x509 -noout -dates

En los navegadores, el panel de Seguridad de las Herramientas de Desarrollo muestra los detalles de la conexión, y curl -v https://example.com revela los pasos del handshake.

Errores de configuración TLS comunes

Incluso con HTTPS habilitado, una mala configuración puede debilitar la seguridad o romper la compatibilidad:

Cómo inspeccionar TLS en la práctica

Si estás depurando un servidor web, empieza comprobando la cadena de certificados y la suite de cifrado. Para Nginx, asegúrate de que tu configuración incluya la cadena completa:

ssl_certificate /path/to/fullchain.pem;
ssl_certificate_key /path/to/privkey.pem;
ssl_protocols TLSv1.2 TLSv1.3;
ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256';

Usa herramientas en línea como SSL Labs para obtener un informe completo, pero verifica siempre con herramientas de línea de comandos para comprobaciones rápidas.

Preguntas frecuentes

¿Cuál es la diferencia entre TLS y SSL?

SSL es el predecesor de TLS. Las versiones SSL 2.0 y 3.0 están obsoletas debido a vulnerabilidades de seguridad. TLS 1.2 y 1.3 son los protocolos seguros actuales.

¿Por qué mi navegador muestra una advertencia de certificado aunque el certificado sea válido?

Las causas comunes incluyen una cadena de certificados incompleta, una discrepancia en el nombre de host o que el certificado haya sido emitido por una CA no confiable para tu sistema. Verifica el SAN del certificado y asegúrate de que se sirvan los intermedios.

¿Cómo puedo comprobar qué versión de TLS admite mi servidor?

Usa openssl s_client -connect yourdomain.com:443 -tls1_3 (o -tls1_2) y busca el protocolo en la salida. Herramientas en línea como SSL Labs también proporcionan informes detallados.

Cuando necesites inspeccionar o formatear rápidamente datos JSON de respuestas de API durante la depuración, el JSON Formatter puede ayudarte a visualizar y validar la estructura.