Résumé

  • Après TLS comme après SASL, XMPP remplaçait le flux XML en cours sans fermer normalement ce flux ni rompre la connexion TCP qui le portait.
  • Le nouvel en-tête, le nouvel identifiant de flux et la nouvelle annonce de fonctions décrivaient un état différent ; continuité TCP, chiffrement, identité du pair, authentification, liaison de ressource et admission des stances restaient des faits séparés.

Le paradoxe se trouvait dans le mot « succès »

Un serveur XMPP vient d’envoyer proceed, puis la poignée de main TLS s’achève correctement. Les octets suivants circuleront sous protection. L’intuition voudrait que le même flux continue, devenu simplement plus sûr. Le protocole refuse cette facilité.

L’initiateur émet un nouvel en-tête de flux sur la connexion chiffrée. Il ne ferme pas l’ancien flux avec </stream>. Le destinataire répond par un nouvel en-tête, crée un autre identifiant de flux et présente les fonctions valables après TLS. La socket n’a pas bougé ; l’objet XML qui y vivait a été remplacé.

La réponse SASL <success/> produit un effet comparable. Elle confirme l’issue de l’échange d’authentification, puis rend son propre contexte périmé. L’initiateur ouvre encore un flux sur le TCP existant. Ce n’est qu’à ce stade que le serveur peut annoncer, pour un client, la liaison de ressource.

La réussite est donc terminale pour le flux qui l’a produite, mais non pour la connexion ni pour toute la négociation XMPP. Elle clôt une étape en révélant la suivante.

TCP portait plusieurs générations sans les confondre

RFC 6120 distingue soigneusement une connexion TCP et un flux XML. TCP est bidirectionnel. Un flux XMPP est, au sens strict, unidirectionnel ; les deux entités disposent habituellement d’un flux dans chaque sens.

Lorsqu’une fonction exige un redémarrage, les parties considèrent le flux précédent comme remplacé. Elles ne transmettent pas sa balise de clôture et ne terminent pas TCP. Elles réemploient la connexion, éventuellement transformée par TLS, puis échangent de nouveaux en-têtes. Le destinataire doit produire un identifiant neuf plutôt que recycler l’ancien.

Parler de « reconnexion » serait inexact. Une reconnexion TCP recréerait une association de transport, avec un nouveau chemin possible et de nouveaux états réseau. Ici, l’économie consiste justement à conserver ce transport tout en détruisant le contexte applicatif devenu inadéquat. Ce n’est pas non plus une reprise de flux, une répétition des stances ou une garantie de livraison.

Une même socket contient ainsi plusieurs chronologies : durée de TCP, activation de TLS, résultat SASL et générations successives du flux XML. L’observateur qui ne garde qu’un booléen « connecté » perd l’ordre des faits et leur portée.

Une annonce de fonctions n’était jamais un catalogue éternel

Les « stream features » disaient ce qui restait à négocier dans l’état présent. La présence d’au moins une fonction obligatoire indiquait que l’initiateur devait poursuivre la négociation avant d’envoyer normalement des stances. Une liste vide, ou limitée aux fonctions volontaires, signalait au contraire que la négociation pouvait être tenue pour achevée.

La séquence était structurante : TCP, puis TLS, puis SASL, puis XMPP. Les mécanismes SASL proposés pouvaient dépendre de la protection TLS déjà obtenue. La liaison de ressource n’apparaissait qu’après l’authentification. Copier la première liste de fonctions dans le flux suivant aurait donc attribué au nouvel état une photographie prise dans l’ancien.

Après chaque redémarrage, le serveur devait réannoncer les fonctions disponibles. Cette obligation transformait la liste en surface de permission contextuelle. Elle ne disait pas : « voici tout ce que ce logiciel sait faire ». Elle disait : « voici ce que ce pair peut ou doit négocier maintenant ».

L’absence d’un élément a la même limite. RFC 7590 rappelle qu’un attaquant peut retirer l’annonce STARTTLS ou son enfant required. Ne pas voir une fonction peut refléter l’étape, la politique, un défaut ou une intervention sur le chemin. Une capture prouve ce qui a été reçu, non l’ensemble des capacités réelles du serveur.

TLS retirait sa valeur probante au passé non protégé

Après une négociation TLS réussie, RFC 6120 demande aux deux côtés d’abandonner les informations obtenues de manière non sûre au-dessus de TCP. Sont notamment visés l’adresse from, l’ancien identifiant de flux et les fonctions reçues avant le chiffrement.

