TryQuickToolBox

Cómo funcionan realmente HTTPS y TLS: handshake y certificados

Security2026-10-30TryQuickToolBox

Por qué HTTPS es importante (y por qué se malinterpreta)

Probablemente hayas visto el icono del candado en tu navegador y hayas asumido que el sitio es "seguro". Pero, ¿qué significa eso realmente? HTTPS no se trata solo de cifrado; se trata de identidad, integridad y confianza. Muchos desarrolladores tratan TLS como una caja negra: lo configuran una vez y lo olvidan. Eso lleva a configuraciones incorrectas, certificados caducados y suites de cifrado vulnerables.

En este artículo, desglosaremos cómo funcionan realmente HTTPS y TLS, desde el handshake hasta la validación de certificados, y te mostraremos cómo configurarlo correctamente. Sin rodeos, solo conocimiento práctico que puedes aplicar hoy.

El handshake TLS: qué sucede antes del primer byte

Cuando un cliente (navegador) se conecta a un servidor a través de HTTPS, realizan un handshake TLS. Esto establece un canal seguro. Aquí tienes una versión simplificada (TLS 1.3):

  1. Client Hello: El cliente envía las suites de cifrado compatibles, un valor aleatorio y una clave compartida (para el intercambio de claves).
  2. Server Hello: El servidor elige una suite de cifrado, envía su propio valor aleatorio y clave compartida, y presenta su cadena de certificados.
  3. Autenticación: El cliente verifica el certificado del servidor contra las CA de confianza y comprueba el nombre de host.
  4. Derivación de claves: Ambas partes calculan el secreto compartido usando ECDHE (Diffie-Hellman efímero de curva elíptica).
  5. Finished: Ambos envían mensajes "Finished" cifrados para confirmar el handshake.

Después de esto, los datos de la aplicación se cifran con claves simétricas. TLS 1.3 reduce los viajes de ida y vuelta a uno, mejorando la latencia.

Intercambio de claves: ECDHE vs RSA

Las versiones anteriores de TLS usaban intercambio de claves RSA, que carece de secreto directo (forward secrecy). Si la clave privada del servidor se ve comprometida, el tráfico pasado puede descifrarse. Las configuraciones modernas usan ECDHE, que proporciona secreto directo: cada sesión tiene claves únicas.

# Ejemplo: Verificar algoritmos de intercambio de claves compatibles
openssl s_client -connect example.com:443 -cipher 'ECDHE'

Certificados: los anclajes de confianza

Un certificado vincula una clave pública a una identidad (nombre de dominio). Está firmado por una Autoridad de Certificación (CA) en la que el cliente confía. Los navegadores incluyen un almacén de CA raíz de confianza.

Cuando visitas un sitio, el servidor envía una cadena: certificado de hoja (para tu dominio) → CA intermedia → CA raíz. El cliente verifica cada firma hasta una raíz de confianza.

Tipos de certificados

Pasos de validación de certificados

Los navegadores comprueban:

Si alguna comprobación falla, recibes una advertencia. Nunca omitas estas advertencias en producción.

Configurar HTTPS en tu servidor

Veamos una configuración típica de Nginx para HTTPS con ajustes TLS modernos.

server {
    listen 443 ssl http2;
    server_name example.com;

    ssl_certificate /etc/letsencrypt/live/example.com/fullchain.pem;
    ssl_certificate_key /etc/letsencrypt/live/example.com/privkey.pem;

    ssl_protocols TLSv1.2 TLSv1.3;
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384';
    ssl_prefer_server_ciphers off;

    # HSTS (usar con precaución)
    add_header Strict-Transport-Security "max-age=63072000" always;
}

Notas:

Obtener certificados con Let's Encrypt

Let's Encrypt proporciona certificados DV gratuitos. Usa Certbot para automatizar la emisión y renovación:

sudo certbot --nginx -d example.com -d www.example.com

Certbot modifica tu configuración de Nginx y configura una tarea cron para la renovación. Siempre prueba la renovación con --dry-run.

Errores comunes y cómo evitarlos

Probar tu configuración HTTPS

Usa herramientas en línea como SSL Labs o herramientas de línea de comandos para verificar tu configuración.

# Verificar detalles del certificado
openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -text

# Probar compatibilidad con TLS 1.3
openssl s_client -connect example.com:443 -tls1_3

Busca:

Preguntas frecuentes

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

SSL es el predecesor de TLS. TLS 1.0 era esencialmente SSL 3.1. Hoy en día, "SSL" se usa a menudo coloquialmente, pero siempre debes usar TLS 1.2 o 1.3.

¿Necesito un certificado de pago para HTTPS?

No. Los certificados DV gratuitos de Let's Encrypt son confiables para todos los navegadores principales y proporcionan el mismo cifrado que los de pago. Los certificados de pago ofrecen garantías y soporte, pero el cifrado es idéntico.

¿Cómo afecta HTTPS al rendimiento?

TLS agrega latencia debido al handshake, pero TLS 1.3 lo reduce a un viaje de ida y vuelta. Con la reanudación de sesión y HTTP/2, la sobrecarga es mínima. Los costos de cifrado/descifrado son bajos en las CPU modernas.

¿Listo para inspeccionar la configuración TLS de tu servidor? Usa nuestro Analizador de registros de Nginx para detectar patrones de tráfico inusuales y asegurarte de que tu configuración HTTPS funcione como se espera.