Ya tienes las cuatro primitivas: cifrado simétrico, cifrado asimétrico, hash con MAC, y firma digital. La lección anterior cerró anunciando algo incómodo, y esta lo desarrolla: combinar primitivas correctas no garantiza un sistema seguro. El ensamblaje —el orden de los mensajes, qué se autentica, qué se negocia, qué pasa cuando algo falla— tiene sus propios modos de fallo, y la historia de la criptografía aplicada está llena de protocolos hechos con AES impecable y RSA impecable que se rompieron por cómo estaban montados. Esta lección estudia el TLS que llevas ocho lecciones dando por supuesto —cumpliendo la promesa del módulo 2—, con su handshake paso a paso, cómo verificarlo y cómo configurarlo; y añade SSH, VPN, mTLS, el correo cifrado y los ataques clásicos contra protocolos: downgrade, stripping, MITM y repetición.

1. Qué es un protocolo criptográfico y por qué puede fallar
2. TLS: qué protege y qué no
3. De SSL a TLS 1.3: qué mejora cada versión
4. El handshake de TLS 1.3 paso a paso
5. Suites de cifrado: cómo se leen
6. Verificar TLS desde la línea de órdenes
7. Configuración segura del servidor de Nimbus
8. mTLS: TLS mutuo y cuándo tiene sentido
9. Otros protocolos: SSH, VPN, correo y cifrado extremo a extremo
10. Ataques contra protocolos y sus defensas
11. Errores de implementación con impacto real

Un protocolo criptográfico es una secuencia acordada de mensajes entre dos o más partes que, usando primitivas criptográficas, consigue un objetivo de seguridad concreto: establecer un canal confidencial, autenticar a alguien, acordar una clave, probar una posesión.

La diferencia con una primitiva es la misma que hay entre un ladrillo y un edificio. Un ladrillo se ensaya en laboratorio y aguanta; un edificio se cae por el diseño, no por el ladrillo. Los modos de fallo típicos de un protocolo son estos, y ninguno implica romper el álgebra:

De ahí la regla del apartado, coherente con todo el módulo: los protocolos tampoco se diseñan ni se implementan a mano. Se usan protocolos estándar, con implementaciones maduras, actualizadas y bien configuradas. Tu trabajo profesional es elegir la versión correcta, configurarla bien y verificar que efectivamente hace lo que crees.

TLS (Transport Layer Security) es el protocolo que convierte HTTP en HTTPS, y también protege SMTP, IMAP, conexiones a bases de datos y prácticamente cualquier cosa que viaje por una red hoy. Es el ejemplo perfecto de cifrado híbrido (03-03) llevado a producción.

Dos consecuencias prácticas que conviene decir en voz alta:

• «Va por HTTPS» no significa «es seguro». El IDOR de 01-01, la inyección SQL de 02-02 y la fuga del bucket de 02-06 ocurrirían igual sobre TLS impecable. TLS protege el tramo, no la aplicación.
• El candado del navegador no acredita honestidad. Acredita que hablas con el dominio que pone en la barra. Una web de phishing con dominio nimbus-reservas-clientes.example tendrá su candado perfecto (02-03).

Qué mejora TLS 1.3, que es lo que hay que saber explicar:

1. Menos vueltas. El handshake se completa en 1-RTT (un ida y vuelta) frente a las dos de TLS 1.2. Se nota en latencia, especialmente desde móvil.
2. Suites reducidas y sin piezas rotas. Se eliminaron del estándar RC4, 3DES, MD5, SHA-1, la compresión, la renegociación y los modos CBC con MAC-then-encrypt. Solo quedan suites AEAD (03-02).
3. Forward secrecy obligatoria. Desaparece el intercambio de clave por RSA estático: todo es ECDHE (03-03). Ya no puedes configurarlo mal, porque la opción mala no existe.
4. Más del handshake va cifrado, incluido el certificado del servidor, lo que reduce lo que un observador aprende.
5. Menos margen para errores de configuración. Es la mejora más subestimada: TLS 1.3 es seguro por defecto, mientras que TLS 1.2 exige que el administrador acierte con la lista de suites.

