¿Qué es TLS? Cómo HTTPS protege el tráfico

#La respuesta corta

TLS (Transport Layer Security) es un protocolo que envuelve una conexión de red con cifrado. HTTPS es HTTP normal enviado dentro de una conexión TLS. Cuando el navegador muestra el candado, ha hecho tres cosas. Cifró los datos. Comprobó que nadie los modificó en el camino. Y confirmó que el servidor demostró tener un certificado confiable para el nombre que escribiste.

El tercer punto es el que la gente suele entender mal. HTTPS te dice con qué servidor estás hablando. No dice si ese servidor es confiable, honesto o bien administrado.

#Por qué HTTP sin cifrar no basta

En Cómo funciona HTTP, las peticiones y las respuestas son mensajes de texto, y HTTP no hace nada para ocultarlos. Cada dispositivo entre tú y el servidor puede leerlos: el router de casa, el punto de acceso de una cafetería, tu proveedor de internet y las redes intermedias.

Un observador pasivo puede leer un formulario de inicio de sesión enviado por HTTP sin cifrar. Un atacante activo en el camino puede hacer más. Puede cambiar una página antes de que llegue a ti, insertar un script o reemplazar una descarga por un archivo modificado. TLS está diseñado para frenar las dos amenazas. Además, le da al cliente una forma de comprobar quién responde, algo que HTTP sin cifrar nunca hace.

#Qué ofrece TLS 1.3

La versión actual es TLS 1.3, definida en la RFC 8446. TLS 1.0 y 1.1 están en desuso, como explica la RFC 8996, y TLS 1.2 sigue muy extendido. La versión 1.3 eliminó muchas opciones antiguas, así que hay menos formas de configurar mal el handshake.

TLS 1.3 ofrece tres propiedades.

#Confidencialidad

Los datos de la aplicación se cifran con claves de sesión que solo conocen los dos extremos. Un observador ve texto cifrado. El tamaño y el momento del tráfico siguen visibles, pero el contenido no.

Un handshake completo de TLS 1.3 usa un intercambio de claves efímero. Ambos lados crean valores temporales para la sesión y los descartan después. Esto da secreto perfecto hacia adelante (forward secrecy): si la clave privada del certificado se filtra años después, las sesiones antiguas que alguien grabó deberían seguir sin poder descifrarse. Una clave filtrada, aun así, permite que un atacante se haga pasar por el servidor desde ese momento. Es decir, el secreto perfecto protege el pasado, no el futuro.

#Integridad

Cada registro lleva una etiqueta de autenticación de un cifrado AEAD, como AES-GCM o ChaCha20-Poly1305. TLS 1.3 solo permite este tipo de cifrado. Si un atacante altera un bit en tránsito, la comprobación de la etiqueta falla y el registro se rechaza.

#Autenticación del servidor

El servidor demuestra que tiene la clave privada correspondiente a su certificado. El certificado vincula esa clave pública con un nombre, como example.com. El cliente comprueba el certificado y la cadena de confianza que lo respalda, y luego verifica el nombre. Buena parte del resto de este artículo trata de esa parte.

#El handshake, paso a paso

El handshake acuerda las claves y prueba las identidades antes de que circule cualquier dato HTTP. En TLS 1.3, el handshake habitual necesita un viaje de ida y vuelta. Los pasos siguientes siguen la RFC 8446 a grandes rasgos.

#Paso 1: el ClientHello

Tu cliente envía un ClientHello. Incluye las versiones de TLS y las suites de cifrado que admite, y un key share, el valor público temporal del cliente para el intercambio de claves. El mensaje también lleva el server name indication (SNI), el nombre de host que pediste, en texto plano. Los servidores que alojan muchos sitios necesitan ese nombre para elegir el certificado correcto.

#Paso 2: el ServerHello

El servidor elige la versión y la suite de cifrado, y envía su propio key share. Cada lado combina su valor privado con el valor público del otro y llega al mismo secreto compartido. Un observador que vio ambos valores públicos no puede calcular ese secreto. Desde aquí, el handshake ya va cifrado.

