5. Seguridad de la Información — Tema 5: Seguridad en Redes TCP/IP.

1. Introducción y motivación.

La expansión de la World Wide Web durante los años 90 y su adopción para realizar transacciones electrónicas planteó nuevos riesgos de seguridad: en el lado del cliente, en el lado del servidor, y sobre la propia información intercambiada entre ambos. Las primeras versiones de HTTP no contemplaban ningún mecanismo de protección, por lo que la información viajaba en claro y sin autenticar.

Para abordar el problema, el IETF formó a mediados de los 90 el grupo de trabajo Web Transaction Security (WTS), con el objetivo de desarrollar los requisitos y especificaciones de los servicios de seguridad necesarios para las transacciones web.

1.1. Amenazas y consecuencias.

Las amenazas que afectan a las transacciones web pueden clasificarse según el servicio de seguridad comprometido:

Servicio Amenaza típica Consecuencia
Integridad Modificación de datos de usuario, troyano en el navegador, modificación en tránsito Pérdida de información, afectación del dispositivo, otros ataques
Confidencialidad Escuchas en el canal (eavesdropping), robo de información, robo de configuración Pérdida de información y privacidad
Disponibilidad Interrupción de procesos en cliente o servidor (DoS) Interrupción del servicio, inaccesibilidad
Autenticación Suplantación de identidad, falsificación de datos Confianza en datos falsos o entidades ilegítimas
ImportantImportante.

La correspondencia entre tipo de ataque y servicio de seguridad necesario es directa: los ataques de eavesdropping exigen confidencialidad, los de tampering exigen integridad y los de forgery exigen autenticación. Toda la arquitectura de SSL/TLS se construye en torno a esta tríada.

1.2. Dos enfoques iniciales: SHTTP frente a SSL.

Frente al problema de la seguridad web, surgieron dos aproximaciones contemporáneas pero distintas:

  • SHTTP (Secure HyperText Transfer Protocol): Solución del grupo WTS del IETF, situada en la capa de aplicación. Quedó especificada en los RFC 2084, 2659 y 2660 (categoría experimental).
  • SSL (Secure Sockets Layer): Solución de Netscape, situada como una subcapa entre aplicación y transporte. Aprovecha que TCP es orientado a conexión y fiable, y proporciona seguridad de forma transparente al protocolo de aplicación.

El enfoque de Netscape se impuso: SSL acabó sustituyendo por completo a SHTTP como mecanismo estándar para proteger las comunicaciones en Internet.

TipModelo mental.

SSL/TLS no es ni un protocolo de aplicación ni un protocolo de transporte: es una subcapa intermedia que se “intercala” sobre TCP y por debajo del protocolo de aplicación, lo que permite proteger cualquier aplicación basada en TCP sin modificarla.

1.3. Evolución histórica de SSL/TLS.

Año Organización Versión
Mediados de 1994 Netscape SSL v1.0 (nunca pública)
Finales de 1994 Netscape SSL v2.0
1995 Netscape SSL v2.0 (actualizada)
1996 Netscape SSL v3.0 (obsoleta)
1999 IETF TLS v1.0 — SSL v3.1 — RFC 2246
2006 IETF TLS v1.1 — SSL v3.2 — RFC 4346
2008 IETF TLS v1.2 — SSL v3.3 — RFC 5246
2018 IETF TLS v1.3 — SSL v3.4 — RFC 8446
NoteRefuerzo conceptual: relación SSL ↔︎ TLS.

TLS es la estandarización por parte del IETF del protocolo SSL de Netscape. Como recoge el propio RFC 2246, las diferencias entre TLS 1.0 y SSL 3.0 no son drásticas, pero sí lo suficiente como para impedir interoperabilidad entre ambos. A efectos didácticos, SSL y TLS son equivalentes en su arquitectura general, y entender SSL es la base para entender TLS.

2. Servicios de seguridad y arquitectura de SSL.

2.1. Servicios proporcionados.

El protocolo SSL es un protocolo cliente/servidor que proporciona prevención contra:

  • Ataques de escucha (eavesdropping): combatidos mediante confidencialidad.
  • Ataques de manipulación (tampering): combatidos mediante integridad.
  • Ataques de falsificación (forgery): combatidos mediante autenticación.

Concretamente, SSL garantiza:

  • Autenticación de las entidades origen y destino, opcionalmente mediante certificados X.509 y MAC.
  • Confidencialidad de la conexión.
  • Integridad de la conexión.
