Résumé

  • Le RFC 2384 réunissait serveur, port, identité de boîte et choix d’authentification dans une URL POP, mais en excluait volontairement le mot de passe en clair.
  • Recevoir cette URL ne suffisait pas à libérer un secret : il fallait une provenance fiable, une règle locale, une confirmation humaine, une validation du serveur ou un mécanisme ne révélant rien de réutilisable.

Une adresse assez riche pour déclencher une action

Configurer un accès POP3 exigeait plusieurs données. Le logiciel devait savoir à quel hôte se connecter, sur quel port, pour quelle boîte et selon quelle méthode d’authentification. Le RFC 2384 proposa de rassembler ces éléments dans une forme transportable : pop://<user>;auth=<auth>@<host>:<port>.

L’hôte était obligatoire. Le port pouvait être omis et prendre la valeur 110. L’identité et le mécanisme pouvaient apparaître ou non. Le résultat tenait dans une chaîne susceptible d’être stockée dans un service de configuration, transmise par un autre programme ou saisie par un utilisateur.

Cette commodité créait aussitôt une surface de décision. Une chaîne reçue n’était pas seulement un objet à afficher. Un client pouvait la traduire en connexion réseau, demander un mot de passe puis envoyer une commande USER et PASS, ou choisir APOP, AUTH et un mécanisme SASL. La représentation devenait la cause d’une action. Le RFC devait donc répondre à une question que la grammaire ne pouvait pas résoudre : qui avait qualité pour faire suivre l’identifiant jusqu’à l’hôte indiqué ?

L’absence du mot de passe ne supprimait pas son mouvement

Le texte interdisait le mot de passe en clair dans l’URL. C’était un plancher de prudence cohérent avec la mobilité des URL : elles peuvent se retrouver dans des documents, des journaux, des interfaces ou des bases de configuration. Ne pas y inscrire le secret réduisait une exposition évidente.

Mais le client pouvait déjà connaître ce secret. Il pouvait l’avoir conservé après une session précédente ou le demander à l’ouverture du lien. Une URL dépourvue de mot de passe restait donc capable de provoquer sa divulgation. La différence entre contenir le secret et déclencher son envoi est le cœur du problème.

Le RFC 2384 le formula explicitement. Les URL pouvaient provenir de sources non fiables. Envoyer des identifiants au mauvais serveur pouvait compromettre le compte. Et un client qui conservait un mot de passe en clair ne devait pas l’utiliser à la suite d’une URL POP sans permission explicite de le fournir au nom d’hôte concerné.

Cette règle ne disait pas seulement « ne mettez pas un mot de passe dans un lien ». Elle refusait qu’une référence hérite automatiquement de l’autorité nécessaire pour faire agir un coffre de secrets.

Une seule notion d’utilisateur cachait deux fonctions

Le document parlait commodément de « nom d’utilisateur », tout en signalant qu’il pouvait s’agir de deux identités. L’identité d’autorisation indiquait la boîte à ouvrir. L’identité d’authentification indiquait le titulaire du secret à vérifier. Elles pouvaient coïncider, mais une égalité de valeur ne supprimait pas la différence de fonction.

Le mécanisme d’authentification formait un autre axe. Si l’URL nommait un mécanisme SASL, APOP ou une extension précise, le client devait suivre ce choix et ne pas lui en substituer un autre sans permission explicite. La chaîne fixait une proposition ; elle n’autorisait pas une dégradation silencieuse.

Le cas ;AUTH=* ouvrait au contraire un espace de sélection. Le client devait choisir un mécanisme approprié et pouvait employer n’importe quel mécanisme accepté par le serveur. Surtout, une URL contenant un utilisateur mais aucun mécanisme était interprétée comme si ce joker était présent. La forme la plus courte pouvait donc être la moins déterminée.

Le RFC invitait à traiter ce joker avec une prudence particulière, car il pouvait aboutir à un mécanisme plus faible. Sa référence à un chiffrement de plus de 56 bits appartient à son époque et ne constitue pas une recommandation actuelle. La structure de la mise en garde, elle, n’a pas vieilli : l’omission déplace le pouvoir de décision vers la négociation et les règles de repli.

Cinq preuves possibles, cinq autorités différentes

Le RFC ne transforma pas la syntaxe en dispositif magique de confiance. Il énuméra cinq conditions dont au moins une devait être satisfaite avant d’utiliser des identifiants demandés par une URL.

