BIBLIOTECA ASTRACode Cyber

CAPÍTULO 34 · PARTE III

TLS: handshake, autenticación y canales seguros

Cómo TLS 1.3 negocia, liga y protege una sesión; cómo se valida la identidad de servicio o de cliente; y qué límites introducen TLS 1.2, PSK, 0-RTT, SNI, ALPN, proxies y la política de aplicación.

Nivel N2–N3 · Estado published

El problema: un canal no es una identidad ni una autorización

Cuando un cliente abre una conexión hacia api.aurora.example, el transporte puede entregar los bytes en orden y, aun así, quedan abiertas preguntas distintas: ¿quién controla el extremo que respondió?, ¿alguien alteró la negociación?, ¿el contenido quedó expuesto en un terminador?, ¿la aplicación permite esa operación? Transport Layer Security (TLS) responde sólo a una parte de esas preguntas. Su modelo profesional no es «poner un candado», sino relacionar negociación, secretos, autenticación y protección de registros bajo supuestos explícitos.

TLS 1.3 define un handshake para negociar parámetros, establecer material secreto y autenticar uno o ambos extremos, y una record layer para proteger fragmentos de tráfico con las claves derivadas. En el caso normal con certificado de servidor, el cliente autentica una identidad de servicio; la autenticación del cliente es opcional. RFC 9846, §§1–2

Conviene separar cuatro propiedades:

Desliza horizontalmente para consultar todas las columnas.

Propiedad Qué puede aportar TLS Qué sigue fuera del protocolo
Confidencialidad Ocultar el plaintext de records frente a observadores que no tienen las traffic keys. El contenido antes de cifrar o después de descifrar, endpoints, terminadores y muchos metadatos.
Integridad/autenticidad del canal Detectar modificación o fabricación de records sin la clave; ligar la negociación al transcript. Entrega, corrección semántica, ausencia de reintentos o un endpoint honesto.
Autenticación Vincular una clave a una identidad aceptada por la política local, o demostrar conocimiento de un PSK. Legitimidad del negocio, intención del usuario o autorización de una operación.
Autorización Nada por defecto. Una aplicación puede usar una identidad TLS como una entrada de su política. Decidir qué principal puede leer, escribir, transferir o administrar un recurso.

Este capítulo usa TLS 1.3 como modelo operativo, compara sólo los límites relevantes de TLS 1.2, y trata certificados, mutual TLS (mTLS), reanudación, 0-RTT, SNI, ALPN, alertas y terminación en proxies. No implementa criptografía, no es una guía de configuración de una marca y no ofrece instrucciones para interceptar tráfico ajeno.

Caso conductor y threat model

Aurora Health publica api.aurora.example. Un cliente autorizado resuelve el nombre, abre TCP hacia un edge y negocia TLS. El edge puede operar en dos diseños:

  1. Passthrough: reenvía bytes y el origen termina TLS. El edge ve metadatos de red, pero no el plaintext ni el certificado que el origen presenta al cliente.
  2. Terminación y re-cifrado: el edge termina una sesión TLS cliente–edge y crea otra edge–origen. Cada tramo tiene handshake, claves, identidad y política propios. El origen ve como peer TLS al edge salvo que exista un contrato adicional para propagar una identidad.

El adversario del modelo controla la red entre dos endpoints TLS: puede observar, reordenar, descartar, retrasar o sustituir mensajes. No se supone que posea las claves privadas ni que el cliente esté comprometido antes de cifrar. Un proxy autorizado no es «el atacante» por definición, pero sí cambia los extremos y el alcance de las garantías. TLS no protege una credencial escrita en un navegador comprometido ni un secreto que un servidor entrega a su propio proceso de logging.

Versión y alcance: TLS 1.3 primero, TLS 1.2 con límites

TLS 1.3 se especificó originalmente en RFC 8446; RFC 9846 es la especificación vigente desde julio de 2026. Obsoleta RFC 8446, 5246, 5077, 6961, 7627 y 8422, y actualiza RFC 5705 y 6066. TLS 1.3 restringe las cipher suites a combinaciones de AEAD y hash de HKDF; el intercambio de claves y la autenticación se negocian por otros campos. También elimina compresión y renegociación del protocolo 1.3. RFC 9846, front matter y §§1.2, 4 y 9