ImportantImportante.

A pesar de emplear criptografía de clave pública, SSL no proporciona el servicio de no repudio, ni de origen ni de entrega. Si la aplicación requiere no repudio (p. ej. firma electrónica de documentos), debe gestionarse a nivel de aplicación.

2.2. Independencia del protocolo de aplicación.

Una ventaja fundamental de SSL es que es independiente del protocolo de aplicación: cualquier protocolo basado en TCP puede beneficiarse de los servicios de seguridad. Esto da lugar a múltiples variantes “sobre SSL/TLS”:

Protocolo Descripción Puerto
https HTTP sobre SSL/TLS 443
ldaps LDAP sobre SSL/TLS 636
ftps-data FTP Data sobre SSL/TLS 989
ftps FTP Control sobre SSL/TLS 990
telnets Telnet sobre SSL/TLS 992
imaps IMAP4 sobre SSL/TLS 993
pop3s POP3 sobre SSL/TLS 995

2.3. Criptografía híbrida.

SSL combina dos familias de algoritmos:

  • Criptografía de clave pública: Para la autenticación de las entidades y el establecimiento de la clave de sesión. SSL v3.0 admitía RSA, Diffie-Hellman y Fortezza KEA (este último sólo hasta SSL v3.0).
  • Criptografía simétrica: Para la autenticación de los datos (mediante MAC) y el cifrado del contenido aplicativo.
WarningIdea clave.

La criptografía híbrida permite combinar las ventajas de ambas familias: la clave pública resuelve el problema de establecer una clave secreta entre desconocidos, y la criptografía simétrica proporciona la velocidad necesaria para cifrar volúmenes grandes de datos.

2.4. Sesión y conexión SSL.

SSL distingue dos conceptos relacionados pero diferentes:

  • Sesión SSL: Asociación entre cliente y servidor en la que se negocian los parámetros de seguridad (versión, cipher suite, claves maestras, etc.) que se aplicarán en las conexiones asociadas a esa sesión.
  • Conexión SSL: Transmisión efectiva de datos entre cliente y servidor, protegida criptográficamente según lo negociado en la sesión.

Una misma sesión puede dar lugar a múltiples conexiones, lo que evita renegociar parámetros costosos cada vez que se abre un canal nuevo.

NoteRefuerzo conceptual: las dos fases de SSL.
  • Fase I — Sesión SSL: Negociación de parámetros de seguridad mediante el handshake.
  • Fase II — Conexión SSL: Comunicación segura (cifrada y autenticada) sobre los parámetros negociados.

2.5. Arquitectura en dos subcapas.

Para cubrir su doble misión (establecer la conexión segura y transmitir datos sobre ella), SSL se organiza en dos subcapas y varios subprotocolos:

   +---------------------------------------------------+
   |  Subcapa alta (sesión y control)                  |
   |   ┌──────────┐ ┌──────────┐ ┌────────┐ ┌────────┐ |
   |   | Handshake| | ChangeCS | | Alert  | | AppData| |
   |   |   (22)   | |   (20)   | |  (21)  | |  (23)  | |
   |   └──────────┘ └──────────┘ └────────┘ └────────┘ |
   +---------------------------------------------------+
   |  Subcapa baja                                     |
   |          SSL Record Protocol                      |
   +---------------------------------------------------+
                          |
                         TCP
  • Subcapa alta: Contiene los subprotocolos que gestionan la sesión y el control:
    • (22) SSL Handshake Protocol: Permite a las partes autenticarse mutuamente, negociar un cipher suite y, opcionalmente, un método de compresión.
    • (20) SSL Change Cipher Spec Protocol: Activa el cipher suite negociado.
    • (21) SSL Alert Protocol: Intercambia mensajes de alerta sobre incidencias.
    • (23) SSL Application Data Protocol: Es el propio protocolo de aplicación (p. ej. HTTP) cuyos datos alimentan al SSL Record Protocol.
  • Subcapa baja: Contiene el SSL Record Protocol, que fragmenta los datos procedentes de la subcapa alta y los procesa de forma individual.

3. SSL Record Protocol.

El SSL Record Protocol es la pieza de la subcapa baja responsable de transformar los datos de la subcapa alta en unidades transmisibles sobre TCP, denominadas SSL records.

