Résumé

  • La fermeture du transport termine un flux sans prouver que tous les records TLS voulus par le pair sont arrivés. close_notify fournit une déclaration protégée et directionnelle.
  • TLS 1.3 a dissocié les deux sens : l’alerte ferme l’écriture de son émetteur, tandis que longueur, chunk terminal ou END_STREAM restent les preuves de complétude applicative.

Un préfixe authentique peut rester incomplet

Un téléchargement s’arrête. Tous les records observés passent leur contrôle d’intégrité et la socket renvoie EOF. On sait que le préfixe reçu est authentique et que le transport ne livre plus rien. On ignore encore si le pair avait fini de parler.

Le protocole supérieur peut parfois trancher. Une réponse qui promet 10 000 octets mais s’arrête à 9 996 révèle son manque. Un corps chunked sans chunk final de taille zéro fait de même. Si la fermeture elle-même sert de délimiteur, aucun de ces témoins n’existe : la fin normale et le suffixe disparu ont la même silhouette.

TLS 1.0 formula ce risque comme une attaque par troncature. Client et serveur devaient partager la connaissance de la fin. L’alerte close_notify, transportée dans TLS, annonçait que son émetteur n’enverrait plus de messages sur cette connexion ; tout record reçu après elle devait être ignoré.

La promesse restait étroite. Elle ne certifiait ni document, ni opération, ni consommation des octets. Elle donnait à TLS l’autorité sur sa propre frontière : la suite protégée de cet émetteur est terminée.

La première version punissait aussi la reprise

TLS 1.0 rendait la session non reprenable lorsqu’une connexion finissait sans échange correct de close_notify. Une fermeture non prouvée faisait donc perdre l’avantage cryptographique d’une connexion ultérieure.

La pratique n’a pas conservé cette sanction. TLS 1.2 indique que TLS 1.1 l’avait supprimée afin de rejoindre les implémentations largement déployées. L’obligation d’envoyer l’alerte avant une fermeture normale du sens d’écriture subsistait, mais l’absence de l’échange n’annulait plus automatiquement la session.

Cette évolution sépara la sémantique de la politique. Il fallait toujours distinguer une fin protégée d’une disparition du transport ; il n’était pas nécessaire de faire de toute irrégularité une décision définitive sur la reprise.

Une symétrie de fermeture pouvait tronquer le retour

Jusqu’à TLS 1.2, le pair recevant close_notify devait répondre immédiatement, fermer la connexion et abandonner ses écritures en attente. L’initiateur n’avait pas à attendre cette réponse avant de fermer son côté lecture.

Or une application peut avoir fini d’émettre sans avoir fini de recevoir. Une requête est partie, mais la dernière réponse est encore en construction. En obligeant les deux sens à mourir ensemble, la défense contre la troncature pouvait supprimer les données de retour qu’elle prétendait protéger.

TLS 1.3 définit donc close_notify comme la fermeture ordonnée d’un seul sens. L’émetteur ferme son écriture ; sa lecture reste ouverte. Le destinataire ne doit plus jeter ses écritures en attente ni répondre sur-le-champ. Chaque sens obtient sa propre fin.

Le texte précise aussi la limite : si la fermeture du transport arrive avant l’alerte, le destinataire ne peut savoir si toutes les données envoyées par le pair ont été reçues. Les records déjà authentifiés ne deviennent pas suspects rétroactivement. L’incertitude porte sur ce qui aurait pu venir ensuite.

HTTP apporte la preuve que TLS ne possède pas

HTTP over TLS expliquait déjà qu’une fermeture prématurée n’invalide pas les données reçues ; elle laisse possible une troncature ultérieure. TLS ignorant les frontières des réponses HTTP, le client devait lire le cadrage applicatif.

HTTP/1.1 conserve cette répartition. Content-Length donne un compte vérifiable. Le codage chunked possède un chunk nul terminal. Leur absence rend le message incomplet. Une réponse délimitée seulement par la fermeture n’est complète sur TLS qu’après une alerte de clôture valide : accepter autrement un préfixe comme résultat final ouvre une surface d’attaque.

L’alerte est donc décisive dans certains cas et seulement corroborante dans d’autres. Si l’application a déjà reçu exactement la longueur annoncée, elle peut reconnaître ce message comme complet malgré une clôture de connexion incomplète. Elle ne doit pas étendre ce constat aux messages suivants ni à une opération sans frontière vérifiée.

Avec HTTP/2, END_STREAM porte la fin sur un stream précis. D’autres streams continuent sur la même connexion. Ce marqueur ne remplace pas la fermeture TLS ; il prouve une frontière applicative distincte avant que le canal partagé ne se ferme à son tour.

La valeur vient de la portée limitée

close_notify ne prouve pas l’identité humaine, l’autorisation d’une transaction, la lecture des données ou la complétude de tout objet. Il établit une seule chose : cet émetteur n’ajoutera plus de messages TLS dans ce sens.

EOF est un événement local. L’alerte est une preuve protégée d’intention. Content-Length, chunk terminal et END_STREAM sont des preuves de structure. La fiabilité vient de leur combinaison sans confusion de mandat.

Sources et limites

Le corpus réunit RFC 2246, RFC 2818, RFC 5246, RFC 8446, RFC 9112 et RFC 9113. Il décrit les règles et leur histoire, non les réglages actuels des bibliothèques, leur diffusion ni la cause d’une alerte manquante.