TLS 1.2 no es sinónimo de «roto»: ECDHE con una suite AEAD puede ofrecer forward secrecy, si la implementación y la política lo hacen correctamente. Pero su espacio de configuración es mayor: las cipher suites combinan más decisiones, existen familias CBC históricas, compresión a nivel TLS y renegociación. Un despliegue 1.2 debe atender, entre otras restricciones, renegotiation_info y extended_master_secret; TLS 1.3 elimina la renegociación. RFC 9325 recomienda preferir TLS 1.3, exige que TLS 1.2 siga las restricciones de esa BCP cuando se usa y desaconseja volver a versiones antiguas. RFC 9325, §§3.1.1, 3.2, 3.5 y apéndice A

TLS 1.0 y 1.1 están deprecadas por RFC 8996; no son un fallback aceptable. Para un protocolo nuevo que use TLS, RFC 9852 exige especificar TLS 1.3 como versión predeterminada; TLS 1.2 puede ofrecerse únicamente como opción adicional no predeterminada por compatibilidad. Esta prescripción no se extrapola a DTLS. RFC 8996, §§1–2; RFC 9852, §4

La versión negociada no se deduce de un nombre en una interfaz. En TLS 1.3 el cliente anuncia supported_versions en ClientHello; el campo heredado legacy_version no debe interpretarse como la versión final. El servidor selecciona una versión y el mecanismo de downgrade permite detectar ciertos retrocesos. RFC 9846, §§4.2.3 y 4.3.1

Qué ocurre en el handshake

ClientHello propone, ServerHello selecciona y, después, los mensajes de handshake se protegen y confirman el transcript.
El handshake separa propuesta, selección y frontera de protección.

Alcance: HRR no es un segundo handshake independiente.

ClientHello: propuesta, contexto y material efímero

El ClientHello propone versiones, cipher suites, grupos soportados, key_share, algoritmos de firma y extensiones. key_share suele contener una contribución efímera de (EC)DHE; no es una clave de sesión ni una identidad. El cliente puede incluir un server_name (SNI) para indicar el nombre de servicio que espera y application_layer_protocol_negotiation (ALPN) para proponer protocolos de aplicación como HTTP/2. SNI ayuda a seleccionar un certificado o virtual host; ALPN ayuda a seleccionar un protocolo. Ninguna extensión autentica por sí sola al peer. RFC 9846, §4.2.2 y §§4.3.1, 4.3.3–4.3.5; RFC 6066, §3; RFC 7301, §§3–4

El ClientHello suele ser visible en un TLS 1.3 ordinario: contiene direcciones y tiempos observables en el transporte, tamaños y normalmente el SNI. Extensiones de privacidad como Encrypted ClientHello cambian qué ve un observador, pero no convierten el tráfico en ausencia total de metadatos; sus requisitos de despliegue quedan fuera de este capítulo.

Si el servidor necesita otro grupo, puede responder con HelloRetryRequest (HRR). No debe dibujarse como un segundo handshake independiente: TLS incorpora un message_hash al transcript y el cliente envía otro ClientHello coherente con la solicitud. RFC 9846, §§4.1 y 4.2.4

ServerHello: selección y frontera de protección

ServerHello selecciona la versión, cipher suite, grupo y key_share compatibles. Con las contribuciones efímeras, ambos extremos calculan el mismo secreto (EC)DHE sin enviarlo. Después de ServerHello, el protocolo deriva los handshake traffic secrets. En el flujo normal, EncryptedExtensions, Certificate, CertificateVerify y Finished se transportan como records protegidos por esas claves; ClientHello y ServerHello no se vuelven retroactivamente secretos. RFC 9846, §2, §§4.4.1–4.4.2 y §§4.5.1–4.5.3