3.1. Formato del SSL record.

Cada SSL record tiene la siguiente estructura de cabecera:

Tipo (1 byte) Versión (2 bytes) Longitud (2 bytes) Fragmento (≥ 0 bytes)
  • Tipo: Indica el protocolo de la subcapa alta del que procede el fragmento. Valores principales:
    • 20 → SSL Change Cipher Spec Protocol
    • 21 → SSL Alert Protocol
    • 22 → SSL Handshake Protocol
    • 23 → SSL Application Data Protocol
  • Versión: Dos bytes que codifican versión mayor y menor (en SSLv3, valores 3 y 0 respectivamente).
  • Longitud: Tamaño del fragmento en bytes.
  • Fragmento: Carga útil ya procesada (comprimida, autenticada y cifrada).

3.2. Procesamiento del fragmento.

El Record Protocol aplica una secuencia ordenada de transformaciones sobre los datos:

[datos de subcapa alta]
        |
        v
   1. Fragmentar  ──→ bloques de longitud ≤ 2^14 bytes (16 384)
        |
   2. Comprimir   ──→ opcional
        |
   3. Añadir MAC  ──→ usa client_write_MAC_secret / server_write_MAC_secret
        |
   4. Cifrar      ──→ usa client_write_key / server_write_key
        |               y client_write_IV / server_write_IV
   5. Añadir cabecera SSL record
        |
        v
   [segmento TCP]

En el destino, el proceso se ejecuta a la inversa: los datos recibidos son descifrados, verificados (MAC), descomprimidos y reensamblados antes de entregarlos a la capa de aplicación.

NoteRefuerzo conceptual: dónde se usa cada clave.
  • El MAC secret garantiza la integridad y la autenticidad del fragmento.
  • La write key y el IV se usan para el cifrado simétrico.
  • Hay claves separadas para cliente y servidor, lo que evita ataques de reflexión y simplifica el análisis del flujo.

4. SSL Handshake Protocol.

El SSL Handshake Protocol es la parte más compleja de SSL y se ejecuta antes de transmitir cualquier dato de aplicación. Permite a cliente y servidor:

  • Autenticarse mutuamente.
  • Negociar un algoritmo de cifrado y una función MAC (el cipher suite).
  • Negociar las claves que se usarán para proteger los datos en el SSL Record Protocol.

4.1. Formato de los mensajes de handshake.

Los mensajes de handshake viajan como fragmento de un SSL record con Tipo = 22. La estructura interna de cada mensaje es:

Tipo (1 byte) Longitud (3 bytes) Contenido (≥ 0 bytes)
  • Tipo: Identifica uno de los diez posibles tipos de mensaje (ver tabla en §4.3).
  • Longitud: Longitud del mensaje en bytes.
  • Contenido: Parámetros específicos del mensaje.

4.2. Las cuatro fases del handshake.

El intercambio completo de mensajes se organiza en cuatro fases:

  • Fase 1 — Negociación de capacidades. Cliente y servidor intercambian ClientHello y ServerHello para acordar versión del protocolo, ID de sesión, cipher suite, número aleatorio (random) y, opcionalmente, método de compresión.
  • Fase 2 — Autenticación del servidor y envío de parámetros. El servidor puede enviar su certificado (opcional), los parámetros necesarios para la gestión de la clave secreta (ServerKeyExchange) y, si lo desea, solicitar un certificado al cliente (CertificateRequest). Termina con ServerHelloDone.
  • Fase 3 — Autenticación del cliente y aportación de la clave. Si se le ha solicitado, el cliente envía su certificado. A continuación envía ClientKeyExchange con los parámetros de seguridad necesarios para derivar la clave de sesión. Si ha enviado certificado, añade CertificateVerify firmado para verificación de origen.
  • Fase 4 — Activación y cierre. Ambas partes envían ChangeCipherSpec y Finished, activando el cipher suite negociado y comprobando que todo el handshake se ha realizado correctamente.

4.3. Tabla de mensajes del Handshake.

