Resumen

  • TLS 1.3 protege como una unidad el contenido, un octeto de tipo interno y los ceros finales de relleno. El emisor elige esos ceros y el receptor los elimina antes de entregar el contenido; el relleno no adquiere significado de aplicación.
  • Una captura acredita longitud de ciphertext, dirección y tiempo. No separa contenido, tipo, relleno y sobrecoste AEAD. Por eso un registro mayor no demuestra por sí solo un mensaje mayor.
  • El relleno puede agrupar huellas de tamaño y crear tráfico de cobertura, pero no borra tiempo, número de registros, respuestas, segmentación ni procesamiento. Las conclusiones necesitan medidas del endpoint, política versionada, límites negociados y pruebas de rechazo.

Cuando una medición correcta recibe demasiada autoridad

Los investigadores compararon dos registros de la misma conexión. El mayor apareció junto a una operación delicada. Como la diferencia era estable, se describió como cuerpo de la petición y se atribuyó a la persona conectada.

El endpoint conservaba un dato ausente en la captura: una devolución de llamada añadía ceros hasta el siguiente límite de bloque. En algunos intervalos enviaba además un registro Application Data sin bytes de aplicación. La diferencia consumía ancho de banda y era observable, pero no podía contarse entera como contenido.

El fallo no estaba en el sensor. Consistía en pedir a una evidencia de transporte que decidiera semántica de aplicación.

La frontera dentro de TLSInnerPlaintext

TLSInnerPlaintext contiene primero los bytes reales, después un ContentType no nulo y al final una secuencia de ceros. Todo entra en la operación de protección. El tipo exterior parece Application Data, así que el observador no conoce el tipo interior por la cabecera.

Tras validar y descifrar AEAD, el receptor examina el plaintext desde el final. Salta ceros hasta hallar el primer octeto no nulo, que representa el tipo. Lo anterior es contenido. Si no encuentra ninguno, debe terminar con unexpected_message.

Esa búsqueda fija el límite donde sí existe autoridad para interpretarlo. La aplicación recibe los bytes anteriores al tipo; no recibe el relleno. Que los ceros hayan sido autenticados no los convierte en orden, identidad ni permiso.

Cobertura no significa actividad

Application Data puede tener contenido interior de longitud cero. El emisor puede generar un registro de tamaño plausible durante el silencio y debilitar la relación simple entre tráfico y actividad.

Handshake y Alert no disfrutan de esa licencia. Un mensaje vacío rodeado de relleno sigue siendo inválido. El receptor debe rechazarlo porque el espacio ocupado no puede inventar una transición del protocolo.

Tampoco basta la cobertura para ocultar comportamiento. Una respuesta, una pausa, una ráfaga o un cierre pueden revelar qué registro acompañaba trabajo real. Se altera una señal; no desaparece el conjunto de señales.

Los ceros también gastan el límite

El máximo incluye contenido, tipo y relleno. Si se negocia record_size_limit, el valor recibido limita el TLSInnerPlaintext completo.

Una política que solicita un bloque determinado no controla necesariamente el resultado. El contenido ya ocupa espacio, el límite puede ser menor y la biblioteca puede recortar el relleno o fragmentar. OpenSSL calcula el máximo disponible antes de escribir los ceros.

Así, un mismo mensaje puede convertirse en uno o varios registros y caer en clases distintas. Para explicar la longitud hacen falta el límite, la fragmentación y el valor aplicado, no sólo el nombre de la regla.

Capacidad disponible no es política activa

La especificación TLS 1.3 define cómo codificar y validar el relleno, pero no prescribe una distribución universal. La aplicación puede rellenar sus propios mensajes cuando conoce mejor qué frontera es sensible; TLS sigue siendo responsable de Handshake y Alert cifrados.

OpenSSL no añade relleno por defecto. Permite bloques o una función ejecutada antes de cifrar cada registro escrito, con reglas separables para Application Data y para Handshake/Alert. Una función configurada puede impedir kernel TLS. Son hechos operativos que una evaluación de coste debe conservar.

GnuTLS permite solicitar relleno por envío y consultar si existe ocultación de longitud. Tener la API instalada sólo demuestra posibilidad. No prueba que el proceso la activara ni el número de bytes aplicado en el incidente.

El tiempo atraviesa la frontera

Retirar el relleno puede consumir tiempo relacionado con su longitud. GnuTLS ofrece GNUTLS_SAFE_PADDING_CHECK para reducir esa señal, aceptando una penalización.

Después comienza el trabajo de aplicación: parseo, asignación, almacenamiento y respuesta. Puede variar con el contenido aunque la biblioteca trate el relleno de forma constante.

Por eso TLS no promete una defensa completa contra análisis de tráfico. Ocultar longitudes con rigor exige cooperación de capas superiores, tráfico adicional y a menudo retrasos. “Relleno habilitado” describe una función, no una garantía final.

La capa depende del protocolo compuesto

EAP-TLS 1.3 recomienda relleno de registro para reducir la fuga por tamaño de certificados. ECH redondea su ClientHello interno y advierte que otros mensajes cifrados con campos sensibles pueden necesitar relleno TLS. Cada perfil nombra primero el secreto de longitud que intenta proteger.

HTTP/3 distingue relleno de aplicación, frames reservados y padding de transporte. QUIC usa el handshake TLS, pero no transporta registros TLS normales. No se puede proyectar una configuración de callback TLS sobre paquetes QUIC.

Las suites TLS de sólo integridad ofrecen otra frontera: el relleno puede estar presente y autenticado, pero sin cifrado no oculta el tamaño del plaintext. La confidencialidad depende del sistema completo.

Qué puede declarar el observador

Una captura pasiva demuestra origen y destino, dirección, instante, longitud cifrada, paquetes y retransmisión. No observa directamente el tipo interior, el contenido, el relleno ni el significado.

Puede afirmar: «el endpoint emitió N octetos protegidos en T». El endpoint permite ampliar: «recibió C octetos, ejecutó la política P versión V, añadió Z, quedó en I bajo el límite L y produjo N».

Sin esa unión, la distribución sustenta una hipótesis. No sustenta por sí sola una acción humana, el tamaño de un objeto o una orden.

Evidencia para la revisión posterior

Registrar conexión, dirección, secuencia, versión TLS, protección, tipo interior, contenido previo, relleno solicitado y aplicado, tamaño interior y cifrado, límite, fragmentación, biblioteca, estado de kernel TLS y versión de política.

Medir a la vez ancho de banda, latencia, CPU, clases de tamaño, respuestas y proporción de cobertura. Separar siempre Application Data de Handshake y Alert.

Probar el rechazo de plaintext todo cero, Handshake y Alert vacíos, solicitudes excesivas y registros sobre el límite. Al desactivar la regla, verificar que cesan la función y su distribución característica.

El campo decisivo es el que no ofrece la captura: longitud de contenido antes del relleno. Sin él, la longitud visible es evidencia de red, no autoridad de aplicación.

Fuentes