Hay un matiz que conviene conocer: TLS 1.3 permite reanudación en 0-RTT, que envía datos en el primer mensaje. Es rápido, pero esos datos son susceptibles de repetición, así que solo debe usarse para peticiones idempotentes. Para la API de Nimbus, la recomendación es no habilitar 0-RTT.

Los cinco momentos, con lo que aporta cada uno:

1. ClientHello. El cliente propone versiones y suites, y —clave para el 1-RTT— ya envía su clave pública efímera, adelantando el intercambio ECDHE. Incluye el SNI, el nombre del servidor al que quiere conectarse, necesario porque una misma IP aloja muchos dominios.
2. ServerHello. El servidor elige la suite y envía su clave pública efímera. Con las dos mitades, ambos calculan el mismo secreto compartido (03-03) y derivan de él las claves de sesión mediante HKDF (03-02). Aquí entra ECDHE y aquí nace la forward secrecy.
3. A partir de este punto todo va cifrado, incluido el certificado.
4. Certificado y CertificateVerify. El servidor envía su certificado y su cadena, y firma con su clave privada un resumen de todo el handshake. Esto es lo que autentica el intercambio y cierra la puerta al MITM de 03-03: el atacante puede hacer su propio ECDHE, pero no puede producir esa firma sin la clave privada correspondiente al certificado. El cliente valida la cadena hasta una raíz de confianza, el nombre del dominio, la vigencia y la firma —lo que se emite y cómo se valida es materia de 03-06—.
5. Finished en ambos sentidos. Cada extremo demuestra que ha visto exactamente los mismos mensajes. Esto es lo que detecta un downgrade: si un atacante hubiera alterado el ClientHello para forzar una suite débil, el resumen no cuadraría.

A partir de ahí, el tráfico se cifra con AES-GCM o ChaCha20-Poly1305 y claves simétricas. Es exactamente el patrón híbrido de 03-03: lo asimétrico solo para acordar y autenticar, lo simétrico para los datos.

Una suite de cifrado es la combinación concreta de algoritmos que se usa en una sesión. En TLS 1.2 el nombre incluye cuatro piezas:

En TLS 1.3 los nombres son mucho más cortos, porque el intercambio y la autenticación ya no se negocian en la suite:

Cómo evaluar una suite de un vistazo: si el intercambio no empieza por ECDHE (o DHE), no hay forward secrecy; si el cifrado es CBC, RC4 o 3DES, está fuera; si el hash es MD5 o SHA (por SHA-1), está fuera. Las tres suites de TLS 1.3 son todas correctas, que es precisamente la ventaja de esa versión.

Saber leer el estado real de un servidor es una habilidad operativa básica. Lucía comprueba la API de Nimbus:

Salida comentada de la primera orden:

Cómo se lee esta salida, que es lo importante:

• depth=2, depth=1, depth=0 son los tres eslabones de la cadena: raíz, intermedia y certificado del servidor. verify return:1 en cada uno significa que ese eslabón validó.
• Certificate chain muestra, para cada certificado, su sujeto (s:) y su emisor (i:). Fíjate en el encadenamiento: el emisor de uno es el sujeto del siguiente. La jerarquía completa es materia de 03-06.
• New, TLSv1.3, Cipher is TLS_AES_256_GCM_SHA384 es la línea que resume el resultado: versión negociada y suite. Si aquí apareciera TLSv1.0 o una suite con CBC, habría hallazgo.
• Server public key is 256 bit indica una clave ECC de 256 bits (equivalente a RSA-3072, tabla de 03-03). Si dijera 2048, sería RSA.
• Verify return code: 0 (ok) es la validación completa. Cualquier otro valor —10 caducado, 18 autofirmado, 19 raíz no fiable, 21 no se pudo verificar— es un problema.
• Las opciones: -servername envía el SNI, imprescindible cuando la IP aloja varios dominios; sin él puedes estar viendo un certificado que no es el tuyo. </dev/null cierra la entrada para que la orden no se quede esperando.

Y la comprobación de HSTS, que se hace sobre las cabeceras HTTP:

Fragmento de configuración de Nginx para el frontal de Nimbus, explicado directiva a directiva:

Qué hace cada bloque:

1. ssl_protocols TLSv1.2 TLSv1.3. Deshabilita SSL y TLS 1.0/1.1. Si toda tu base de clientes es moderna, dejar solo TLSv1.3 es mejor todavía; mídelo antes con los registros de acceso.
2. ssl_ciphers. Solo suites ECDHE (forward secrecy) con AEAD. ssl_prefer_server_ciphers off es lo recomendado hoy: se deja elegir al cliente dentro de la lista permitida, porque un móvil sin aceleración AES elegirá ChaCha20 y irá más rápido con la misma seguridad.
3. ssl_ecdh_curve X25519:prime256v1. Prioriza X25519 (03-03), más rápida y más difícil de implementar mal.
4. Reanudación. La caché acelera reconexiones. ssl_session_tickets off evita el riesgo de que una clave de tickets mal rotada anule la forward secrecy; ssl_early_data off desactiva 0-RTT por el riesgo de repetición.
5. Grapado OCSP. El servidor adjunta al handshake una prueba reciente de que su certificado no está revocado, en lugar de obligar al cliente a consultarla. Mejora privacidad y latencia; el mecanismo de revocación se estudia en 03-06.
6. HSTS. max-age=63072000 (dos años) indica al navegador que solo use HTTPS para este dominio; includeSubDomains lo extiende a todos los subdominios y preload permite incluirlo en la lista precargada de los navegadores. Es la defensa contra el stripping del apartado 10. Cuidado: includeSubDomains y preload son difíciles de revertir; verifica antes que todos los subdominios sirven HTTPS.
7. Redirección 301 de HTTP a HTTPS. Necesaria, pero no suficiente: la primera petición sigue viajando en claro. Por eso hace falta HSTS.

Verifica siempre el resultado con un analizador externo de configuración TLS y con las órdenes del apartado 6: la configuración escrita y la efectiva no siempre coinciden, sobre todo con balanceadores o CDN por delante.

En TLS normal solo se autentica el servidor; el cliente se identifica después, dentro del canal, con una contraseña o un token. En mTLS (mutual TLS), ambos extremos presentan certificado y ambos se autentican durante el propio handshake.

Lo que aporta: la autenticación ocurre antes de que la aplicación procese nada, así que un atacante sin certificado válido ni siquiera llega a la lógica de negocio. Lo que cuesta: hay que emitir, distribuir, renovar y revocar un certificado por cliente, lo que exige una PKI interna —el asunto de 03-06—. La regla práctica: mTLS entre pocos sistemas de alto valor, tokens para muchos usuarios.

SSH merece un detalle, porque su modelo de confianza es distinto del de TLS: no hay autoridades de certificación, sino una huella del host que el cliente memoriza la primera vez (trust on first use).

Lo esencial: cuando SSH avisa de que la clave del host ha cambiado o es desconocida, aceptar a ciegas equivale a aceptar un posible MITM. La huella debe compararse con la obtenida por otro canal. Y para un parque como el de Nimbus, la solución que escala es firmar las claves de host con una CA de SSH, lo que sustituye la memorización por una confianza jerárquica (03-06). Además: autenticación solo por clave —PasswordAuthentication no—, clave protegida con frase de paso y root sin acceso directo; el endurecimiento completo del servidor es de 05-06.

Sobre las VPN, aquí solo interesa qué garantizan: un túnel cifrado y autenticado entre dos puntos. No dan control de acceso a las aplicaciones ni convierten en confiable lo que hay dentro. El despliegue de red se trata en 05-04.

Y el cifrado extremo a extremo como concepto: los datos se cifran en el dispositivo del emisor y solo se descifran en el del destinatario, de modo que ni el proveedor del servicio puede leerlos. Es la diferencia con TLS, donde el servidor sí ve el contenido. Para Nimbus, un E2EE completo sería incompatible con su función —la aplicación necesita procesar las citas—, pero el concepto reaparece en 03-07 al hablar del cifrado a nivel de campo.

Dos merecen desarrollo:

El stripping es el ataque más rentable contra un usuario en una wifi pública, y no rompe TLS: lo esquiva. La víctima escribe nimbusreservas.example sin https://, el navegador prueba HTTP, y el atacante intercepta esa petición inicial y actúa de proxy en claro hacia el usuario mientras habla en HTTPS con el servidor real. HSTS lo corta porque el navegador, tras la primera visita legítima, se niega a usar HTTP para ese dominio. Y preload cierra también esa primera visita, al venir la regla de fábrica en el navegador.