Mensaje Tipo Contenido principal
Hello_request 0 Vacío. Lo envía el servidor para solicitar renegociación.
Client_hello 1 Versión, client_random, ID de sesión, cipher suites soportados, métodos de compresión.
Server_hello 2 Versión, server_random, ID de sesión, cipher suite elegido, método de compresión.
Certificate 11 Cadena de certificados X.509.
Server_key_exchange 12 Parámetros para computar la clave de sesión (p. ej. parámetros DH) y firma del hash de client_random + server_random + parámetros.
Certificate_request 13 Tipos de certificado y autoridades aceptadas.
Server_hello_done 14 Vacío. Indica fin de Fase 2.
Client_key_exchange 16 pre_master_secret cifrado con RSA, o parámetros DH/Fortezza para computar el master_key en ambas partes.
Certificate_verify 15 Firma sobre hash(master_key + hash(todos los mensajes intercambiados hasta el momento)). Sólo si se envió certificado de cliente.
Finished 20 Cifrado del hash(master_key + hash(hash(todos los mensajes hasta el momento) + ID_sender)).

4.4. Ejemplo: formato de ClientHello y ClientKeyExchange.

SSL record                 |  Mensaje de Handshake
                           |
Tipo Versión Long. Frag.   |  Tipo Long. Versión  Contenido
 22    3,0    Y    ...     |   1    Z    3,0      client_random,
                           |                       ID session,
                           |                       cipher suite1,
                           |                       cipher suite2, ...
SSL record                 |  Mensaje de Handshake
                           |
Tipo Versión Long. Frag.   |  Tipo Long.  Contenido
 22    3,0    Y    ...     |  16    Z     pre-shared master key
TipEsquema rápido del handshake (SSL/TLS 1.2). 
Cliente                                  Servidor
   │                                         │
   │──── ClientHello ───────────────────────▶│
   │                                         │
   │◀──── ServerHello                        │
   │      [Certificate]                      │
   │      [ServerKeyExchange]                │
   │      [CertificateRequest]               │
   │       ServerHelloDone ──────────────────│
   │                                         │
   │──── [Certificate]                       │
   │      ClientKeyExchange                  │
   │     [CertificateVerify]                 │
   │      ChangeCipherSpec                   │
   │      Finished ─────────────────────────▶│
   │                                         │
   │◀──── ChangeCipherSpec                   │
   │       Finished                          │
   │                                         │
   │═══════ datos de aplicación ════════════▶│

Los corchetes [ ] indican mensajes opcionales.

5. Establecimiento de la clave de sesión.

Una vez completada la negociación inicial, cliente y servidor deben derivar el material criptográfico necesario para proteger la conexión. Concretamente, hay que obtener:

  1. La clave de sesión (para cifrado simétrico de los datos).
  2. Una clave para el MAC (para integridad y autenticidad).
  3. Un IV (vector de inicialización) para el modo de operación del cifrado en bloque.

5.1. Parámetros que intervienen en la derivación.

El material criptográfico se calcula a partir de:

  • Una semilla (pre_master_secret, también llamada pre-shared master key).
  • Dos valores aleatorios (nonces): client_random y server_random.
  • Una función pseudoaleatoria (PRF — pseudorandom function) que combina los anteriores.

El flujo de derivación, simplificado, es:

   pre_master_secret    client_random   server_random
            │                │                │
            └────────────────┴────────────────┘
                             │
                             ▼
                       PRF (función
                      pseudoaleatoria)
                             │
                             ▼
                        master_key
                             │
                             ▼
                          PRF + más
                          aleatoriedad
                             │
                             ▼
                       key_block →  [ client_write_MAC_secret,
                                      server_write_MAC_secret,
                                      client_write_key,
                                      server_write_key,
                                      client_write_IV,
                                      server_write_IV ]
ImportantImportante.

La PRF de SSL es distinta a la de TLS. SSL usa una combinación de MD5 y SHA-1; TLS 1.0 y 1.1 también, pero TLS 1.2 y 1.3 emplean SHA-256. Es uno de los puntos clave en los que SSL 3.0 y TLS no son interoperables.

5.2. Intercambio de claves con RSA.

El esquema más sencillo de intercambio de claves usa RSA y se desarrolla en tres pasos:

  • Paso 1 — ClientHello. El cliente genera client_random y propone cipher suites. Envía toda la información al servidor.
ClientHello = ( { TLS_RSA_WITH_AES_256_CBC_SHA, ... }, client_random, ... )

  • Paso 2 — ServerHello y certificado. El servidor genera server_random, elige el cipher suite y entrega su certificado X.509 que contiene su clave pública RSA.

  • Paso 3 — ClientKeyExchange. El cliente genera la semilla pre_master_secret, la cifra con la clave pública RSA del servidor y la envía:

ClientKeyExchange = E_pub_server( pre_master_secret )

A partir de ahí, cliente y servidor disponen de client_random, server_random y pre_master_secret, lo que les permite derivar la master_key y, de ella, las claves de sesión.

5.3. Intercambio de claves con Diffie-Hellman.

Antes de introducir DHE, conviene recordar el esquema básico de Diffie-Hellman:

Valores públicos: q (primo grande), α (raíz primitiva de q)

   Alice                                     Bob
   ─────                                     ───
   Xa < q  (clave privada)                   Xb < q  (clave privada)
   Ya = α^Xa mod q  (clave pública)          Yb = α^Xb mod q  (clave pública)
                  intercambian Ya, Yb
   KAB = (Yb)^Xa mod q                       KAB = (Ya)^Xb mod q

             KAB = α^(Xa·Xb) mod q = α^(Xb·Xa) mod q

Ambos llegan a la misma clave compartida sin haberla transmitido en ningún momento.

5.4. DHE — Diffie-Hellman efímero y Perfect Forward Secrecy.

Tanto SSL como TLS usan DHE (Diffie-Hellman Efímero) como mejora del esquema anterior:

  • Cliente y servidor generan valores secretos nuevos en cada negociación, en lugar de reutilizar valores estáticos.
  • Esta renegociación constante proporciona Perfect Forward Secrecy (PFS) en la creación del secreto compartido.
  • PFS evita el riesgo de MitM (Man-in-the-Middle) retrospectivo.
WarningIdea clave.

Sin PFS, si la clave privada RSA del servidor se filtra (o un MitM compromete la negociación), un atacante puede derivar todas las claves de sesión pasadas entre las entidades legítimas, descifrando comunicaciones antiguas. Con PFS, comprometer una clave privada de largo plazo no compromete las sesiones anteriores.

5.5. DHE-RSA: combinando autenticación e intercambio efímero.

El esquema más típico combina autenticación con RSA e intercambio de clave con DHE:

Cliente                                                        Servidor
   │── ClientHello (TLS_DHE_RSA_WITH_AES_256_CBC_SHA, ──────▶│
   │   client_random)                                          │
   │                                                           │
   │                                                           │  1. Genera server_random
   │                                                           │  2. Genera G, N (G raíz primitiva, N primo)
   │                                                           │  3. Genera privada Xb < N
   │                                                           │  4. Calcula Yb = G^Xb mod N
   │                                                           │
   │◀── ServerHello (G, N, Yb,                                 │
   │     RSAsign(G, N, Yb, server_random) )                    │
   │    [Certificate]                                          │
   │    ServerHelloDone                                        │
   │                                                           │
   │  1. Verifica certificado, extrae Kpub_serv                │
   │  2. Verifica firma RSAsign sobre (G, N, Yb, server_random)│
   │  3. Genera privada Xa < N                                 │
   │  4. Calcula Ya = G^Xa mod N                               │
   │                                                           │
   │── ClientKeyExchange (Ya = G^Xa mod N) ────────────────▶│
   │                                                           │
   │  5. pre_master_secret = G^(Xa·Xb) mod N                   │
   │                                          5. pre_master_secret = G^(Xa·Xb) mod N
NoteRefuerzo conceptual: por qué este esquema cubre todo.
  • RSA se usa solo para firmar, garantizando que los parámetros DH provienen efectivamente del servidor (autenticación).
  • DHE se usa para generar la semilla compartida (pre_master_secret) de forma efímera (confidencialidad con PFS).
  • A partir de la semilla y los randoms, la PRF deriva el resto de material criptográfico.

6. Subprotocolos auxiliares.

6.1. SSL Change Cipher Spec Protocol.

Es un protocolo extremadamente simple. Consta de un único mensaje de un solo byte con valor 1, cuya función es activar el cipher suite negociado en el handshake. A partir de ese momento, todos los SSL records subsiguientes se procesan con los nuevos algoritmos y claves.

SSL record
 Tipo  Versión  Longitud   Fragmento
  20    3,0       1            1           ← un único byte

6.2. SSL Alert Protocol.

Se usa para comunicar al otro extremo incidencias relacionadas con SSL. Cada mensaje consta de dos bytes y se comprime (opcional) y cifra según lo establecido en la sesión.

