1Por qué importa
TLS es la defensa sobre la que descansa casi todo lo demás, y también la más malentendida. Se le atribuye una garantía de identidad que solo cumple si la verificación del certificado está bien hecha, y se le atribuye una protección del contenido que nunca da: TLS asegura el transporte, no lo que la aplicación hace con lo transportado. Confundir esas fronteras lleva a dos errores opuestos y frecuentes: fiarse de más de un canal cifrado, y creer que “ya está en HTTPS” resuelve problemas de aplicación.
El punto donde TLS se rompe en la práctica casi nunca es la criptografía. Es la verificación: un cliente que acepta cualquier certificado, una biblioteca con la comprobación desactivada “para que funcione en desarrollo” que llega a producción, una CA de pruebas instalada en el sistema y olvidada. La cadena de confianza es fuerte; los eslabones humanos que la rodean, no tanto. Esta lección se centra ahí porque es donde ocurren los incidentes.
Y hay una razón de continuidad. La lección anterior te dejó una cookie con el
atributo Secure pendiente porque el laboratorio servía en claro.
Aquí ese servicio pasa a HTTPS y el atributo empieza a proteger de verdad. TLS
es lo que convierte varias defensas de la fase de aplicaciones de teatro en
controles reales, y por eso va antes que ellas.
El entregable es una frase que puedas defender ante alguien que diga “está en HTTPS, es seguro”: qué garantiza exactamente ese candado, contra quién, y qué deja fuera. Si la frase no distingue transporte de contenido y cifrado de autenticación, todavía no entiendes qué te da TLS.
2Conceptos
- Handshake: la negociación inicial donde cliente y servidor acuerdan versión, cifrado y claves.
- Certificado: un documento firmado que ata una clave pública a una identidad (un nombre).
- Autoridad certificadora (CA): quien firma certificados y a quien alguien decide creer.
- Cadena de confianza: la secuencia de firmas desde el certificado del servidor hasta una raíz en la que confías.
- Almacén de confianza: la lista de raíces que tu sistema o navegador acepta sin preguntar.
- SAN: el campo del certificado que dice para qué nombres es válido; lo que de verdad se verifica.
- Confidencialidad hacia delante: una propiedad por la que comprometer la clave del servidor no descifra sesiones pasadas.
- Fijación: exigir un certificado o una clave concretos en vez de aceptar cualquiera que la cadena valide.
3Explicación profunda
TLS da tres garantías y conviene enumerarlas por separado porque se rompen por separado. Confidencialidad: quien mira el cable ve tráfico cifrado. Integridad: si alguien altera un byte por el camino, se detecta. Autenticación: sabes con quién hablas, siempre que verifiques el certificado. Las dos primeras son casi automáticas una vez negociada la sesión; la tercera depende de un paso que el software puede hacer mal o saltarse, y por eso es la que falla.
El handshake es donde se acuerda todo. En TLS 1.3, el cliente ofrece las versiones y algoritmos que soporta y ya manda su parte del material de claves; el servidor elige, presenta su certificado y su parte del material, y ambos derivan la misma clave de sesión sin que esa clave haya viajado nunca por el cable. Ese es el punto elegante: la clave con la que se cifra la conversación no se transmite, se calcula en los dos extremos a partir de piezas públicas y de un secreto que cada uno guarda. De ahí sale la confidencialidad hacia delante: como la clave de sesión es efímera, robar la clave del servidor tiempo después no descifra las sesiones que ya ocurrieron.
La autenticación es una cadena de firmas. El servidor presenta su certificado, firmado por una CA. Puede que esa CA esté firmada por otra, y otra, hasta llegar a una raíz. Tu sistema tiene una lista de raíces en las que confía por defecto —el almacén de confianza— y la verificación consiste en recorrer la cadena comprobando cada firma hasta encontrar una de esas raíces. Si la cadena llega a una raíz de confianza, y el nombre que pediste está en el campo SAN del certificado, y no ha caducado ni está revocado, la verificación pasa. Si falta cualquiera de esas condiciones, falla, y el aviso del navegador es esa comprobación funcionando.
Aquí está el matiz que casi todo el mundo pasa por alto: el nombre se verifica contra el SAN, no contra el campo de nombre común. Ese campo dejó de ser normativo hace años, y un certificado sin SAN lo rechazan los clientes modernos aunque el nombre común cuadre. Cuando emitas el certificado del laboratorio vas a poner el SAN a mano precisamente para ver esta pieza.
Y aquí está el error de diseño más caro de toda la lección: una CA en la que confías puede firmar un certificado para cualquier nombre. Si tu sistema confía en cien raíces, cualquiera de esas cien puede emitir un certificado válido para tu banco, y tu cliente lo aceptará. Esa es la razón de que instalar una CA de pruebas en el almacén del sistema sea tan peligroso: le das el poder de suplantar cualquier sitio. Por eso este laboratorio nunca toca tu almacén: la confianza en su CA se pasa a mano, en cada comando, con una bandera. La defensa contra el problema de las cien raíces es la fijación: exigir no “cualquier certificado que la cadena valide” sino “este certificado o esta clave concretos”.
Una última frontera, porque es la que más incidentes de aplicación causa: TLS protege el tráfico entre dos extremos. Cuando hay un proxy inverso que termina el TLS, como el de la lección anterior, la conversación cifrada acaba ahí; lo que va del proxy a la aplicación es otra cosa, y es responsabilidad tuya. “Todo está en HTTPS” suele significar “el primer tramo está en HTTPS”, y el resto del camino se da por supuesto sin haberlo comprobado.
4Ejemplo sencillo
# Un mensajero con un carnet confidencialidad hablais dentro de una cabina insonorizada integridad si alguien cambia una palabra, los dos lo notais autenticacion antes de entrar, el mensajero ensena un carnet # Como se comprueba el carnet el carnet lo firma una oficina. <- la CA tu confias en esa oficina porque <- el almacen de confianza esta en tu lista de oficinas validas. el carnet dice PARA QUE NOMBRE vale. <- el SAN si pediste hablar con Ana y el carnet es de Ana, y la firma es de una oficina de tu lista: pasa. # El fallo que casi nadie ve si confias en cien oficinas, CUALQUIERA de las cien puede emitir un carnet de Ana. por eso no metes una oficina de pruebas en tu lista y te olvidas de ella.
5Ejemplo técnico
Así se lee un handshake y una verificación reales. Esto es contra el servidor HTTPS del laboratorio, cuyo certificado firmó la CA que tú vas a crear:
Las tres líneas son la lección entera. La primera verifica de la forma correcta:
da la raíz explícitamente. La segunda falla porque el sistema no conoce esa
raíz, y ese fallo es el mecanismo protegiéndote. La tercera es la trampa: con
-k sigue habiendo cifrado, así que quien mire el cable no ve nada,
pero desaparece la autenticación, así que estarías hablando cifrado con
cualquiera. Esa opción, escrita en un script que llega a producción, es una de
las causas más comunes de intermediario aceptado.
| Situación | ¿Cifrado? | ¿Autenticado? | Consecuencia |
|---|---|---|---|
| Verificación correcta con la raíz | Sí | Sí | La garantía completa de TLS |
Cliente con -k o verificación desactivada | Sí | No | Intermediario indetectable: hablas cifrado con cualquiera |
| CA de pruebas instalada en el sistema | Sí | Sí, pero de más | Esa CA puede suplantar cualquier sitio |
| Certificado sin SAN para el nombre | Sí | No, y el cliente lo rechaza | Fallo correcto: el nombre no está avalado |
| TLS termina en el proxy | Solo hasta el proxy | Solo el proxy | El tramo interno es responsabilidad tuya |
La segunda fila es la que hay que grabar. Cifrado sin autenticación no es seguridad, es privacidad frente a terceros mientras hablas con el atacante. Es peor que no cifrar, porque da una sensación de protección que impide sospechar.
6Diagrama
Ver el mismo diagrama como código Mermaid (editable)
flowchart LR
S[certificado del servidor] --> I[CA intermedia]
I --> R[raíz en el almacén]
R --> OK[cadena OK: cifrado + autenticado]
S -. verificacion saltada .-> BAD[cifrado sin autenticacion]
7Código
Emitir un certificado es lo que hace tangible la cadena de confianza. Este es el corazón del script de la CA del laboratorio, con el SAN puesto a mano para que se vea qué se firma exactamente:
# 1. raiz de la CA del laboratorio (vive solo en el lab) openssl req -x509 -newkey rsa:2048 -sha256 -days 30 -nodes \ -keyout ca.key -out ca.crt \ -subj "/O=Laboratorio local/CN=CA del lab-net-tls" # 2. clave y peticion de firma del servidor openssl req -newkey rsa:2048 -sha256 -nodes \ -keyout servidor.key -out servidor.csr \ -subj "/O=Laboratorio local/CN=web-tls" # 3. el SAN: lo que de verdad se verifica, no el CN cat > san.cnf <<'EOF' subjectAltName = DNS:web-tls, DNS:localhost extendedKeyUsage = serverAuth basicConstraints = critical, CA:FALSE EOF # 4. la CA firma la peticion, incluyendo el SAN openssl x509 -req -in servidor.csr \ -CA ca.crt -CAkey ca.key -CAcreateserial \ -out servidor.crt -days 30 -sha256 \ -extfile san.cnf
El paso 3 es el que enseña la pieza. El nombre común del paso 2 es casi
decorativo; lo que un cliente moderno comprueba es la lista de nombres del SAN.
Y basicConstraints = critical, CA:FALSE es el que impide que este
certificado firme a su vez otros: sin esa línea, un certificado de servidor
podría comportarse como una CA, que es exactamente el tipo de confusión de la
que salen los incidentes graves.
8Qué puede salir mal
Desactivar la verificación para desarrollo. La bandera que ignora el certificado se pone “un momento” y viaja al repositorio, al contenedor y a producción. Es la causa número uno de intermediario aceptado en clientes propios.
Instalar una CA de pruebas en el sistema. Muchos tutoriales lo recomiendan porque quita el aviso del navegador. A cambio, esa CA puede firmar un certificado válido para cualquier sitio, y si la clave se filtra, cualquiera puede suplantar todo lo que visitas.
Creer que HTTPS protege el contenido. TLS asegura el transporte. Una inyección, un control de acceso roto o un dato mal validado ocurren dentro del túnel cifrado, con total comodidad.
Olvidar el tramo interno. Terminar el TLS en el proxy y mandar el resto en claro por la red interna está bien si esa red es de confianza, y es un problema en cuanto no lo es. “Está en HTTPS” describía solo el primer tramo.
9Cómo lo abusaría un atacante
Un atacante rara vez ataca la criptografía de TLS: es cara y suele estar bien. Ataca la verificación. Combina lo que aprendiste en la lección de DNS —conseguir que el nombre apunte a su servidor— con un certificado que el cliente acepte, y el trabajo está hecho. La pregunta es solo cómo consigue ese certificado válido.
La vía más cómoda es que el cliente no verifique. Un script con la comprobación desactivada, una aplicación móvil que acepta cualquier certificado, una biblioteca mal configurada: en todos esos casos no hace falta ningún certificado especial, porque el cliente no mira. La segunda vía es una CA de más en el almacén: si el atacante consiguió que se instalara una CA suya en algún momento, puede emitir certificados válidos para lo que quiera, y el candado aparece verde. La tercera, más difícil, es engañar a una CA legítima para que emita un certificado para un nombre que no es del solicitante, que es la razón de que existan mecanismos para vigilar qué certificados se emiten para tus dominios.
En todos los casos, el patrón es el mismo: el cifrado sigue funcionando y da sensación de seguridad, mientras la autenticación —la garantía que de verdad importa contra un intermediario— está rota o ausente. Por eso la defensa no es “usar TLS”, que ya se usa, sino verificar bien y reducir en quién se confía.
10Cómo defenderlo
- No desactives nunca la verificación, ni siquiera en desarrollo. Si necesitas confiar en una CA propia, pásala explícitamente, como hace el laboratorio.
- No instales CAs de pruebas en el almacén del sistema. Confía en ellas por comando o por proceso, nunca de forma global y permanente.
- Fija el certificado o la clave en los clientes que hablan siempre con el mismo servidor, para no depender de las cien raíces del almacén.
- Exige TLS moderno: 1.2 como mínimo, 1.3 cuando puedas, y retira las versiones antiguas en vez de dejarlas “por compatibilidad”.
- Cifra también el tramo interno cuando la red entre el proxy y la aplicación no sea de confianza, o segméntala para que lo sea.
- Vigila qué certificados se emiten para tus dominios, para detectar una emisión que tú no pediste.
11Laboratorio
down -v. No la instales en el almacén de tu
sistema: le darías el poder de suplantar cualquier sitio que visites. La
confianza se pasa a mano, con --cacert.
Levanta el laboratorio. Al arrancar, la CA emite su raíz y firma el certificado del servidor:
cd cursos/seguridad/labs/lab-net-tls
docker compose up -d --build
docker compose logs ca
Compara ahora los dos transportes. El mismo secreto viaja en claro por HTTP y cifrado por HTTPS; captura los dos y busca la cadena en la captura:
Ahora sigue el handshake y la cadena de confianza, y prueba las tres formas de verificar: con la raíz, sin ella, y apagándola:
docker compose exec cliente sh -c "echo | openssl s_client -connect web-tls:443 -servername web-tls -CAfile /certs/ca.crt 2>&1 | head -30"
docker compose exec cliente curl -s --cacert /certs/ca.crt https://web-tls/secreto
docker compose exec cliente curl -s https://web-tls/secreto ; echo salida=$?
docker compose exec cliente curl -sk https://web-tls/secreto
docker compose exec cliente openssl x509 -in /certs/servidor.crt -noout -ext subjectAltName
docker compose down -v
12Ejercicios
Di qué garantía falla en cada caso
Para cada situación, di cuál de las tres garantías —confidencialidad,
integridad, autenticación— falta: (1) un cliente con -k; (2)
HTTP en claro; (3) un certificado caducado que el cliente acepta igual; (4)
TLS 1.3 correcto con verificación de la raíz; (5) TLS que termina en el
proxy y sigue en claro por una red interna hostil.
(1) falta autenticación, hay cifrado. (2) faltan las tres. (3) falta autenticación: aceptar lo caducado es no verificar de verdad. (4) no falta ninguna, es la garantía completa. (5) en el primer tramo están las tres, en el segundo faltan todas, y como la red interna es hostil eso basta para comprometer la conversación entera.
Clave: autenticación · todas · autenticación · ninguna · todas en el tramo interno. Lo evaluable es que en (1) y (3) reconozcas que el cifrado sigue vivo.
Emite un certificado con el SAN equivocado
Modifica el script de la CA del laboratorio para emitir un certificado cuyo
SAN no incluya web-tls. Vuelve a levantar y comprueba qué dice
curl --cacert al conectar por ese nombre. Explica por qué falla
aunque la firma de la CA sea válida.
san.cnf, dentro de ca/generar.sh. Quita web-tls de la lista.down -v antes de volver a levantar.curl.
Con el SAN sin web-tls, curl --cacert falla con
un error de nombre, no de firma: la cadena valida perfectamente hasta la
raíz, pero el nombre que pediste no está entre los que el certificado
avala. Es exactamente la comprobación que muchos clientes mal escritos se
saltan, y por eso separarla de la validación de la cadena importa: son
dos comprobaciones distintas y un cliente puede hacer una y olvidar la
otra.
Clave: el error es de nombre, no de confianza. Si tu explicación dice “la firma es inválida”, has confundido las dos comprobaciones.
Investiga la transparencia de certificados
Existe un mecanismo público que registra casi todos los certificados que las CAs emiten, precisamente para detectar emisiones no autorizadas. Investiga fuera de esta lección y responde: ¿cómo se llama?, ¿qué problema de la CA “demasiado poderosa” mitiga y cuál no?, y ¿cómo lo usarías para vigilar tus propios dominios?
Se llama transparencia de certificados, y consiste en registros públicos donde las CAs anotan lo que emiten. Mitiga el problema de que una CA emita un certificado para un nombre que no le corresponde, porque esa emisión queda registrada y visible; no lo impide, solo lo hace detectable después. La ventana de daño es el tiempo entre la emisión y que alguien note el registro, así que la vigilancia tiene que ser activa.
El uso práctico es suscribirse a alertas por dominio: cuando aparece un certificado nuevo para uno de tus nombres que tú no solicitaste, es una señal temprana de suplantación o de un proceso interno descontrolado. Es barato de montar y detecta una clase de ataque que ninguna verificación del cliente puede ver.
Clave: detecta, no previene. Lo evaluable es que reconozcas la ventana de daño y propongas una vigilancia activa por dominio.
Red Team · el intermediario que el cliente acepta
Dentro del lab-net-tls, y solo dentro: demuestra que un cliente
que no verifica acepta cualquier certificado. Genera un certificado
autofirmado distinto del que emitió la CA, sírvelo, y consigue que el cliente
lo acepte con -k. Explica qué habría cambiado con verificación.
-k acepta un certificado que la CA del laboratorio nunca firmó.curl -k contra web-tls con curl --cacert /certs/ca.crt contra un certificado que no es el emitido.
El punto no es servir otro certificado, sino ver que -k
deja pasar cualquiera. Con verificación, un certificado que la CA de
confianza no firmó se rechaza de inmediato, porque su cadena no llega a
ninguna raíz conocida. Con -k, el cliente ni siquiera mira
la cadena: cifra y habla. Un atacante que se ha puesto en medio —con lo
aprendido en las lecciones de DNS y HTTP— solo necesita que el cliente
use esa bandera, y presenta su propio certificado sin que nadie proteste.
Con verificación correcta, ese mismo intermediario tendría que presentar
un certificado válido para el nombre y firmado por una raíz de confianza,
que es justo lo que no tiene. La autenticación es lo que lo detiene, y
-k es lo que la apaga.
Clave: lo demostrado es que -k convierte cualquier certificado en aceptable. Con verificación, la cadena que no llega a una raíz de confianza corta el ataque.
Blue Team · detecta la verificación desactivada
La verificación desactivada no deja rastro en el servidor: el handshake se ve normal. Piensa dónde sí se puede detectar y escribe una comprobación que la encuentre. Después aplícala a un repositorio tuyo y cuenta cuántos lugares apagan la verificación.
curl, una opción de la biblioteca HTTP, un contexto de TLS permisivo.insecure, verify=false, -k, rejectUnauthorized: false.La detección vive en el código del cliente, porque el servidor no distingue un cliente que verifica de uno que no. Una regla de búsqueda de patrones en el pipeline, que marque las formas conocidas de desactivar la verificación en cada lenguaje del repositorio, encuentra casi todas. El resultado típico de aplicarla por primera vez sorprende: suele haber varios, casi siempre en clientes de servicios internos y en código de pruebas que se coló al camino real.
La comprobación no debe bloquear siempre, porque hay usos legítimos en pruebas aisladas; debe exigir una justificación explícita al lado de cada aparición. Un patrón sin justificación es un hallazgo; con justificación revisada, una excepción documentada.
Clave: la detección es estática y del lado del cliente. El entregable es la regla de patrones y el recuento de apariciones en tu repositorio.
Architecture Challenge · confianza entre tus propios servicios
Diseña cómo se autentican entre sí los servicios internos de una plataforma sin depender del almacén de raíces públicas. Define: quién emite los certificados internos, cómo se distribuye la confianza, cómo se rotan, y por qué la fijación o una CA interna propia es preferible a confiar en las cien raíces públicas para tráfico que nunca sale a internet.
Una propuesta razonable: una CA interna propia, cuyo certificado raíz se distribuye a los servicios como única raíz de confianza para el tráfico interno. Cada servicio recibe un certificado de vida corta emitido automáticamente, con su identidad de carga en el SAN, y la rotación es continua en vez de un evento anual que da miedo. Para el tráfico que nunca sale a internet, esta CA sustituye por completo al almacén público.
La ventaja de seguridad es directa: el conjunto de quién puede emitir un certificado válido para un servicio interno pasa de las cien raíces públicas —cualquiera de las cuales sería un punto de fallo— a una sola CA que tú controlas. Es el mismo razonamiento que la fijación, aplicado a escala de plataforma, y conecta con la identidad de carga que la fase de identidad va a desarrollar.
Clave: no hay una única respuesta. Se evalúa que reduzcas el conjunto de emisores de confianza, que rotes con vida corta, y que justifiques por qué el tráfico interno no necesita las raíces públicas.
13Preguntas de comprensión
Un cliente conecta con -k. ¿Qué garantía de TLS pierde?
Cifrado sin autenticación es privacidad frente a terceros mientras hablas con el atacante. Es la trampa clásica de TLS.
¿Contra qué nombre se comprueba de verdad que un certificado es válido para un sitio?
Un certificado sin SAN lo rechazan los clientes modernos aunque el nombre común cuadre. Por eso se pone el SAN a mano al emitir.
¿Por qué es peligroso instalar una CA de pruebas en el almacén del sistema?
Una raíz de confianza puede avalar cualquier nombre. Añadir una es ampliar el conjunto de quién puede suplantarte, y si su clave se filtra, cualquiera hereda ese poder.
Terminas TLS en el proxy. ¿Qué protege TLS en ese diseño?
TLS asegura el transporte entre dos extremos. Si termina en el proxy, el tramo interno hay que protegerlo aparte o garantizar que la red es de confianza.
14Reto adicional
Audita la configuración TLS de un servicio tuyo
Toma un servicio que controles y audita su TLS con openssl
s_client: qué versiones acepta, qué certificado presenta, cuándo
caduca, qué contiene su SAN y si ofrece confidencialidad hacia delante.
Escribe qué cambiarías y por qué, con el vocabulario de esta lección.
openssl s_client -connect host:443 te muestra el certificado y la versión negociada.Los hallazgos habituales son tres: versiones antiguas aceptadas “por si acaso”, que amplían la superficie sin dar nada; certificados que caducan pronto sin un proceso automático de renovación, que son un incidente de disponibilidad programado; y SANs demasiado amplios o con nombres que ya no se usan. Ninguno es dramático por separado, y todos son baratos de arreglar una vez que sabes mirarlos.
La caducidad merece una mención especial porque une esta lección con la primera: un certificado caducado rompe la disponibilidad, no la confidencialidad, y es de las causas más frecuentes de caída total de un servicio. Automatizar la renovación es una defensa de disponibilidad disfrazada de tarea de criptografía.
Clave: el entregable es la lista de cambios con su motivo. Cada cambio debe nombrar qué garantía o qué propiedad mejora.
15Resumen
- TLS da tres garantías que se rompen por separado: confidencialidad, integridad y autenticación. La que falla casi siempre es la autenticación.
- El handshake acuerda la clave de sesión sin que esa clave viaje por el cable; de ahí sale la confidencialidad hacia delante.
- La verificación es una cadena de firmas hasta una raíz de confianza, y el nombre se comprueba contra el SAN, no contra el nombre común.
- Cualquiera de las raíces de tu almacén puede avalar cualquier nombre. Por eso instalar una CA de pruebas en el sistema es peligroso, y la fijación reduce el conjunto de emisores.
- Cifrado sin autenticación no es seguridad: es hablar cifrado con el atacante. La bandera que apaga la verificación es la causa número uno de este fallo.
- TLS protege el transporte entre dos extremos. Ni el contenido de la aplicación ni el tramo posterior a un proxy están cubiertos por “está en HTTPS”.
16Mis notas
Estas notas se guardan solo en este navegador. No se envían a ningún servidor. Expórtalas desde el panel de progreso si cambias de máquina.
17Recursos
Los comentarios se cargan solo si los pides, desde GitHub Discussions. No se carga nada de terceros mientras no pulses.