El pinning consiste en que el cliente exija no solo un certificado válido, sino uno concreto (o una CA concreta). Sirve contra el escenario de una CA que emite un certificado indebido para tu dominio. Tiene un riesgo serio: si se rota el certificado sin actualizar el pin, la aplicación deja de funcionar y solo se arregla publicando una nueva versión. Recomendación para Nimbus: valorarlo en la app móvil —donde el ciclo de actualización es controlable y el pin puede apuntar a la CA, no a la hoja—, y no en el navegador. Para el resto, la transparencia de certificados (03-06) cubre el mismo riesgo con mucho menos coste operativo.

El protocolo puede ser impecable y la implementación anularlo. El ejemplo canónico, ya citado en 02-02:

Qué significa exactamente esa línea: la conexión sigue cifrada, pero se acepta cualquier certificado, incluido el de un atacante. Es decir, se conserva el coste de TLS y se pierde por completo su garantía, porque sin autenticar al otro extremo el cifrado protege una conversación con quien sea. Es el MITM de 03-03 servido en bandeja, y en este caso concreto expondría el tráfico con la pasarela de pago.

La versión correcta, con las tres situaciones que suelen provocar el atajo:

Otros errores del mismo grupo, todos habituales y todos igual de graves:

La defensa organizativa es la de siempre: una comprobación en el CI (02-04) que rechace verify=False, InsecureSkipVerify, rejectUnauthorized: false y curl -k, y revisión obligatoria entre dos personas para cualquier excepción justificada, con fecha de caducidad y ticket asociado.

Conceptuales

1. Creer que HTTPS hace segura la aplicación. Protege el tramo, no la lógica.
2. Tomar el candado por una acreditación de honestidad. Acredita el dominio, nada más.
3. Pensar que una VPN sustituye al control de acceso. Da un túnel; dentro del túnel sigue haciendo falta autorizar.
4. Suponer que el certificado se renueva solo porque «lo pusimos con Let's Encrypt». La renovación automática también se rompe, y hay que monitorizarla (03-06).

De configuración

5. Dejar habilitados TLS 1.0/1.1 o suites con CBC, RC4 o 3DES.
6. Redirigir a HTTPS sin HSTS. La primera petición sigue viajando en claro.
7. Activar includeSubDomains y preload sin comprobar todos los subdominios. Difícil de revertir; puede dejar servicios inaccesibles.
8. Habilitar 0-RTT sin analizar la repetición.
9. No verificar la configuración efectiva cuando hay CDN o balanceador delante: lo que sirve el frontal puede no ser lo que configuraste.

De implementación

10. verify=False y equivalentes. El error canónico.
11. Validar la cadena pero no el nombre del host.
12. Aceptar a ciegas una huella SSH nueva o cambiada.
13. Fijar un pin de certificado sin plan de rotación. Convierte una renovación rutinaria en una caída.

Consejos

• Configura TLS 1.3 por defecto, deja 1.2 solo con suites ECDHE-AEAD si tienes clientes antiguos, y revisa esa decisión con datos de tus registros cada seis meses.
• Monitoriza la fecha de caducidad de cada certificado con alerta a 30 y a 7 días. Un certificado caducado es una incidencia de disponibilidad, y en Equifax (02-06) cegó además la detección.
• Automatiza la verificación: una comprobación programada que ejecute openssl s_client contra tus dominios y alerte si cambian la versión, la suite o la huella del certificado.
• Recuerda la jerarquía de responsabilidad: el protocolo lo eligen los estándares, la versión y la configuración las eliges tú, y la validación la respeta tu código. Los tres tienen que estar bien.

Lucía ejecuta openssl s_client contra un servicio interno y obtiene:

Se pide: (a) enumera todos los problemas que revela esta salida y ordénalos por gravedad; (b) explica qué garantía concreta se pierde con cada uno; (c) indica si el certificado autofirmado es siempre un fallo o puede ser aceptable, y bajo qué condiciones; (d) propón la configuración objetivo para este servicio interno.

Nimbus integra una nueva pasarela de pago. El proveedor ofrece: TLS 1.2 o 1.3, mTLS opcional, firma HMAC de los webhooks y una lista blanca de IP.