#Paso 3: el certificado y la prueba

El servidor envía su certificado. En TLS 1.2, el certificado era visible en la red. En TLS 1.3 viaja dentro de la parte cifrada del handshake.

Después, el servidor envía un mensaje CertificateVerify, una firma sobre la transcripción del handshake hecha con la clave privada del certificado. Eso demuestra que el servidor tiene la clave en esta misma conversación. Un certificado copiado por sí solo no le sirve a un atacante. Un mensaje Finished, un MAC sobre la transcripción, cierra la parte del servidor.

#Paso 4: el cliente comprueba y termina

Tu cliente revisa la cadena de certificados, las fechas de validez, el nombre del certificado frente al host que pediste y la firma de CertificateVerify. Si todas las comprobaciones pasan, el cliente envía su propio mensaje Finished, y los datos de la aplicación pueden circular.

Si una comprobación falla, el cliente se detiene. Un navegador muestra una advertencia de certificado, y curl termina con un error. Esos mensajes son la parte más útil de TLS para quien empieza, porque indican qué comprobación falló.

#Certificados y cadenas de confianza

Un certificado es una estructura X.509, y la RFC 5280 define el perfil que se usa en internet. Estos son los campos que más importan aquí.

Los clientes modernos ignoran el Common Name (CN) del subject para comprobar el nombre de host y usan la lista SAN. Quien lee solo el CN puede interpretar mal un certificado.

#Cómo se comprueba la cadena

Un servidor rara vez presenta un certificado que el cliente pueda verificar directamente. Normalmente, el certificado hoja, que cubre el nombre de host, está firmado por una CA intermedia, y la intermedia está firmada por una CA raíz. El cliente confía en un conjunto de raíces que viene con el sistema operativo o el navegador.

El cliente construye un camino desde la hoja hasta una raíz confiable. En cada eslabón verifica la firma, comprueba las fechas de validez y confirma que el emisor puede firmar certificados. Luego comprueba el nombre de host. Las dos comprobaciones tienen que pasar.

Cualquier raíz de confianza puede, en principio, emitir un certificado para cualquier nombre. Por eso la confianza depende de las prácticas de las autoridades del almacén. Por eso los fabricantes retiran a las autoridades que emiten certificados de forma incorrecta.

#Revocación

Un certificado puede revocarse antes de vencer, por ejemplo después de que se comprometa su clave. Los clientes pueden comprobar la revocación con listas (CRL) o con OCSP, pero estas comprobaciones funcionan de forma irregular. Una conexión sin errores no demuestra que el certificado nunca fue revocado.

#Lo que TLS no protege

#El servidor

TLS autentica la identidad del servidor. No evalúa cómo se comporta. Un sitio de phishing puede obtener un certificado válido para un dominio parecido que controla. El candado entonces muestra que la conexión llega al dueño de la clave de ese dominio, no que el dominio pertenezca a tu banco. Lee el nombre de host en la barra de direcciones antes de confiar en la página. Un servidor con certificado correcto todavía puede ser hackeado o estar mal administrado.

#Metadatos

TLS oculta el contenido, no todos los datos de la conexión. Quien está en el camino todavía ve las direcciones IP de cada extremo, el puerto, el tamaño y el momento aproximados del tráfico, y el nombre del servidor en el ClientHello, porque el SNI viaja en texto plano. Encrypted Client Hello es un esfuerzo del IETF para ocultar el SNI, pero revisa cuánto está desplegado antes de suponer que un sitio lo usa. Las consultas DNS son un protocolo aparte y revelan los nombres que resuelves, salvo que uses DNS cifrado.

#Los extremos

TLS protege los datos mientras se mueven entre dos extremos. No protege los extremos. Un malware en tu computadora puede leer datos ya descifrados, y una extensión del navegador puede leer cada página que abres. Una empresa también puede instalar su propia raíz de confianza en tu equipo y descifrar tu tráfico mediante un proxy de inspección. En ese caso, la decisión de confianza pertenece a quien controla esa raíz.