SSL record
 Tipo  Versión  Longitud   Fragmento (2 bytes)
  21    3,0       2        ┌──────────┬─────────────┐
                           │  Nivel   │ Descripción │
                           │ (1 / 2)  │   (1 byte)  │
                           └──────────┴─────────────┘
  • Primer byte — Nivel de severidad:
    • 1 → warning.
    • 2 → fatal.
  • Segundo byte — Código de alerta específico. Ejemplos: unexpected_message, bad_record_mac, decompression_failure, illegal_parameter, etc.
ImportantImportante.

Si el nivel es fatal, SSL termina la conexión de forma inmediata. Otras conexiones de la misma sesión pueden continuar abiertas, pero no se permiten nuevas conexiones dentro de esa sesión.

6.3. SSL Record Protocol.

Ya descrito en §3. Es el responsable de fragmentar, comprimir, autenticar (MAC), cifrar y añadir cabecera a los datos procedentes de la subcapa alta antes de entregarlos a TCP.

7. TLS 1.2 y TLS 1.3.

TLS hereda toda la arquitectura SSL pero introduce mejoras significativas en seguridad y rendimiento. Las dos versiones modernas relevantes son TLS 1.2 (2008, RFC 5246) y TLS 1.3 (2018, RFC 8446).

7.1. TLS 1.2.

Los cambios respecto a SSL/TLS anteriores son sustanciales:

  • Cálculo del master key: La PRF se basa en SHA-256, en lugar de la combinación MD5 + SHA-1 de TLS 1.0/1.1. Concretamente:
master_key (48 bytes) = PRF-SHA-256( pre_master_secret,
                                     "master_key",
                                     client_random + server_random )

key_block             = PRF( master_key,
                             "key_expansion",
                             client_random + server_random )

del que se derivan:

  • client_write_MAC_secret, server_write_MAC_secret

  • client_write_key, server_write_key

  • client_write_IV, server_write_IV

  • Extensiones en ClientHello/ServerHello: Permite añadir información sobre certificados, parámetros de seguridad, autorizaciones, tipos de certificados, etc.

  • Actualización del cipher suite: Se eliminan DES e IDEA, se añade AES y se introduce criptografía de clave pública basada en curvas elípticas con ECDHE para la negociación de claves.

  • AEAD (Authenticated Encryption with Associated Data): Se introducen modos que combinan cifrado y autenticación en una sola operación:

    • AES-CBC-MAC / AES-CCM.
    • AES-GCM (Galois Counter Mode), que funciona de forma similar al modo CTR pero usa Carter-Wegman MAC en un campo de Galois; es rápido y eficiente.

7.2. TLS 1.3.

TLS 1.3 introduce cambios todavía más profundos, orientados a rendimiento y seguridad:

  • Un único RTT (Round-Trip Time) en el handshake. Frente a los 2 RTT de versiones anteriores, TLS 1.3 reduce el coste de establecer la conexión.
  • 0-RTT en reconexión. Si cliente y servidor ya se conocen, pueden reutilizar credenciales (PSK — pre-shared key) y empezar a enviar datos junto con el primer mensaje.
  • Prevalece Perfect Forward Secrecy. Solo se permiten cipher suites del tipo DHE-RSA / ECDHE.
  • Reducción de modos de operación. Solo se admiten CBC y AEAD (GCM y CCM). Se eliminan los algoritmos débiles o cuestionables: DES, RC4, MD5, SHA-1, etc.
  • No usa compresión (la compresión a nivel TLS había abierto la puerta a ataques como CRIME).
  • Cifrado de la práctica totalidad del handshake, incluyendo certificados, lo que reduce el fingerprinting del cliente y del servidor.
TipEsquema rápido del handshake TLS 1.3 (1-RTT). 
Cliente                                  Servidor
   │                                         │
   │── ClientHello                           │
   │   + ClientKeyShare ────────────────────▶│
   │                                         │
   │◀── ServerHello                          │
   │    + ServerKeyShare                     │
   │    {EncryptedExtensions}                │
   │    {Certificate}                        │
   │    {CertificateVerify}                  │
   │    {Finished} ──────────────────────────│
   │                                         │
   │── {Finished} ──────────────────────────▶│
   │                                         │
   │═══════ datos de aplicación ════════════▶│

Las llaves { } indican mensajes cifrados con las claves derivadas tras el intercambio de KeyShare. El handshake completo se realiza en un solo RTT.

