$ ssh lab-03-mtls-chain·M03 · L7

Servicios de Red, Resolución y Criptografía de Tránsito

10.0.3.0/24dns:53 · tls:443 · mtls

Objetivo: emitir CA efímera y probar mTLS.

Runtime: Linux, Bash, openssl

Comprensión0/5 lecciones

Práctica verificada0/2 checks

Empezar: El problema: llegar a una IP no prueba con quién hablaste~10 min

subred M03 · 0/4 hosts en línea · ver en el cielo →

Lee el mecanismo; después interroga la evidencia.

La teoría define qué debe ocurrir. Las figuras y tablas reducen el mecanismo a señales observables; la topología y el inspector de paquete permiten comprobarlo después. Cada lección termina con «Lo entiendo»: márcala cuando puedas explicarla, no cuando la hayas leído.

Conceptos disponibles19

El problema: llegar a una IP no prueba con quién hablaste

Una aplicación puede resolver un nombre, abrir TCP y aun así estar conectándose al servicio equivocado. DNS responde “a qué IP intento ir”; TLS responde “qué clave e identidad presentó el peer”; mTLS añade “qué identidad presentó también el cliente”. Confundir esas respuestas conduce a atajos como desactivar la validación de certificado, que cifra el tráfico pero elimina la verificación del interlocutor. [1,2]

Al terminar podrás diagnosticar casos como: “DNS funciona y la TCP existe, pero el SAN del certificado no corresponde a api.internal; la conexión debe rechazarse”. Esa separación es la base de entre servicios.

Mapa mínimo: nombre, camino e identidad son controles distintos

Flujo del mecanismo4 etapas

Nombre, camino e identidad

Resolver una IP no prueba la identidad del servicio.

intención

aplicación. Solicita un nombre y decide el destino esperado.

Ver la figura original

aplicación
   │ pregunta «¿dónde está api.internal?»
   ▼
DNS ── nombre → IP, TTL, tipo de respuesta
   │ abre conexión a esa IP
   ▼
TCP ── comprueba alcance y sesión
   │ negocia claves y presenta certificados
   ▼
TLS/mTLS ── ¿la identidad y el contexto están autorizados?

Aprende primero a no mezclar las capas. Un registro A correcto no autentica; selecciona un certificado pero tampoco autentica; una cadena válida no basta si el SAN no coincide con la identidad esperada. [1,2]

Ruta de estudio y conexión con el roadmap

Lee una respuesta DNS como estructura: nombre, tipo, TTL y RCODE.
Separa resolución de establecimiento TCP.
Recorre TLS 1.3 como negociación de secreto y prueba de identidad.
Añade mTLS y política por /SAN para decidir quién puede llamar.

En Kubernetes, el módulo siguiente hará que esta misma conversación atraviese , Services, y NetworkPolicies: descubrir un no equivale a estar autorizado a usarlo.

Referencia técnica: DNS, TLS y mTLS

DNS usa /53; TCP/53 sirve transferencias, respuestas grandes/fallback. Cabecera: ID, QR/Opcode/AA/TC/RD/RA/RCODE, QD/AN/NS/AR. RR: NAME, TYPE, CLASS, TTL, RDLENGTH, RDATA. A entrega ; SRV prioridad/peso/puerto/target; TXT texto opaco. TTL permite cache, no autorización. [1]

TLS 1.3 negocia secreto efímero con ClientHello (SNI, ALPN, key share), ServerHello y mensajes cifrados. X.509 vincula clave/identidad: valide trust anchor, tiempo, SAN/hostname, key usage y revocación. SNI selecciona virtual host, no autentica.

mTLS exige certificado de ambos pares. Autorice URI SAN/SPIFFE ID concreta, no sólo cadena válida. emite/rota identidad; data plane decide por conexión. [2]

Elemento	Verificación	Riesgo
DNS	RCODE, TTL, servidor	egress por nombre no controlado
TLS servidor	SAN/cadena/tiempo	skip verify
TLS cliente	CA/SAN workload	confiar CA demasiado amplia
rotación	trust bundle solapado	cert permanente