La source de l’URL pouvait être un service de renvoi déjà validé et reconnu par la politique du site. Une politique locale explicite pouvait autoriser le serveur, par exemple dans un domaine connu. L’utilisateur pouvait confirmer le domaine exact et l’emploi de l’identifiant ou du mécanisme. Le mécanisme d’authentification pouvait vérifier le serveur avant de transmettre une donnée compromettante. Enfin, le mécanisme pouvait ne rien révéler qui permette au destinataire de compromettre une connexion future.

Ces possibilités ne produisaient pas la même preuve. La première portait sur la provenance. La deuxième sur une délégation administrative. La troisième sur un consentement circonstancié. La quatrième sur l’identité cryptographique du pair. La cinquième réduisait ce que le pair malveillant pouvait exploiter.

L’auteur du lien contrôlait l’itinéraire proposé. Il ne contrôlait aucune de ces preuves par défaut. Le client gardait la faculté décisive de retenir le secret.

Interdire le relatif ne rendait pas l’absolu digne de confiance

Les URL POP relatives étaient interdites. Une référence ne pouvait donc pas emprunter silencieusement son hôte au contexte d’un document. Elle devait désigner une destination absolue.

Cette décision supprimait une ambiguïté de résolution, mais pas le problème d’autorité. Un attaquant peut écrire un nom d’hôte complet. Une chaîne parfaitement encodée peut viser le mauvais opérateur. Une politique fondée sur un suffixe de domaine peut devenir trop large. La complétude syntaxique prouve que l’instruction est interprétable, pas qu’elle mérite d’être exécutée.

La distinction est utile au-delà de POP. Elle sépare le reçu de lecture — « voici les composants que j’ai analysés » — du reçu d’autorisation — « voici pourquoi cette destination peut recevoir cette catégorie de secret ».

Deux exemples rattrapés par l’exécution

Les deux errata attachés au RFC 2384 donnent à cette histoire une conclusion particulièrement nette. L’exemple APOP imprimait un condensat qui ne correspondait pas au défi du serveur et au mot de passe montrés. L’Errata 2943, vérifié, fournit le condensat corrigé. Un autre exemple utilisait le nom SCRAM-MD5, alors que le mécanisme pertinent à cette date était CRAM-MD5. L’Errata 2942 fut conservé pour une future mise à jour, car corriger le nom exigeait aussi de refaire l’échange encodé.

Ce ne sont pas des preuves d’incidents en production. Elles ne rendent pas le schéma POP caduc. Elles démontrent quelque chose de plus précis : une transcription qui ressemble à un protocole n’est pas encore la preuve de son exécution. Le nom du mécanisme, les octets de l’échange, la réussite de l’authentification et l’ouverture de la boîte sont des faits séparés.

Le code en fonctionnement tranche là où la prose tolère parfois une approximation. Un condensat correspond au calcul ou n’y correspond pas. Une implémentation connaît un mécanisme sous le bon nom ou ne peut pas lancer celui que l’exemple désigne. La preuve apparaît à la frontière d’exécution, non dans l’apparence convaincante du texte.

La modestie d’un protocole simple

POP3 était volontairement limité. Le RFC 1939 ordonnait la session en états d’autorisation, de transaction et de mise à jour. Le RFC 1734 définissait la commande AUTH. Le RFC 2222 donnait le cadre SASL. Le RFC 2449 ajouta ensuite l’annonce des capacités du serveur. Le RFC 2384 n’essaya pas d’absorber ces responsabilités dans une super-URL.

Il spécifia le minimum commun : comment nommer une ressource et proposer une méthode. Il laissa les décisions futures au lieu où leur preuve pouvait être examinée — politique locale, utilisateur, client et échange d’authentification. C’est une forme de coordination mince : assez de déterminisme pour rendre la configuration portable, pas assez de pouvoir implicite pour transformer toute chaîne reçue en ordre de divulgation.

Même après l’authentification, il faut résister aux raccourcis. Une connexion ne prouve pas l’autorisation d’envoyer le secret. Une authentification positive ne prouve pas que la bonne boîte a été ouverte. Une boîte ouverte ne prouve pas que le message voulu a été récupéré. Des octets récupérés ne prouvent pas leur conservation ou leur présentation correcte. Chaque passage demande son propre reçu.

Le RFC 2384 rendait une boîte aux lettres plus facile à désigner. Sa leçon durable fut de ne pas confondre ce pouvoir de désignation avec le pouvoir d’obtenir les clés.

Sources