#Laboratorio práctico: inspecciona el HTTPS de example.com

example.com es uno de los nombres que la IANA reserva para documentación y ejemplos. Todos los comandos siguientes se conectan solo a example.com. El laboratorio no cambia nada en el servidor y no requiere cuenta. Necesitas una terminal con curl y openssl. Los comandos de openssl se ejecutaron con OpenSSL 3.2.4.

Tu salida será distinta de la que se muestra aquí. Las direcciones IP cambian, los certificados se renuevan y las fechas avanzan.

#Paso 1: lee el intercambio con curl

curl -vI https://example.com

La opción -v muestra los detalles de la conexión, y -I envía una petición HEAD, que solo pide cabeceras. En la máquina usada para este artículo (Windows 11 con Git Bash, curl 8.12.1, ejecutado el 8 de noviembre de 2026), las líneas relevantes se vieron así:

* Host example.com:443 was resolved.
* IPv4: 172.66.147.243, 104.20.23.154
* Connected to example.com (172.66.147.243) port 443
* using HTTP/1.x
> HEAD / HTTP/1.1
> Host: example.com
< HTTP/1.1 200 OK

Esta compilación de curl usa Schannel, la biblioteca TLS de Windows, y su salida detallada es distinta a la de un curl compilado con OpenSSL. Aquí, curl no mostró la versión TLS, el cifrado ni las líneas del certificado que pide este laboratorio. En un curl basado en OpenSSL, busca la línea con la versión TLS y el cifrado, y el bloque del certificado con subject, issuer y fecha de expiración. Los pasos siguientes obtienen los mismos datos con openssl.

El 200 OK significa que el servidor respondió dentro de la conexión TLS. Las cabeceras viajan cifradas, y curl las descifra localmente.

#Paso 2: obtén un resumen corto con openssl

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

Salida:

Connecting to 172.66.147.243
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=example.com
Hash used: SHA256
Signature type: ECDSA
Verification: OK
Server Temp Key: X25519, 253 bits
DONE

Léelo línea por línea:

• Protocol version: la versión de TLS negociada para esta conexión.
• Ciphersuite: AES-256-GCM protege los registros, y SHA-384 se usa en el key schedule.
• Signature type: ECDSA, el algoritmo de la clave del certificado.
• Verification: OK, lo que significa que la cadena se validó contra el almacén de confianza de esta build de openssl.
• Server Temp Key: X25519, el intercambio de claves efímero que da el secreto perfecto hacia adelante.

La opción -servername define el SNI. Sin ella, un servidor que aloja varios sitios puede devolver un certificado por defecto que no coincide con el nombre que querías. La redirección </dev/null cierra la entrada estándar, así que el comando termina.

#Paso 3: lee los campos del certificado

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -subject -issuer -dates

Salida:

subject=CN=example.com
issuer=C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
notBefore=Sep 26 22:49:11 2026 GMT
notAfter=Dec 25 22:56:35 2026 GMT

El subject tiene solo un CN. El issuer es una CA intermedia, no la raíz. La ventana de validez estaba abierta el día del laboratorio y se cierra el 25 de diciembre de 2026. Compara notAfter con la fecha de tu sistema, porque un certificado vencido falla aunque su cadena esté en orden.

El subject no lista los nombres cubiertos, así que pide la lista SAN:

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | openssl x509 -noout -ext subjectAltName

Salida:

X509v3 Subject Alternative Name:
    DNS:example.com, DNS:*.example.com

El comodín cubre nombres como www.example.com. El cliente compara esta lista con el host de tu URL.

#Paso 4: lista la cadena que envió el servidor

openssl s_client -connect example.com:443 -servername example.com -showcerts </dev/null 2>/dev/null | grep -E '^ *[0-9] s:|^ *i:'