Pulsa una fila para fijarla.

Referencia: no cuenta para tu progreso. Vuelve aquí cuando necesites un campo o un estado concreto.

DNS: una respuesta es una estructura, no sólo una IP

Cabecera DNS separa pregunta, respuesta, autoridad y adicional. QR distingue query/response; RD pide recursión; RA declara disponibilidad; AA indica respuesta autoritativa; RCODE comunica resultado. Resolver puede seguir CNAME/delegaciones y cachear respuestas o errores. Registre nombre, servidor, RCODE, TTL e IP final: una IP sola no explica resolución. [1]

Figura

Query: ID=0x4a11 RD=1 QNAME=api.internal QTYPE=A
Reply: ID=0x4a11 QR=1 RA=1 RCODE=NOERROR
       Answer: api.internal. 30 IN A 10.60.0.20
       Additional: _grpc._tcp.api.internal. 30 IN SRV 0 5 8443 api.internal.

Resultado	Significado	Error común
NXDOMAIN	nombre no existe	reintentar en resolver público
SERVFAIL	resolver no completó	asumir fallo de aplicación
NOERROR sin Answer	existe, pero no ese tipo	ignorar QTYPE
TC=1	truncado en UDP	bloquear TCP/53

Pulsa una fila para fijarla.

DNS dirige conexión; no prueba identidad. Aún con IP correcta, TLS debe validar el peer y egress debe limitar resolver/destino. [3,2]

TLS 1.3: autenticación, secreto y contexto

TLS 1.3 negocia secreto efímero con ClientHello (SNI, ALPN, key share), ServerHello y mensajes cifrados. CertificateVerify prueba clave privada; Finished vincula transcripción de . El cliente sigue obligado a validar trust anchor, tiempo y SAN esperado. [2]

Flujo del mecanismo4 etapas

TLS 1.3 con mTLS en un solo viaje de ida y vuelta

Cada mensaje responde a una pregunta distinta: parámetros, identidad del servidor, identidad del cliente.

propuesta

ClientHello. El cliente propone versión, SNI (a qué nombre quiere hablar), ALPN y su parte del intercambio de claves (key_share).

Ver la figura original

app                         api
ClientHello(SNI, ALPN, key_share) ─────────►
◄──────── ServerHello + {Certificate, CertificateVerify, Finished}
{Certificate, CertificateVerify, Finished} ─►
◄──────── application data with traffic keys

Chequeo	Antes de autorizar	Rechazo sano
servidor	SAN api.internal	cert válido para db.internal
cadena	issuer esperado	CA pública inesperada
cliente	URI SAN permitida	workload de otro
contexto	método/puerto/destino	client válido hacia DB

Pulsa una fila para fijarla.

Caso visual: DNS correcto, TLS incorrecto

Si DNS devuelve 10.60.0.20 y TCP conecta, pero hostname mismatch, transporte funcionó y autenticación falló. No se arregla con insecure-skip-verify: investigue SAN, SNI, despliegue y trust bundle. [2]

Trampas en producción

TC=1 exige fallback . [1]
privada necesita emisión/trust bundle/rotación automatizadas. [2]
Laboratorio usa CN: producción exige SAN validado.

Referencias de la lectura 3

[1] Chris Sanders · Practical Packet Analysis · PPA, cap. 8 · No Starch Press
[2] Evan Gilman y Doug Barth · Zero Trust Networks · ZTN, cap. 2 · O'Reilly Media
[3] Chris Sanders · Practical Packet Analysis · PPA, caps. 8–9 · No Starch Press

Fuentes del módulo 2

DNS y L7: Practical Packet Analysis (PPA), caps. 8–9. CA, PKI, trust: Zero Trust Networks (ZTN), cap. 2. TLS 1.3 es actualización operativa, no atribución a PPA 2009.

PPA Practical Packet AnalysisCapítulo 8: Common Upper-Layer Protocols · Capítulo 9: Real-World Scenarios
ZTN Zero Trust NetworksCapítulo 2: Managing Trust

Checkpoint 03 · predice antes de revelar