Un ServerHello observado demuestra una selección en ese punto, no una autenticación ya completada. Si el transcript que ve cada extremo difiere, el Finished fallará o la validación del handshake abortará. El transcript hash no oculta mensajes: liga las decisiones y firmas posteriores a una historia concreta. RFC 9846, §§4.1 y 4.5.3

Parámetros, certificado y prueba de posesión

El servidor envía EncryptedExtensions con extensiones aceptadas que no eran necesarias para derivar las primeras claves. Si usa autenticación por certificado, envía Certificate; si el cliente la solicita, puede enviar también CertificateRequest para autenticación del cliente.

Estos mensajes responden preguntas distintas:

El cliente verifica el CertificateVerify del servidor y envía su Finished. En mTLS, el servidor incluye CertificateRequest; el cliente responde con Certificate y CertificateVerify antes de Finished. Esa autenticación mutua sólo afirma una identidad de certificado bajo políticas de ambos lados. La aplicación todavía debe mapear esa identidad a un principal y autorizar la operación. Si el servidor acepta PSK sin certificado, el flujo de reanudación puede autenticar continuidad del PSK y omitir esos mensajes de certificado: «hubo certificado» no es una propiedad universal de TLS.

Finished y transición a application data

Finished usa un finished_key derivado y el transcript; confirma que el peer llegó al mismo estado criptográfico. Una firma CertificateVerify válida sin Finished no prueba que ambas partes derivaron las mismas traffic keys. Un Finished válido sin validación de nombre no prueba que el peer sea el servicio esperado. Tras verificar ambos Finished, cada dirección puede proteger application records con sus secretos de aplicación.

Identidad: ruta, nombre, tiempo, revocación y política

La identidad TLS requiere cadena y trust anchor, nombre RFC 9525, tiempo, uso y prueba del handshake; la autorización de aplicación queda fuera.
La identidad aceptada es una decisión compuesta y acotada.

Alcance: CT, revocación y pinning aportan señales, no autorización.

La validación de un certificado es una decisión compuesta, no una comparación visual ni una sola firma.

  1. Ruta: el cliente construye una ruta hasta un trust anchor local, valida firmas, basicConstraints, keyUsage, políticas y límites de camino según RFC 5280, §6. El trust anchor es configuración local; no «viaja» como una propiedad del certificado. RFC 5280, §6
  2. Tiempo: comprueba notBefore y notAfter usando un reloj y una política de tolerancia. Un certificado no válido por tiempo puede ser rechazado aunque la cadena sea criptográficamente correcta; el reloj local y la ventana observada forman parte de la evidencia.
  3. Nombre: para una identidad de servicio basada en DNS, el cliente compara la referencia de identidad con subjectAltName:dNSName siguiendo las reglas del protocolo de aplicación. RFC 9525 —que obsoleta RFC 6125— exige construir la referencia independientemente de los identificadores presentados, usar subjectAltName y aplicar límites estrictos a los comodines. RFC 9525, §§6.1–6.3
  4. Uso: verifica que el certificado sea apto para el papel que se está autenticando, por ejemplo serverAuth o clientAuth, conforme a la política y a las extensiones del certificado.
  5. Revocación: CRL y OCSP pueden aportar estado de revocación, pero la disponibilidad, frescura, stapling, caché y tratamiento de fallos varían. RFC 5280, §§5–6, define perfiles de CRL y validación; OCSP está especificado en RFC 6960. Una aplicación concreta puede no consultar en tiempo real, y «no se obtuvo respuesta OCSP» no es por sí solo prueba de que el certificado sea válido o revocado.
  6. Transcripción y clave: se valida CertificateVerify y el binding al handshake; la cadena no basta si el extremo no controla la privada.

Certificate Transparency (CT) añade auditabilidad de certificados públicos mediante logs append-only y Signed Certificate Timestamps. RFC 9162, §§1 y 4, deja claro que CT permite detectar emisiones sospechosas; no impide por sí mismo una emisión incorrecta, no reemplaza la validación de cadena/nombre/tiempo y no convierte un candado en autorización. RFC 9162, §§1 y 4

