Résumé

  • TLS 1.3 protège ensemble le contenu, un octet de type interne et une suite finale de zéros. L’émetteur choisit le bourrage ; le récepteur le valide et le retire avant de livrer le contenu. Cette représentation supplémentaire n’ajoute aucun sens applicatif.
  • Une capture établit la longueur du chiffré, la direction et le temps. Elle ne sépare pas directement contenu, type, bourrage et surcoût AEAD. Une trame plus longue ne prouve donc pas un message applicatif plus long.
  • Le bourrage peut réduire la précision des empreintes de taille et créer du trafic de couverture. Il ne supprime ni le rythme, ni le nombre d’enregistrements, ni les réponses, ni les fuites de traitement. Une affirmation solide exige les mesures de l’extrémité et la provenance de la politique.

Le nombre exact qui racontait la mauvaise histoire

L’enquête disposait d’une capture propre. Deux enregistrements sortants appartenaient à la même connexion ; l’un dépassait l’autre de 512 octets. Comme le second coïncidait avec une opération sensible, l’écart fut présenté comme la taille d’une charge utile et comme la preuve d’un geste utilisateur.

Le journal de l’extrémité révélait un autre mécanisme. Une règle ajoutait assez de zéros pour atteindre le bloc suivant. Aux périodes de silence, un composant pouvait aussi produire un enregistrement Application Data dont le contenu interne était vide. Les octets existaient sur le fil et consommaient des ressources, mais ils ne constituaient pas tous une requête.

La faute consistait à donner à la visibilité réseau l’autorité du sens applicatif. Une mesure exacte n’autorise pas une conclusion qui traverse une frontière qu’elle ne voit pas.

Le point où finit le contenu

TLSInnerPlaintext place d’abord le contenu, puis un octet ContentType non nul et enfin une suite arbitraire de zéros. L’ensemble est chiffré et authentifié. L’en-tête extérieur porte un type opaque compatible avec Application Data ; un observateur ne peut pas en déduire le type interne.

Après déchiffrement AEAD réussi, le destinataire parcourt uniquement le texte clair retourné, depuis la fin. Les zéros sont du bourrage. Le premier octet non nul indique le type ; ce qui le précède est le contenu. Si aucun octet non nul n’existe, le destinataire ferme la connexion avec unexpected_message.

Cette opération fixe la limite à l’extrémité. L’application ne reçoit que le contenu débarrassé du bourrage. Des zéros authentifiés ne deviennent ni instruction, ni identité, ni permission.

Le trafic de couverture a ses propres limites

Un enregistrement Application Data peut contenir zéro octet applicatif. TLS permet ainsi de produire une taille plausible quand la présence ou l’absence d’activité est sensible. L’observateur ne peut plus assimiler automatiquement « enregistrement transmis » à « action accomplie ».

Cette faculté ne s’étend pas aux messages Handshake et Alert. Un corps vide entouré de bourrage n’est pas un message de protocole valide. Le récepteur doit le refuser au lieu de laisser la représentation fabriquer un événement d’état.

Le trafic de couverture ne garantit pas l’indistinction. Une réponse, un délai de calcul, une rafale ou une fermeture peuvent encore révéler le travail réel. Le bourrage affaiblit un signal de longueur ; il ne supprime pas l’écosystème des signaux.

La limite négociée inclut les zéros

Le bourrage ne crée aucun espace gratuit. Le contenu, le type et les zéros doivent tenir dans la taille maximale de TLSInnerPlaintext. Si record_size_limit abaisse la limite, la valeur reçue s’applique à l’ensemble de cette structure.

Une politique qui demande 1 024 octets de bourrage peut donc n’en obtenir qu’une partie. Le contenu courant occupe déjà une place ; l’implémentation peut plafonner le supplément ou fragmenter autrement. Le code OpenSSL borne le résultat afin de ne pas dépasser le maximum autorisé.

Deux messages identiques peuvent dès lors devenir un seul enregistrement, plusieurs fragments ou des tailles différentes selon la limite et la politique. Sans ces états, la longueur finale ne permet pas de reconstruire le chemin.

Le standard fournit un mécanisme, pas une politique universelle