DNS correcto no autentica al peer TLS

El resolver interno responde api.internal → 10.60.0.20. El cliente abre TLS con SNI api.internal, pero el certificado recibido tiene como SAN sólo payments.internal.

DNS: RCODE=NOERROR, A api.internal 10.60.0.20, TTL 30
ClientHello: SNI=api.internal, ALPN=h2
Certificate: DNS:payments.internal; no SAN DNS:api.internal

¿Qué decisión preserva el modelo Zero Trust?

Inspector de paquete

app→dns UDP/53

10.60.0.10:49152 → 10.60.0.53:53

IPv4UDPDNS

IPv4 · bits 64–71 · 8 bits

TTL

Saltos restantes. Cada router lo decrementa; en 0 descarta y emite ICMP Time Exceeded.

Cambia en cada salto: por eso el checksum IP se recalcula en cada router.

58 bytes · hex

0000

0008

0010

0018

0020

0028

0030

0038

Supuestos de la síntesis

Puerto origen 49152: primer puerto efímero IANA, ilustrativo.
TTL inicial 64 (valor por defecto de Linux); Identification 0x1c46 ilustrativo.
Consulta A para api.internal, tomada del registro declarado en dns. Transaction ID ilustrativo.

Walkthrough

host Linux, OpenSSL 1.1.1+, directorio .lab-03.

lab-03-mtls-chainsetup

1# setup · lab-03-mtls-chain

2set -euo pipefail

3rm -rf .lab-03; mkdir .lab-03; cd .lab-03

4openssl req -x509 -newkey rsa:2048 -nodes -days 1 -subj '/CN=learn-ca' -keyout ca.key -out ca.crt >/dev/null 2>&1

5for name in server client; do

6 openssl req -newkey rsa:2048 -nodes -subj "/CN=$name" -keyout "$name.key" -out "$name.csr" >/dev/null 2>&1

7 openssl x509 -req -days 1 -CA ca.crt -CAkey ca.key -CAcreateserial -in "$name.csr" -out "$name.crt" >/dev/null 2>&1

8done

9nohup openssl s_server -accept 8443 -cert server.crt -key server.key -CAfile ca.crt -Verify 1 -www >server.log 2>&1 &

10# paso 1

$ openssl s_client -connect 127.0.0.1:8443 -servername api.internal -CAfile .lab-03/ca.crt -cert .lab-03/client.crt -key .lab-03/client.key -verify_return_error

12# paso 2

13↳ Se espera Verify return code: 0 (ok).

14# paso 3

15$ openssl x509 -in .lab-03/server.crt -noout -issuer -subject -dates

Las líneas con ↳ son la salida esperada que declara el laboratorio, no una ejecución real.

Definición de Terminado

El laboratorio está cerrado cuando los 2 checks pasan y el script imprime PASS-lab-03.

0/2

openssl verify -CAfile .lab-03/ca.crt .lab-03/server.crt | grep -q ': OK'
Comprueba que la salida contiene «: OK».
Lo verifiqué a mano
openssl s_client -connect 127.0.0.1:8443 -CAfile .lab-03/ca.crt -cert .lab-03/client.crt -key .lab-03/client.key -verify_return_error </dev/null 2>&1 | grep -q 'Verify return code: 0 (ok)'
Comprueba que la salida contiene «Verify return code: 0 (ok)».
Lo verifiqué a mano

¿Vas a practicar en Linux? Verifica tu entornoOpcional

Usa esta ruta sólo después de preparar el laboratorio en tu propia máquina. No hace falta instalar ni ejecutar nada para leer, explorar o completar los checkpoints.

pnpm verifier:build
sudo ./bin/lnverify run lab-03-mtls-chain --json

Carga tu verificación

Ejecuta el script instrumentado. Evalúa cada check por separado y escribe una línea ::lnet por check, en vez de abortar en el primero.
O usa el verificador en Go, que produce los mismos marcadores o JSON:
sudo ./bin/lnverify run lab-03-mtls-chain
Pega la salida aquí. También vale la salida del script original (PASS-lab-03) o una traza de bash -x.