El pinning también es una política local con cobertura y ciclo de rotación propios. Puede detectar cambios inesperados en un conjunto de claves, pero un pin mal operado rompe disponibilidad y un pin correcto no evalúa autorización de negocio. Ningún CT, pinning o mecanismo de revocación debe describirse como garantía total.

Un certificado válido tampoco prueba que la organización sea honesta, que el sitio sea legítimo para el usuario, que la aplicación esté libre de vulnerabilidades o que una transferencia esté autorizada. Prueba, en el mejor caso, que una política aceptó una identidad de servicio y una clave ligada a este handshake.

Key schedule: separación de secretos, no «una clave de sesión»

PSK y ECDHE alimentan secretos TLS 1.3 separados por fase y dirección; main secret deriva secretos de aplicación, exportación y reanudación.
El key schedule separa propósito, fase y dirección.

Alcance: los labels HKDF históricos no cambian el nombre semántico main secret.

TLS 1.3 usa HKDF. El modelo conceptual es:

PSK opcional ──► early secret
                    │       + transcript
(EC)DHE ────────────┴──────► handshake secret
                                  ├─ client/server handshake traffic secret
                                  └─ Finished keys
                         ───────► main secret
                                  ├─ client/server application traffic secret
                                  ├─ exporter_secret (label histórico: "exp master")
                                  └─ resumption_secret (label histórico: "res master")

RFC 9846 denomina main secret al valor central del schedule; algunos labels HKDF conservan la palabra histórica master por compatibilidad y no deben confundirse con el nombre semántico vigente. Los labels y hashes del transcript separan propósito, fase y dirección. El secreto (EC)DHE no se usa directamente como clave AEAD. En un handshake completo, los valores efímeros permiten forward secrecy frente al compromiso posterior de una clave de identidad, bajo la condición de que se destruyan secretos efímeros y no exista otra exposición. En una reanudación PSK + (EC)DHE, la conexión nueva combina continuidad del PSK y un intercambio nuevo. Una reanudación PSK-only no ofrece el mismo forward secrecy frente al compromiso del PSK. RFC 9846, §§2.1 y 7.1

La separación de claves también separa las direcciones: un servidor no debe cifrar application data con la traffic key de cliente. Cada record consume un número de secuencia implícito y un nonce derivado según el algoritmo; reutilizar un nonce con la misma clave rompe el supuesto de AEAD. RFC 9846, §§5.2–5.3

Record layer, límites y cierre

La record layer fragmenta tipos de contenido en records y protege plaintext con AEAD, asociado a la clave y al estado de esa dirección. Tras el handshake, el tipo externo suele ser application_data; el tipo real se protege dentro del record. Padding puede cambiar longitudes, pero no elimina análisis de tamaño, temporización, volumen, endpoints o patrón de comunicación. RFC 9846, §§5.1–5.5 y apéndice E.3

AEAD detecta modificación y fabricación de records, pero no garantiza que un segmento TCP llegue, que el peer lo entregue a la aplicación ni que el mensaje de negocio sea correcto. Un atacante puede descartar tráfico y causar timeout sin producir un ciphertext inválido. KeyUpdate deriva nuevas application traffic secrets dentro del estado de la conexión; no es una única «rotación global» instantánea. RFC 9846, §4.7.3

El cierre normal usa close_notify, que indica que el emisor no enviará más records. Una aplicación que trata EOF o un reset de transporte como final correcto sin conocer la semántica de su protocolo puede aceptar truncamiento. Las alertas de error —por ejemplo bad_certificate, certificate_unknown, decrypt_error, handshake_failure, protocol_version o no_application_protocol— describen una condición del endpoint que las emitió, no una causa física única. TLS 1.3 reduce el uso de alertas warning; salvo close_notify, los errores relevantes terminan la conexión. RFC 9846, §§6 y 6.2

SNI, ALPN y terminación en intermediarios

SNI (server_name) es una indicación del nombre que el cliente espera y permite a un edge escoger un certificado o virtual host. No es un certificado, no demuestra que el servidor elegido sea autorizado y no debe usarse como sustituto de la comparación de identidad definida por RFC 9525. ALPN negocia un protocolo de aplicación; el servidor selecciona un valor de la lista propuesta o aborta si la política exige uno que no está disponible. ALPN evita interpretar bytes con el parser equivocado, pero no concede permisos. RFC 9525, §§6.1–6.3; RFC 6066, §3; RFC 7301, §§3–4