Se pide: (a) decide qué mecanismos activar y en qué dirección actúa cada uno (Nimbus→pasarela, pasarela→Nimbus); (b) explica qué amenaza concreta detiene cada mecanismo y cuáles se solapan; (c) indica qué pasa si la clave privada del certificado de cliente de Nimbus se filtra, y qué debe ocurrir entonces; (d) razona si la lista blanca de IP es un control criptográfico y qué valor real aporta.

Rubén pregunta por qué, si la web de Nimbus «redirige sola a HTTPS», hace falta configurar nada más.

Se pide: (a) describe paso a paso un ataque de stripping contra un cliente de Nimbus en la wifi de una cafetería; (b) explica por qué la redirección 301 no lo impide; (c) explica qué hace HSTS y qué añade preload; (d) indica los dos riesgos operativos de includeSubDomains y preload y cómo se mitigan antes de activarlos.

Ejercicio 1

(a) y (b) Problemas por gravedad:

(c) ¿Es siempre un fallo? No necesariamente. Para un servicio interno, lo inaceptable no es que el certificado no lo firme una CA pública, sino que no lo firme nada en lo que el cliente confíe explícitamente. Es aceptable si existe una CA interna cuyo certificado raíz está instalado en los clientes y estos lo validan de verdad (verify="/ruta/ca-interna.pem", apartado 11). Lo que nunca es aceptable es la combinación habitual: certificado autofirmado más verify=False en los clientes, que es cifrado sin autenticación.

(d) Configuración objetivo: certificado emitido por la CA interna de Nimbus (03-06), con SAN correcto para interno.nimbus.local; solo TLS 1.3, al ser todos los clientes propios; clave ECDSA P-256 o Ed25519; validación estricta en todos los clientes contra la raíz interna; y, dado que es comunicación entre servicios, mTLS (apartado 8), con renovación automatizada y alerta de caducidad.

Ejercicio 2

(a) y (b) Mecanismos:

Solapamientos. mTLS y lista blanca se solapan parcialmente en la dirección Nimbus→pasarela, pero actúan en capas distintas (identidad criptográfica frente a origen de red) y son complementarios en defensa en profundidad (01-03). TLS y HMAC no se solapan: TLS protege el canal, HMAC protege el mensaje, y sigue haciendo falta HMAC aunque el webhook llegue por HTTPS, porque HTTPS acredita el canal, no quién compuso el contenido.

(c) Si se filtra la clave privada del certificado de cliente: un atacante podría autenticarse ante la pasarela como Nimbus. Hay que revocar el certificado de inmediato, emitir uno nuevo con una clave nueva, desplegarlo, notificar al proveedor, revisar los registros de la pasarela en busca de operaciones no reconocidas y ejecutar el análisis de causa raíz (por qué la clave era accesible). El ciclo de vida completo, en 03-06.

(d) La lista blanca de IP no es un control criptográfico: no aporta confidencialidad, integridad ni autenticidad demostrable, y la dirección de origen es suplantable en algunos escenarios. Su valor real es reducir la superficie de ataque (01-04) y filtrar ruido automatizado. Es un control útil y barato, pero nunca puede sustituir a TLS ni al HMAC.

Ejercicio 3

(a) El ataque, paso a paso. (1) El cliente se conecta a la wifi de la cafetería, donde el atacante controla el punto de acceso o hace envenenamiento ARP. (2) Escribe nimbusreservas.example en el navegador, sin https://. (3) El navegador emite una petición HTTP en claro. (4) El atacante la intercepta y no la deja llegar; en su lugar establece él una conexión HTTPS legítima con Nimbus y sirve al usuario el mismo contenido por HTTP. (5) El usuario ve la web correcta, sin candado —pocos lo miran— e introduce sus credenciales. (6) El atacante las lee en claro y las reenvía a Nimbus, que ve una sesión perfectamente normal.

(b) Por qué la redirección 301 no basta. La redirección la envía el servidor, y en este ataque la petición inicial nunca llega al servidor: la intercepta el atacante, que simplemente no redirige. La redirección solo actúa cuando el tráfico llega a Nimbus; el ataque vive precisamente en el tramo anterior.

