Résumé

  • Dans la RFC 742, une ligne réduite à CRLF demandait à un hôte précis la liste des personnes alors connectées à ce système.
  • La requête pouvait circuler d’une machine à l’autre, mais la réponse restait produite localement; la RFC 1288 a ensuite explicité le refus et le choix des champs.

L’hôte restait la source du renseignement

Pour comprendre Finger, il faut regarder la requête la plus courte. Le client ouvrait une connexion vers une machine, envoyait un retour chariot suivi d’un saut de ligne, puis attendait. Dans la spécification de décembre 1977, cette ligne vide demandait la liste des personnes qui utilisaient le système à cet instant. Elle visait un hôte donné. Elle ne lançait pas une recherche dans tout l’ARPANET et ne consultait pas un registre central de présence.

La RFC 742, signée Ken Harrenstien, décrivait une interface réseau vers des programmes NAME et FINGER déjà utilisés à SAIL, au SRI et sur plusieurs systèmes ITS du MIT. Elle rapprochait la requête vide d’une commande locale d’état du système, comme systat sous TOPS-10 ou TENEX. La liste pouvait donner le nom complet et l’emplacement du terminal; le nom du travail et le temps d’inactivité étaient présentés comme des compléments utiles. Une requête nominative suivait une autre logique: elle pouvait décrire la session en cours ou, pour une personne déconnectée, indiquer sa dernière déconnexion et afficher un message de plan écrit par l’utilisateur.

Le changement d’échelle est essentiel. Une requête nominative part d’un compte connu. Une requête vide demande à l’hôte de révéler un ensemble d’utilisateurs. Le protocole rendait cette question simple à transporter, mais ne définissait pas une liste valable partout. La RFC 742 précise que la réponse dépend du système interrogé et qu’aucun format n’est obligatoire. Ses exemples montrent des terminaux, des pièces, des tâches et des durées d’inactivité; ils prouvent ce que certains exemples illustrent, pas ce que tous les serveurs auraient affiché.

Une réponse lisible n’est pas une preuve

Une ligne pouvait sembler concluante: un nom, un terminal, parfois quelques minutes d’inactivité. Pourtant, la RFC décrit un programme distant qui produit un état destiné aux humains, pas une autorité indépendante qui certifie l’identité d’une personne. Elle ne définit ni lien cryptographique entre le nom affiché et la personne au clavier, ni mesure de présence à l’échelle du réseau. Lire la réponse comme le compte rendu d’un hôte est une déduction fondée sur le périmètre et le format du protocole; en faire une preuve d’identité ou un recensement complet d’Internet dépasserait les textes.

Les champs eux-mêmes n’avaient pas tous le même statut. Un identifiant de connexion ou un nom complet pouvait aider un collègue à reconnaître un compte. L’emplacement du terminal ou la durée d’inactivité pouvait suggérer où se trouvait quelqu’un et s’il travaillait. Un fichier de plan contenait éventuellement du texte rédigé par l’utilisateur, tandis que les données de session provenaient du système. Une réponse unique pouvait donc mêler des informations de sources, de rythmes de mise à jour et de sensibilité différents. La RFC 742 laissait une large part de cet agencement à chaque installation.

Les clarifications ont suivi les systèmes existants

La suite ne fut pas une reconstruction complète. En novembre 1990, la RFC 1194 cherchait à clarifier la communication sans invalider les nombreuses implémentations existantes ni ajouter de restrictions inutiles. Elle estimait que les implémentations alors les plus répandues semblaient surtout dériver du travail BSD UNIX de Berkeley; cette observation datée n’est pas un recensement des déploiements. La RFC 1196, publiée le mois suivant, apporta des corrections et précisions mineures. En décembre 1991, la RFC 1288 remplaça les trois textes antérieurs.

La nouvelle description rendait la requête vide plus explicite. La requête {C} demandait la liste de tous les utilisateurs en ligne. Le programme distant devait répondre ou refuser clairement. S’il répondait, il devait fournir au moins le nom complet; l’administrateur devait pouvoir choisir les autres champs utiles. La section de sécurité autorisait aussi le refus de cette liste générale et avertissait que les renseignements sur les utilisateurs pouvaient être sensibles. Une implémentation citée en exemple révélait les heures de connexion et de lecture du courrier, l’existence de messages non lus et le nom du dernier expéditeur. C’est un exemple de voie de divulgation, pas la description de chaque serveur.

Cette limite était réelle, sans constituer une garantie contre toute fuite. La décision appartenait au site interrogé: activer le service, refuser la liste générale ou limiter les champs. La RFC 1288 parlait également des attaques contre les implémentations, notamment du ver Morris; ce risque est distinct. Une faille qui permet d’exécuter du code ou de compromettre un serveur n’est pas la même chose qu’un service fonctionnel qui révèle des données choisies par son opérateur.

Ce qui devenait interopérable

Le protocole rendait assez commun le geste du client et le type de question: demander l’état d’un compte ou la liste des utilisateurs d’un hôte. Il ne rendait pas commun le sens, l’exhaustivité ni la fraîcheur de la réponse. C’est un motif précoce de l’histoire d’Internet: une syntaxe de requête partagée peut coexister avec le contrôle local de la production et de la divulgation des données. Le chemin est commun; le renseignement reste situé sur la machine qui répond.

Les RFC ne disent pas combien de sites exploitaient Finger, combien de requêtes vides circulaient, si les administrateurs utilisaient les refus prévus, ni si chaque réponse était à jour. Elles documentent un service et l’évolution de sa spécification, pas son adoption à l’échelle du réseau. La conclusion historique doit rester précise: à partir de 1977, une requête simple pouvait rendre accessible à distance la liste des utilisateurs d’un hôte; en 1991, la spécification décrivait le refus et le choix local des champs comme des éléments du contrôle de ce service.

Sources