En un proxy que termina TLS hay dos sesiones, no un canal mágico de extremo a extremo. El cliente puede autenticar al edge; el edge puede autenticar al origen; el origen no puede inferir automáticamente el certificado del cliente. Si el edge reenvía un identificador de usuario, éste necesita un contrato de integridad, procedencia y autorización independiente. En passthrough, el origen conserva la autenticación TLS del cliente–origen, pero el edge pierde la capacidad de aplicar controles basados en plaintext. En re-cifrado, cada leg puede negociar versión, SNI, ALPN, trust store y certificados distintos. Un log de handshake en el edge no prueba el estado del origen.

PSK, reanudación y 0-RTT

NewSessionTicket permite derivar un PSK para una conexión posterior. La reanudación no reutiliza las traffic keys de la conexión anterior: el nuevo handshake deriva secretos nuevos, incorpora un binder al transcript y puede combinar PSK con (EC)DHE. La continuidad del ticket tampoco es autenticación de usuario; es una credencial de sesión emitida bajo una política de servidor.

Con 0-RTT el cliente envía early data antes de recibir el Finished del servidor. Reduce latencia, pero el servidor puede recibir el mismo early data más de una vez: anti-replay requiere coordinación temporal, estado compartido y límites de despliegue; TLS no hace replay-safe una operación de negocio. RFC 9846, §§2.3 y 8; RFC 9325, §4.2.10

Una lectura idempotente puede ser candidata a 0-RTT si el protocolo y la arquitectura toleran replays. POST /transfers, cambio de contraseña, alta de dispositivo o cualquier operación con efectos no debe aceptarse como early data sólo porque va cifrada. Controles posibles son esperar al handshake confirmado, idempotency keys verificadas en un almacén compartido, deduplicación atómica y una política explícita del edge. La opción prudente para una transferencia financiera es no usar 0-RTT.

Desliza horizontalmente para consultar todas las columnas.

Modo Identidad/credencial Forward secrecy Early data
Completo con certificado + (EC)DHE Certificado, nombre, política y CertificateVerify. Sí bajo los supuestos de efimeridad y borrado de secretos. No.
PSK + (EC)DHE PSK/ticket y nuevo intercambio. Sí para la contribución nueva, sujeto a compromiso del PSK y del endpoint. No si se espera al handshake.
PSK-only reanudado PSK/ticket; puede no haber certificado nuevo. No frente al compromiso del PSK en el sentido del intercambio efímero. Puede habilitar 0-RTT.
PSK con early data (0-RTT) Variante sobre un flujo PSK/reanudado, antes de completar el handshake. Conserva las propiedades del modo PSK subyacente; early data tiene garantías más débiles. Replay posible; requiere controles de despliegue y aplicación.

Leer evidencia sin fabricar certeza

Una captura puede mostrar ClientHello, ServerHello, SNI, ALPN, versión anunciada, tamaños, tiempos, alertas visibles y cierre. No demuestra qué trust store usó el cliente, qué nombre comparó, si verificó revocación, qué identidad mapeó la aplicación o si el origen aceptó la operación. Un certificado visible prueba presentación, no aceptación.

Un descifrado autorizado requiere material de claves o instrumentación del endpoint. Mostrar plaintext con secretos exportados por el cliente no significa que una captura haya «roto TLS»; demuestra que se obtuvo material desde un endpoint. La evidencia debe conservar origen, versión, filtro, relojes, punto de terminación y relación entre legs.

Para un cierre, distinguir al menos:

  1. alert emitida y su nivel/código;
  2. último mensaje del transcript observado;
  3. si CertificateVerify o Finished fueron aceptados en cada endpoint;
  4. validación de nombre, tiempo, ruta, uso y revocación según logs/configuración;
  5. si el cierre ocurrió en edge, origen o transporte posterior;
  6. si la aplicación recibió un mensaje completo o sólo un prefijo.