Le redémarrage répond donc à un problème de provenance. Si l’on conservait sans examen les affirmations pré-TLS, un intermédiaire actif pourrait façonner le contexte que le système qualifierait ensuite de protégé. Les nouveaux en-têtes ne décorent pas le canal chiffré : ils obligent les parties à reformuler leurs affirmations dans le contexte qui doit les soutenir.

Cela ne permet toujours pas de réduire TLS à « identité vérifiée ». Le chiffrement d’un canal, la validation d’un certificat, l’identité visée et la politique d’acceptation sont des résultats différents. RFC 7590 renforce les obligations d’authentification des clients et des serveurs, tout en reconnaissant comme cas distincts et plus faibles certaines connexions chiffrées mais non authentifiées entre serveurs.

Une journalisation sérieuse doit donc conserver la méthode de vérification, son résultat et la règle appliquée. Le simple fait qu’un nouveau flux s’ouvre après TLS ne dit pas quelle identité a été démontrée.

SASL authentifiait sans distribuer toutes les autorisations

RFC 4422 présente SASL comme un cadre de mécanismes remplaçables pour les protocoles orientés connexion. Il sépare l’identité d’authentification, l’identité d’autorisation, l’issue de l’échange et l’éventuelle couche de sécurité négociée. Tous les mécanismes ne fournissent pas les mêmes propriétés.

XMPP transporte cet échange dans son vocabulaire XML. Après SASL, il impose un nouveau flux sur le TCP existant. Le serveur génère un autre identifiant et expose les fonctions accessibles dans l’état authentifié.

Le mot « authentifié » reste borné. SASL peut établir l’identité qui a présenté les justificatifs et, selon le mécanisme, celle au nom de laquelle elle demande à agir. Il ne lie pas automatiquement une ressource, n’autorise pas chaque destination et ne prouve pas qu’une application distante traitera un message.

Pour un client, la liaison de ressource demeure obligatoire. Le serveur ne l’annonce qu’après la réussite SASL. Si le client tente avant cette liaison d’envoyer une stance à une autre entité que le serveur ou son propre compte, RFC 6120 exige que le serveur ne la traite pas et ferme le flux avec l’erreur not-authorized.

La réussite SASL remplace donc une question par une autre. « Les justificatifs ont-ils abouti ? » devient « quelles opérations sont maintenant offertes, et quelle adresse complète sera liée à ce flux ? »

La liaison achevait l’étape sans provoquer un troisième redémarrage

La liaison associe au compte authentifié une partie ressource qui distingue ce client connecté de ses autres ressources. Elle modifie l’adressage et ouvre l’accès normal aux stances. Pourtant, le texte est explicite : après la liaison de ressource, les parties ne doivent pas redémarrer le flux.

Cette interdiction révèle que le redémarrage n’était pas un rituel attaché à toute réponse positive. TLS et SASL modifiaient les conditions dans lesquelles les affirmations précédentes avaient été apprises. La liaison intervenait déjà dans le flux post-authentification et n’exigeait pas une nouvelle purge.

Une implémentation correcte a donc besoin d’un automate à états. TCP ouvert ne signifie pas TLS établi. TLS établi ne signifie pas pair validé. Pair validé ne signifie pas SASL terminé. SASL terminé ne signifie pas ressource liée. Ressource liée ne signifie pas message délivré.

L’identifiant de flux lui-même reste une donnée technique, non une identité d’utilisateur, un jeton universel ou un reçu. XMPP rend la progression visible ; il ne transforme pas chaque repère en preuve de l’étape finale.

De 2004 à 2015, la frontière devint plus explicite

RFC 3920, publié en octobre 2004, imposait déjà un nouveau flux après la réussite de TLS et après <success/> de SASL. Il fixait l’ordre TCP, TLS, SASL, XMPP et considérait l’ancien flux comme clos à ces points sans demander sa balise de fermeture.

RFC 6120 l’a remplacé en 2011. Il a rendu le modèle plus général et plus lisible : l’ancienne génération est remplacée, TCP est réemployé, un nouvel identifiant est créé et les fonctions du nouvel état sont envoyées. Il ne s’agissait pas d’inventer tardivement le redémarrage, mais d’exprimer nettement sa grammaire et sa raison.

RFC 7590 a ensuite durci en 2015 les recommandations TLS face à un environnement de menace transformé. Cette évolution interdit de prendre la chorégraphie pour une attestation globale de sécurité. Le protocole peut exécuter la bonne transition alors qu’une politique de certificats ou de mécanismes reste insuffisante.

L’idée qui traverse cette histoire est plus générale que la messagerie. On peut préserver une ressource coûteuse — la connexion — sans accorder à l’ancien contexte un droit de survie. Quand les conditions de confiance changent, la continuité du câble ne doit pas devenir continuité automatique des affirmations.

Sources