La spécification TLS 1.3 actuelle ne choisit ni taille de bloc, ni distribution aléatoire, ni cadence de couverture. Elle laisse cette décision à l’application et à l’émetteur. Pour les données applicatives, la couche supérieure connaît parfois mieux les frontières sensibles ; pour Handshake et Alert chiffrés, le bourrage reste une tâche TLS.

OpenSSL n’ajoute rien par défaut. Il permet de configurer un bloc ou un rappel exécuté avant le chiffrement de chaque enregistrement TLS 1.3. Les données applicatives peuvent utiliser une règle différente de celle des Handshake et Alert. Un rappel actif peut en outre rendre kernel TLS indisponible.

GnuTLS offre un paramètre de bourrage à l’envoi et une interrogation sur le masquage de longueur. Ces interfaces prouvent une capacité, pas son activation. Seul l’état du processus montre quelle règle a réellement produit la trame.

Le temps reste visible

Le retrait du bourrage peut lui-même avoir une durée dépendante de sa longueur. GnuTLS propose GNUTLS_SAFE_PADDING_CHECK pour réduire ce signal, moyennant un coût de performance.

La mesure constante s’arrête toutefois à la frontière de la bibliothèque. L’application peut ensuite analyser le vrai contenu, allouer de la mémoire, consulter une base ou produire une réponse avec une durée dépendante des données. Un traitement TLS régulier ne rend pas l’application régulière.

Le texte TLS reconnaît cette difficulté. Des garanties robustes exigeraient une coopération de l’application et du protocole supérieur, davantage de volume et souvent davantage de délai. La présence de bourrage ne vaut donc jamais déclaration générale de confidentialité contre l’analyse de trafic.

Chaque composition choisit sa couche

EAP-TLS 1.3 recommande le bourrage d’enregistrements pour réduire la fuite liée à la taille des certificats. ECH bourre son ClientHello interne selon une règle propre et signale que d’autres messages de négociation chiffrés contenant des champs sensibles peuvent aussi demander un bourrage TLS. L’objectif précède le mécanisme.

HTTP/3 distingue le bourrage applicatif, les trames réservées et le bourrage du transport, car leur granularité et leur comportement en cas de perte diffèrent. QUIC consomme des messages de négociation TLS mais ne transporte pas des enregistrements TLS ordinaires. Une option de rappel TLS ne prouve donc rien sur le bourrage des paquets QUIC.

Les suites TLS 1.3 limitées à l’intégrité fournissent un contre-exemple utile : elles peuvent inclure le bourrage, mais sans chiffrement celui-ci ne dissimule pas la taille du texte clair. L’effet dépend de la confidentialité et de la politique, non de la présence de zéros.

Ce que la capture peut affirmer

Une capture passive établit les extrémités, la direction, l’instant, la longueur chiffrée, la mise en paquets et les retransmissions. Elle n’observe pas directement le type interne, la longueur de contenu, le nombre de zéros ou le sens de la requête.

La formulation sûre est : « l’extrémité a émis un enregistrement protégé de N octets à T ». La trace du processus peut compléter : « C octets de contenu ont reçu Z octets de bourrage selon la politique P version V, sous la limite L, pour produire I octets internes et N octets chiffrés ».

Sans cette jonction, une distribution permet une hypothèse, pas l’attribution d’une action humaine ou d’une taille d’objet.

Un registre exploitable après l’incident

Conserver la connexion, la direction, la séquence, la version TLS, le mode de protection, le type interne, la longueur avant bourrage, la demande et le résultat du bourrage, les longueurs interne et chiffrée, la limite négociée, la fragmentation, la version de bibliothèque, l’état kernel TLS et la révision de politique.

Mesurer avec eux le coût en bande passante, latence et CPU. Séparer les distributions de contenu, de bourrage et de chiffré ; suivre aussi les réponses et le ratio de couverture.

Tester les refus : texte interne entièrement nul, Handshake ou Alert vide, demande excessive et dépassement de record_size_limit. Après désactivation, vérifier que le rappel et sa signature de tailles ont réellement disparu.

La donnée décisive est celle que le réseau ne voit pas : la longueur applicative avant bourrage. Sans elle, la longueur visible reste une preuve de transport, pas une autorité applicative.

Sources