Controles positivos, negativos y de regresión

Una comprobación profesional no pregunta sólo «¿conecta?»:

Un resultado negativo sólo vale si el punto podía observar el fallo y la política definía el oráculo. Un handshake exitoso no prueba autorización; un fallo de handshake no identifica por sí solo si la causa fue nombre, reloj, ruta, clave, ALPN, política o red.

Transferencia: revisar una propuesta de diseño

El equipo de Aurora afirma: «El candado demuestra que POST /transfers está autorizado; podemos activar 0-RTT porque el contenido está cifrado; el certificado y CT prueban que el negocio es legítimo; el edge puede pasar la identidad al origen con una cabecera». La revisión correcta separa las afirmaciones:

  1. TLS puede proteger confidencialidad/integridad del leg y autenticar una identidad de servicio bajo una política.
  2. La autorización de POST /transfers exige una sesión/principal y una política de aplicación; no la concede el certificado.
  3. 0-RTT introduce replay; el edge y la aplicación deben impedir duplicar la operación o esperar Finished.
  4. CT mejora la detección de emisión sospechosa para certificados públicos; no prueba legitimidad comercial ni evita toda emisión indebida.
  5. Una cabecera de identidad sólo es confiable si el edge la elimina de entradas no confiables, la vuelve a crear tras autenticar, la protege frente al cliente y existe un contrato verificable de integridad/procedencia entre edge y origen. mTLS edge–origen puede autenticar al edge, no convierte automáticamente la cabecera en una identidad de usuario.

El claim final debe decir qué leg, versión, nombre, trust store, política de revocación, ALPN, modo de reanudación, punto de terminación y operación se observaron. Si falta cualquiera de ellos, se declara fuera de alcance en lugar de convertir un indicador en garantía.

Síntesis

TLS 1.3 construye un argumento encadenado: ClientHello y ServerHello negocian y aportan material efímero; el transcript liga la historia; la validación de ruta, nombre, tiempo, uso y política convierte un certificado presentado en una identidad aceptada; CertificateVerify demuestra posesión de la privada; Finished confirma secretos y transcript; el key schedule deriva secretos separados; la record layer protege records por dirección.

El argumento sigue siendo acotado. TLS no autentica usuarios por defecto, no autoriza acciones, no oculta todos los metadatos, no garantiza disponibilidad ni convierte un proxy en un canal extremo a extremo. PSK, mTLS, CT, pinning, revocación y 0-RTT cambian las propiedades según su política y despliegue; ninguno debe describirse como garantía total.

Comprobación de comprensión

  1. Reconstruye el cambio de protección entre ClientHello, ServerHello y EncryptedExtensions; ¿qué sigue visible y qué queda protegido?
  2. Compara Certificate, CertificateVerify y Finished: ¿qué pregunta responde cada uno?
  3. Reescribe «la cadena es válida, por tanto el sitio es legítimo» incluyendo ruta, nombre, tiempo, uso, revocación y límite de negocio.
  4. ¿Qué cambia en una sesión mTLS y qué autorización adicional sigue siendo necesaria?
  5. ¿Por qué PSK-only y PSK + (EC)DHE no ofrecen la misma propiedad de forward secrecy?
  6. ¿Qué puede observar un atacante de red si application records usan AEAD y padding?
  7. ¿Por qué una alerta certificate_unknown no basta para adjudicar una única causa?

Problema de transferencia

Un edge termina TLS para api.aurora.example, negocia ALPN HTTP/2 y re-cifra hacia tres orígenes. El equipo quiere aceptar POST /transfers en 0-RTT, reenviar X-Client-Cert: valid y considerar suficiente que el certificado tenga CT y no esté expirado. Redacta un dictamen que: (a) separe confidencialidad, integridad, autenticación y autorización por leg; (b) enumere controles positivos, negativos y de regresión para nombre, mTLS, ALPN, revocación y replay; (c) explique qué evidencia del edge no prueba el estado del origen; y (d) indique una decisión conservadora con su incertidumbre residual.

Fuentes principales