Salida:

 0 s:CN=example.com
   i:C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
 1 s:C=US, O=SSL Corporation, CN=Cloudflare TLS Issuing ECC CA 3
   i:C=US, O=SSL Corporation, CN=SSL.com TLS Transit ECC CA R2
 2 s:C=US, O=SSL Corporation, CN=SSL.com TLS Transit ECC CA R2
   i:C=US, O=SSL Corporation, CN=SSL.com TLS ECC Root CA 2022
 3 s:C=US, O=SSL Corporation, CN=SSL.com TLS ECC Root CA 2022
   i:C=GB, ST=Greater Manchester, L=Salford, O=Comodo CA Limited, CN=AAA Certificate Services

Cada línea s: es un subject, y cada línea i: es su issuer. La entrada 0 es la hoja, y cada entrada la emite la siguiente. Los certificados pueden tener firma cruzada, así que una cadena puede llegar a una raíz por más de un camino. El cliente necesita un camino válido que termine en una raíz de su propio almacén.

#Paso 5: confirma que la cadena se valida

openssl s_client -connect example.com:443 -servername example.com </dev/null 2>/dev/null | grep 'Verify return code'

Salida:

Verify return code: 0 (ok)

Cero significa que el almacén de confianza de esta build de openssl aceptó la cadena. Otros valores indican un fallo concreto, como un certificado vencido.

#Paso 6: provoca a propósito un fallo de nombre

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

Salida, resumida:

depth=0 CN=example.com
verify error:num=62:hostname mismatch
CONNECTION ESTABLISHED
Protocol version: TLSv1.3
Ciphersuite: TLS_AES_256_GCM_SHA384
Peer certificate: CN=example.com
Verification error: hostname mismatch

El comando sigue conectándose solo a example.com. La opción -verify_hostname pide a openssl que compare el certificado con example.org, que el certificado no cubre. Un navegador muestra el mismo tipo de fallo. Esta comprobación impide que un servidor con certificado válido para un dominio se haga pasar por otro.

#Qué llevarte del laboratorio

La conexión negoció TLS 1.3, y el cliente aceptó la cadena para example.com mientras rechazaba el mismo certificado para example.org. Ninguno de esos resultados dice si la empresa detrás de example.com es confiable. El laboratorio demuestra que tu cliente llegó al dueño de la clave de example.com, y nada más.

#Errores comunes

• Leer el candado como una calificación de confianza. Significa que el canal está cifrado y que el certificado se comprobó. No califica el sitio.
• Revisar solo el CN. Los clientes modernos comparan el nombre de host con la lista SAN.
• Hacer clic en una advertencia de certificado sin mirarla. La advertencia significa que falló una comprobación. Averigua cuál antes de seguir.
• Añadir -k o --insecure a curl para que desaparezca un error. Eso desactiva las comprobaciones que acabas de leer. Úsalo solo contra un servidor de pruebas desechable, nunca con credenciales reales.
• Escribir código con la verificación desactivada, como verify=False en un cliente HTTP de Python. Los datos siguen cifrados, pero llegan a quien respondió.

#Cómo seguir avanzando

Lee las secciones de visión general y de handshake de la RFC 8446, y luego revisa los campos del certificado en la RFC 5280. Lee la guía de TLS para servidores de Mozilla y ejecuta una comprobación de configuración en un servidor que administres.

El siguiente artículo de la serie trata de claves públicas y privadas, las matemáticas detrás del certificado. Si la etapa de resolución de nombres te resulta nueva, lee primero ¿Qué es DNS?, porque su resultado define a qué dirección llega el handshake.

#Fuentes

• RFC 8446: The Transport Layer Security (TLS) Protocol Version 1.3
• RFC 5280: Internet X.509 Public Key Infrastructure Certificate and CRL Profile
• Mozilla: Security/Server Side TLS
• Documentación de OpenSSL: openssl-s_client
• RFC 8996: Deprecating TLS 1.0 and TLS 1.1
• IANA: Example domains