Lección 1 de 612 min
Cifrado y transporte seguro
HTTPS, TLS 1.2 y 1.3, HSTS y la diferencia entre cifrar en tránsito y en reposo.
Imagina que alguien inicia sesión en tu tienda desde el Wi-Fi de una cafetería. Si la conexión no va cifrada, cualquiera en esa red puede leer su contraseña, robarle la cookie de sesión o cambiar el precio que ve en pantalla. Si va cifrada pero mal configurada, el resultado puede ser casi el mismo.
En el módulo de fundamentos viste cómo funcionan TLS y HTTPS por dentro. Aquí cambiamos de papel: eres quien defiende el servidor. Verás qué protege exactamente HTTPS, cómo conseguir y renovar certificados, qué versiones de TLS activar, cómo obligar al navegador a usar siempre HTTPS y por qué cifrar los datos que viajan no basta si los que guardas están en claro.
HTTPS y los certificados
HTTPS es HTTP de siempre, pero dentro de un túnel TLS. El túnel solo sirve si el navegador puede comprobar con quién lo ha abierto, y para eso están los certificados.
HTTPS
HTTP dentro de TLS: confidencialidad, integridad y autenticidad en cada petición.
- Puerto:
- 443
- Esquema:
- https://
HTTPS aporta tres garantías. Confidencialidad: nadie en el camino puede leer lo que viaja, ni las cabeceras, ni las cookies, ni el cuerpo. Integridad: si alguien modifica un solo byte, la conexión lo detecta y se corta. Autenticidad: el servidor demuestra con su certificado que de verdad es tienda.com y no un impostor que se ha colado en medio.
Lo que no oculta es con quién hablas: un observador sigue viendo la IP del servidor y, normalmente, el nombre del dominio. Y no hace segura tu aplicación: un formulario vulnerable sigue siéndolo aunque viaje cifrado.
Hoy HTTPS es el mínimo para cualquier web, no un extra. Los navegadores marcan como «no seguras» las páginas HTTP, y muchas APIs modernas (geolocalización, service workers, el portapapeles) solo funcionan en contextos seguros.
Úsalo cuando
Siempre, en todas las páginas y en todas las APIs, también en las internas. Redirige con un 301 cualquier petición HTTP a su versión HTTPS.
Ten en cuenta
El «contenido mixto» rompe la protección: una página HTTPS que carga un script por HTTP le da a un atacante la ocasión de modificar ese script. Los navegadores bloquean o actualizan gran parte de ese contenido, pero lo correcto es no tenerlo.
# Todo lo que llegue por HTTP se redirige a HTTPS
server {
listen 80;
server_name tienda.com;
return 301 https://$host$request_uri;
}
server {
listen 443 ssl;
server_name tienda.com;
ssl_certificate /etc/letsencrypt/live/tienda.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/tienda.com/privkey.pem;
}Certificados, CA y Let's Encrypt
Prueban que un dominio es tuyo, con la firma de alguien en quien confía el navegador.
- Protocolo:
- ACME
- Let's Encrypt:
- Gratuita
Un certificado TLS une un nombre de dominio con una clave pública, y lo firma una autoridad de certificación (CA). Tu navegador y tu sistema operativo traen una lista de CA raíz de confianza; si la cadena de firmas del certificado llega hasta una de ellas y el dominio coincide, el candado aparece. La clave privada correspondiente nunca sale de tu servidor.
Let's Encrypt es una CA gratuita y automatizada. Con el protocolo ACME, un programa como Certbot (o un servidor como Caddy, o cert-manager en Kubernetes) demuestra que controlas el dominio, obtiene el certificado y lo renueva solo antes de que caduque.
Los certificados de Let's Encrypt han durado tradicionalmente 90 días, y toda la industria está acortando la vida máxima de los certificados. La conclusión práctica es la misma: la renovación tiene que ser automática, no una tarea en el calendario de alguien.
Úsalo cuando
Para cualquier web pública. Si usas una CDN o una plataforma como Vercel o Cloudflare, suelen emitir y renovar el certificado por ti.
Ten en cuenta
Un certificado caducado tumba tu web igual que una caída del servidor: el navegador muestra un aviso a pantalla completa. Vigila la renovación con una alerta y protege la clave privada como cualquier otro secreto.
# Obtiene el certificado y configura nginx automáticamente
sudo certbot --nginx -d tienda.com -d www.tienda.com
# Comprueba que la renovación automática funcionará
sudo certbot renew --dry-runConfigurar TLS
TLS ha tenido varias versiones. Las antiguas tienen debilidades conocidas, así que configurar bien un servidor consiste sobre todo en decidir qué versiones y qué algoritmos aceptas.
TLS 1.2
La versión veterana: sigue siendo segura si eliges bien los cifrados.
- Publicado:
- 2008
- Estándar:
- RFC 5246
TLS 1.2 se publicó en 2008 y todavía lo usan muchos clientes antiguos. Es seguro, pero admite una larga lista de suites de cifrado (combinaciones de algoritmos), y algunas son débiles: RC4, 3DES, el modo CBC o el intercambio de claves RSA estático.
Ese último punto importa por el forward secrecy (secreto hacia adelante): con intercambio ECDHE, cada conexión usa claves temporales, así que si mañana roban la clave privada del servidor no podrán descifrar el tráfico que grabaron ayer. Con RSA estático, sí podrían.
Úsalo cuando
Mantenlo activo junto a TLS 1.3 para no dejar fuera a clientes antiguos, pero restringido a suites con ECDHE y cifrado autenticado (AES-GCM o ChaCha20-Poly1305).
Ten en cuenta
No escribas la lista de cifrados de memoria: el generador de configuración de Mozilla te da una configuración probada para nginx, Apache y otros servidores.
# Solo TLS 1.2 y 1.3: TLS 1.0 y 1.1 quedan fuera
ssl_protocols TLSv1.2 TLSv1.3;
# Para TLS 1.2: solo ECDHE (forward secrecy) y cifrado autenticado
ssl_ciphers ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305;TLS 1.3
Más rápido y más simple: quitó todo lo débil y hace obligatorio el forward secrecy.
- Publicado:
- 2018
- Estándar:
- RFC 8446
- Handshake:
- 1 ida y vuelta
TLS 1.3, de 2018, rediseñó el protocolo con dos objetivos. El primero, velocidad: el handshake completo necesita un solo viaje de ida y vuelta en lugar de dos, y al reanudar una sesión puede enviar datos desde el primer mensaje (el llamado 0-RTT).
El segundo, seguridad por eliminación: quitó RC4, 3DES, CBC, la compresión, la renegociación y el intercambio RSA estático. Solo quedan unas pocas suites de cifrado autenticado y todas usan claves efímeras, así que el forward secrecy ya no es opcional.
Las versiones 1.0 y 1.1 están oficialmente obsoletas desde 2021 y los navegadores principales ya no las aceptan. Desactívalas en tus servidores.
Úsalo cuando
Siempre que tu servidor o tu CDN lo permita, que hoy es casi siempre. Es la versión que negociarán los navegadores modernos.
Ten en cuenta
El 0-RTT tiene un precio: esos primeros datos se pueden reenviar (un ataque de repetición). Muchos servidores lo traen desactivado; si lo activas, úsalo solo para peticiones que no cambien nada, como un GET.
# ¿Qué versión y qué cifrado negocia tu servidor?
openssl s_client -connect tienda.com:443 -tls1_3 </dev/null | grep -i "cipher"
# New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384
# TLS 1.1 debería fallar
openssl s_client -connect tienda.com:443 -tls1_1 </dev/null
# ... handshake failureHSTS
Una cabecera que obliga al navegador a usar siempre HTTPS con tu dominio.
- Cabecera:
- Strict-Transport-Security
- Se ignora:
- Por HTTP
Aunque redirijas HTTP a HTTPS, la primera petición por HTTP viaja en claro, y un atacante en la red puede interceptarla y mantener a la víctima en HTTP (el ataque de «SSL stripping»). La cabecera Strict-Transport-Security lo evita: le dice al navegador que, durante max-age segundos, convierta por su cuenta cualquier enlace http:// a tu dominio en https://, sin llegar a preguntar.
includeSubDomains extiende la regla a todos los subdominios. Y como la primera visita sigue desprotegida, existe la preload list: una lista que viene incluida en los navegadores. Si tu dominio está en ella, el navegador usa HTTPS desde la primera petición. Para entrar, envías la cabecera con preload y lo solicitas en hstspreload.org.
Úsalo cuando
En cuanto todo tu dominio funcione por HTTPS. Empieza con un max-age corto, comprueba que nada se rompe y súbelo a un año.
Ten en cuenta
Es difícil de deshacer: si un subdominio todavía necesita HTTP, includeSubDomains lo dejará inaccesible, y salir de la preload list tarda meses. El navegador ignora la cabecera si llega por HTTP.
# Fase de prueba: 5 minutos, solo el dominio principal
Strict-Transport-Security: max-age=300
# Producción: un año, subdominios incluidos y lista de precarga
Strict-Transport-Security: max-age=31536000; includeSubDomains; preloadPruébalo
Analiza tu dominio con SSL Labs: te dice qué versiones de TLS y qué cifrados aceptas, si la cadena de certificados está completa y si envías HSTS.
Cifrar en tránsito y en reposo
TLS protege los datos mientras viajan. Pero tarde o temprano llegan a un disco, a una base de datos o a una copia de seguridad, y allí necesitan otra capa de protección.
En tránsito frente a en reposo
Cifrar lo que viaja por la red y cifrar lo que se queda guardado son problemas distintos.
- En tránsito:
- TLS
- En reposo:
- Disco, BD o campo
En tránsito significa mientras los datos se mueven: del navegador a tu servidor, pero también de tu servidor a la base de datos o entre microservicios. Ahí la herramienta es TLS, y conviene usarlo también dentro de tu red, no solo hacia Internet.
En reposo significa mientras están almacenados. Hay varios niveles: cifrar el disco completo (los volúmenes de la nube lo ofrecen con una casilla), que la propia base de datos cifre sus archivos o cifrar campos concretos, como un número de documento, desde tu aplicación.
Cada nivel protege de una amenaza distinta. Cifrar el disco te salva si roban el disco, una copia de seguridad o una instantánea; no te salva si el atacante entra por tu aplicación, porque la aplicación ve los datos ya descifrados.
Úsalo cuando
Siempre ambos. El cifrado en reposo de los discos y las bases de datos gestionadas es barato y suele bastar con activarlo; reserva el cifrado por campo para los datos más sensibles.
Ten en cuenta
Cifrar no sirve de nada si la clave está junto a los datos, por ejemplo en el mismo servidor o en el código. Para eso existen los servicios de gestión de claves.
KMS y cifrado de sobre
Un servicio que custodia tus claves maestras y un patrón para cifrar mucho con poco.
- Ejemplos:
- AWS KMS, Cloud KMS, Key Vault
Un KMS (Key Management Service), como AWS KMS, Google Cloud KMS o Azure Key Vault, guarda las claves maestras en hardware especializado del que no salen nunca. Tú no las ves: le pides al servicio que cifre o descifre, y cada uso queda registrado y controlado por permisos.
Como enviar gigas de datos al KMS sería lento, se usa el cifrado de sobre (envelope encryption). Generas una clave de datos, cifras con ella tus datos en local y guardas la clave de datos cifrada por la clave maestra junto al resultado. Para leer, pides al KMS que descifre solo esa pequeña clave.
Úsalo cuando
Cuando cifras datos desde tu aplicación o necesitas controlar quién puede descifrar qué. Los servicios de la nube ya lo usan por debajo cuando activas el cifrado de un disco o de un bucket.
Ten en cuenta
Si borras la clave maestra, pierdes para siempre todo lo que cifraste con ella. Por eso los KMS obligan a programar el borrado con un periodo de espera.
import { KMSClient, GenerateDataKeyCommand } from "@aws-sdk/client-kms";
const kms = new KMSClient({});
// 1. El KMS genera una clave de datos y te la da dos veces:
// en claro (para usarla ya) y cifrada con la clave maestra (para guardarla)
const { Plaintext, CiphertextBlob } = await kms.send(
new GenerateDataKeyCommand({ KeyId: "alias/clientes", KeySpec: "AES_256" }),
);
// 2. Cifras los datos en local con Plaintext (por ejemplo, AES-GCM)
// 3. Guardas los datos cifrados junto a CiphertextBlob
// 4. Borras Plaintext de la memoria en cuanto terminasNo reinventes la criptografía
Usa los algoritmos y las librerías estándar (AES-GCM, la Web Crypto API, el SDK de tu nube) y deja que un KMS custodie las claves. Inventar tu propio cifrado es una de las formas más fiables de acabar con datos expuestos.
Interactivo
Versiones de TLS cara a cara
Activa o desactiva opciones para compararlas cara a cara.
| Característica | TLS 1.0 y 1.1 | TLS 1.2 | TLS 1.3 |
|---|---|---|---|
| Estado | Obsoletas desde 2021 | Vigente | Vigente y recomendada |
| Handshake completo | 2 idas y vueltas | 2 idas y vueltas | 1 ida y vuelta (0-RTT al reanudar) |
| Suites de cifrado | Incluyen algoritmos rotos | Muchas, algunas débiles: hay que filtrarlas | Pocas, todas con cifrado autenticado |
| Forward secrecy | Opcional | Solo con suites ECDHE | Siempre |
| ¿Activarlo? | No | Sí, con cifrados filtrados | Sí |
Ponlo en práctica
Saber qué es cada cosa es la mitad del trabajo. La otra mitad es reconocer cuándo usarla.
Interactivo
¿Qué usarías?
Lee cada situación y elige la opción que mejor la resuelve. Fallar aquí no cuenta: es para practicar.
Tu web ya redirige HTTP a HTTPS, pero en una auditoría te dicen que la primera petición de un usuario que escribe tienda.com en la barra todavía se puede interceptar.
Para recordar
- HTTPS da confidencialidad, integridad y autenticidad; no oculta con quién hablas ni arregla los fallos de tu aplicación.
- Automatiza la emisión y la renovación de certificados con ACME: un certificado caducado es una caída del servicio.
- Activa TLS 1.2 y 1.3, desactiva 1.0 y 1.1 y, para TLS 1.2, acepta solo suites con forward secrecy.
- HSTS obliga al navegador a usar HTTPS; la preload list protege incluso la primera visita, pero es difícil de deshacer.
- Cifra también en reposo y deja las claves en un KMS: cifrar con la clave al lado de los datos no protege nada.
Comprueba lo aprendido
Cuestionario
Responde las 5 preguntas para completar la lección.
1.Un atacante está en la misma red Wi-Fi que tu usuario, que navega por tu web con HTTPS. ¿Qué puede ver?
2.¿Qué significa que una conexión tenga forward secrecy?
3.Envías
Strict-Transport-Security: max-age=31536000; includeSubDomains. ¿Qué riesgo corres?4.¿Por qué TLS 1.3 es más rápido que TLS 1.2 al abrir una conexión nueva?
5.Tus discos en la nube están cifrados. Un atacante explota una inyección SQL en tu API. ¿Qué ocurre?