7.3. Comparativa TLS 1.2 vs TLS 1.3.

Aspecto TLS 1.2 TLS 1.3
RTT del handshake 2 RTT 1 RTT (0-RTT en reconexión)
Cipher suites soportados Amplio catálogo, muchos legados Catálogo reducido, solo AEAD
PFS Opcional (DHE/ECDHE recomendado) Obligatorio
Algoritmos eliminados DES, IDEA Además: RC4, MD5, SHA-1, modos no-AEAD
Compresión TLS Opcional (deshabilitada en práctica) Eliminada
Cifrado del handshake Parcial Casi completo (incluidos certificados)
WarningIdea clave.

TLS 1.3 representa una simplificación radical del protocolo: menos opciones, menos algoritmos, menos rondas. Esta reducción no es casual; cada elemento eliminado había sido fuente de vulnerabilidades reales (BEAST, CRIME, POODLE, FREAK, Logjam, etc.) en versiones anteriores.

8. DTLS — Datagram Transport Layer Security.

8.1. Motivación.

SSL/TLS está diseñado sobre TCP, que es orientado a la conexión y fiable. Sin embargo, hay aplicaciones que se ejecutan sobre UDP (VoIP, vídeo en tiempo real, IoT, DNS sobre UDP, etc.) y que también requieren seguridad. Para cubrir este caso se definió DTLS (Datagram Transport Layer Security) en el RFC 6347 (creado en 2006, última versión de enero de 2012).

DTLS está adquiriendo un papel relevante en escenarios de comunicación en tiempo real o entornos restringidos como IoT (RFC 7925 — TLS/DTLS Profiles for the Internet of Things).

8.2. Adaptaciones respecto a TLS.

La estructura general es similar a la de TLS, pero la transmisión se realiza sobre UDP, no fiable (puede haber pérdidas o entrega desordenada de datagramas). Para compensar esto, DTLS añade:

  • Mecanismos de control de flujo de la información a nivel del propio protocolo.
  • Un número de secuencia explícito en cada DTLS record, en lugar del implícito de TLS.
  • Mecanismos de retransmisión y fragmentación propios del handshake para tolerar pérdidas.
   +-----------------+
   |   Aplicación    |
   +-----------------+
   |  DTLS Record    |
   +-----------------+
   |  UDP   |  TCP   |   ← DTLS sobre UDP; TLS sobre TCP
   +--------+--------+
   |     Internet    |
   +-----------------+
   |     Enlace      |
   +-----------------+
   |     Física      |
   +-----------------+
TipCuándo usarlo.

DTLS es la opción adecuada cuando la aplicación no puede o no quiere usar TCP: comunicación en tiempo real con tolerancia a pérdidas (voz, vídeo), entornos con dispositivos limitados (IoT, sensores) o protocolos diseñados sobre UDP (DTLS-SRTP, CoAP sobre DTLS, etc.).

9. Síntesis y modelo mental.

TipModelo mental.

SSL/TLS es una subcapa entre aplicación y transporte que cumple tres funciones, en orden:

  1. Acordar quién es quién y con qué algoritmos se va a hablar (handshake, certificados, cipher suite).
  2. Acordar una clave compartida que ninguna escucha pueda recuperar (intercambio de claves, idealmente con PFS vía DHE/ECDHE).
  3. Proteger cada paquete de datos con esa clave (Record Protocol: fragmentar, comprimir, autenticar, cifrar).

El resto de subprotocolos —Change Cipher Spec y Alert— son simples mecanismos de control: uno para “pasar de modo claro a modo cifrado” y otro para “avisar de errores”.

NoteRefuerzo conceptual: línea de tiempo conceptual.
  • SSL 2.0 / 3.0 (1994-1996) — Solución pragmática de Netscape; SSL 3.0 ya está obsoleta.
  • TLS 1.0 / 1.1 (1999-2006) — Estandarización por IETF; vulnerabilidades acumuladas en CBC y hashes.
  • TLS 1.2 (2008) — SHA-256, AES, ECDHE, AEAD; el “estándar de trabajo” durante una década.
  • TLS 1.3 (2018) — Simplificación, 1-RTT, PFS obligatorio, eliminación de criptografía débil.
  • DTLS — Misma arquitectura adaptada a UDP, con retransmisión y secuencia explícita.