(c) Qué hace HSTS. La cabecera Strict-Transport-Security indica al navegador que, durante max-age segundos, debe usar HTTPS obligatoriamente para ese dominio, convirtiendo internamente cualquier http:// en https:// antes de enviar nada por la red. Tras una sola visita legítima, el stripping deja de funcionar. preload va más allá: el dominio se inscribe en una lista que los navegadores traen de fábrica, de modo que la regla se aplica incluso en la primera visita, cubriendo el único hueco que quedaba.

(d) Los dos riesgos operativos. (1) includeSubDomains obliga a HTTPS en todos los subdominios, presentes y futuros; si alguno —una web interna, un entorno de pruebas, un panel antiguo— solo sirve HTTP, dejará de ser accesible desde los navegadores que hayan visto la cabecera. (2) preload es muy difícil de revertir: la retirada de la lista tarda meses en propagarse con las versiones de los navegadores, así que un error se arrastra mucho tiempo. Mitigación: inventariar todos los subdominios y comprobar que sirven HTTPS válido; desplegar primero con un max-age corto (por ejemplo, 300 segundos) y sin preload; verificar durante unas semanas; y solo entonces subir a dos años y solicitar la inscripción.

Has dado el salto de las piezas al ensamblaje, y con él una idea que conviene no olvidar: combinar primitivas correctas no basta, porque un protocolo falla por no autenticar el intercambio, por una negociación manipulable, por falta de frescura, por fugar información en los errores o por estados no previstos —ninguno de esos fallos requiere romper el álgebra—. De ahí la extensión natural de la regla del módulo: los protocolos tampoco se diseñan a mano; se eligen, se configuran y se verifican.

Y has saldado la deuda pendiente desde el módulo 2. Sabes qué protege TLS —confidencialidad, integridad, autenticidad del servidor y forward secrecy en el tramo— y qué no: la aplicación, los metadatos, el servidor comprometido y el cliente infectado. Conoces la evolución hasta TLS 1.3 y sus cinco mejoras, con la más importante siendo la que menos se cita: que es seguro por defecto, porque las opciones malas ya no existen. Has recorrido el handshake paso a paso viendo exactamente dónde entra ECDHE —y con él la forward secrecy—, dónde entra el certificado con su CertificateVerify, que es lo que cierra la puerta al MITM, y dónde empieza el cifrado simétrico AEAD; sabes leer una suite y descartar en un vistazo las que no llevan ECDHE o llevan CBC. Lo has verificado en la práctica con openssl s_client interpretando depth, cadena, versión, suite y Verify return code, y con curl -I para HSTS; y has configurado el frontal de Nimbus directiva a directiva: versiones, suites, curvas, reanudación sin 0-RTT, grapado OCSP, HSTS y redirección. Añades mTLS para pocos sistemas de alto valor, la panorámica de SSH con su confianza en la primera conexión y la huella que nunca se acepta a ciegas, IPsec y WireGuard, S/MIME y PGP, el E2EE como concepto y el sellado de tiempo. Cierras con los ataques clásicos —downgrade, stripping con HSTS como respuesta, MITM con certificado falso y el papel real y los riesgos del pinning, repetición, oráculo de relleno y compresión— y con el error de implementación canónico, el verify=False, que conserva íntegro el coste de TLS y anula por completo su garantía.

Pero fíjate en cuántas veces has tenido que aplazar la misma respuesta. ¿Cómo sabe el cliente que ese certificado es de Nimbus? ¿Quién lo emitió y con qué garantía? ¿Qué pasa cuando la clave se filtra o el certificado caduca? ¿Cómo se monta la CA interna que necesitan el mTLS y los servicios internos? Toda la seguridad de este capítulo descansa sobre la validación de un certificado, y todavía no hemos abierto esa caja.

En Gestión de Claves, Certificados y PKI (03-06) entramos en lo que el módulo 2 anunció como «el problema realmente difícil», y la tesis es contundente: los algoritmos casi nunca fallan; la gestión de claves sí. Verás el ciclo de vida completo de una clave, dónde debe vivir —de la variable de entorno al HSM—, por qué borrar el commit del .env filtrado en el incidente de 02-06 no basta, cómo se rota sin cortar el servicio, qué contiene exactamente un certificado X.509, cómo funciona la cadena de confianza, qué garantizan las CA, cómo se emite con ACME, cómo se revoca y cómo la transparencia de certificados permite a Nimbus detectar un certificado emitido indebidamente para su dominio.