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

Security2026-10-26TryQuickToolBox

El problema: HTTPS está en todas partes, pero ¿cómo funciona realmente?

Ves el icono del candado en tu navegador y asumes que tu conexión es segura. Pero cuando algo sale mal—un error de certificado, una advertencia de contenido mixto o un handshake TLS lento—necesitas entender qué está pasando bajo el capó. Esta guía desglosa HTTPS y TLS en piezas prácticas y digeribles para que puedas depurar y optimizar conexiones seguras.

HTTPS es simplemente HTTP sobre TLS (Transport Layer Security). TLS proporciona cifrado, autenticación e integridad. Veamos cómo funciona, paso a paso.

Qué hace realmente TLS

TLS resuelve tres problemas fundamentales:

Sin TLS, el tráfico HTTP es texto plano—cualquiera en la ruta de red puede leerlo o modificarlo. TLS envuelve HTTP en un túnel cifrado.

El handshake TLS: paso a paso

Antes de que fluya cualquier dato HTTP, el cliente y el servidor realizan un handshake para acordar los parámetros de cifrado. Este es el flujo típico 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, los conjuntos de cifrado y un valor aleatorio.
  2. Server Hello: El servidor elige una versión de TLS y un conjunto de cifrado, y envía su propio valor aleatorio.
  3. Certificado: El servidor envía su cadena de certificados, incluida su clave pública y prueba de identidad.
  4. Intercambio de claves: Usando el certificado, el cliente y el servidor acuerdan de forma segura un secreto compartido (pre-master secret) utilizando algoritmos como ECDHE.
  5. Finished: Ambas partes verifican el handshake y cambian a comunicación cifrada usando claves simétricas derivadas del secreto compartido.

TLS 1.3 reduce esto a un solo viaje de ida y vuelta (1-RTT) e incluso admite 0-RTT para sesiones reanudadas, haciendo las conexiones más rápidas.

Certificados: el ancla de confianza

Un certificado vincula una clave pública a una identidad (como un nombre de dominio). Está firmado por una Autoridad de Certificación (CA) en la que el cliente confía. Cuando tu navegador se conecta a https://example.com, verifica:

Si alguna verificación falla, recibes una advertencia. Para desarrollo, puedes usar certificados autofirmados, pero los navegadores los marcarán a menos que los confíes explícitamente.

Errores comunes de certificados y soluciones

ErrorCausa probableSolución
NET::ERR_CERT_COMMON_NAME_INVALIDEl certificado no coincide con el dominioReemitir el certificado con los Subject Alternative Names (SANs) correctos
NET::ERR_CERT_AUTHORITY_INVALIDAutofirmado o CA no confiableUsar una CA de confianza o instalar la CA en el almacén de confianza
NET::ERR_CERT_DATE_INVALIDExpirado o aún no válidoRenovar el certificado y verificar el reloj del sistema

Cifrado en la práctica: simétrico vs asimétrico

TLS utiliza ambos tipos de cifrado:

El secreto compartido del handshake se usa para derivar claves de sesión simétricas. Este enfoque híbrido te da seguridad y rendimiento.

Depuración de conexiones TLS

Cuando HTTPS falla, necesitas inspeccionar el handshake. Aquí tienes comandos y técnicas prácticas:

1. Inspeccionar detalles del certificado con OpenSSL

openssl s_client -connect example.com:443 -servername example.com </dev/null

Esto imprime la cadena de certificados, el conjunto de cifrado y los detalles del handshake. Busca Verify return code: 0 (ok) para confirmar la confianza.

2. Probar versiones de TLS y cifrados

nmap --script ssl-enum-ciphers -p 443 example.com

Esto lista las versiones de TLS y conjuntos de cifrado compatibles, ayudándote a identificar configuraciones débiles.

3. Verificar encabezados de seguridad HTTP

Usa las DevTools del navegador (pestaña Seguridad) para ver si la página es completamente segura. El contenido mixto (recursos HTTP en una página HTTPS) genera advertencias y puede romper funcionalidades.

4. Analizar registros del servidor en busca de errores TLS

Si ejecutas Nginx, los fallos de handshake TLS aparecen en los registros de errores. Por ejemplo:

2025/01/01 12:00:00 [error] 1234#0: *5 SSL_do_handshake() failed (SSL: error:14094416:SSL routines:ssl3_read_bytes:sslv3 alert certificate unknown) while SSL handshaking, client: 203.0.113.1, server: 0.0.0.0:443

Esto indica que el cliente rechazó el certificado. Verifica tu cadena de certificados y configuración.

Optimización del rendimiento de TLS

TLS añade latencia, pero puedes minimizarla:

Errores comunes y cómo evitarlos

Preguntas frecuentes

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

HTTPS es HTTP sobre TLS. TLS es el protocolo que proporciona cifrado y autenticación. Por lo tanto, HTTPS es la versión segura de HTTP, impulsada por TLS.

¿Cómo mejora TLS 1.3 a TLS 1.2?

TLS 1.3 reduce el handshake a un viaje de ida y vuelta (1-RTT) y admite 0-RTT para sesiones reanudadas. También elimina algoritmos criptográficos obsoletos y débiles, simplificando la configuración y mejorando la seguridad.

¿Por qué recibo errores de certificado en desarrollo?

Los servidores de desarrollo a menudo usan certificados autofirmados, que los navegadores no confían por defecto. Puedes agregar el certificado a tu almacén de confianza o usar una herramienta como mkcert para generar certificados de confianza local.

¿Necesitas inspeccionar o depurar rápidamente registros del servidor en busca de errores TLS? Prueba nuestro Analizador de registros de Nginx para analizar y filtrar entradas de registro en tu navegador.