Résumé

  • En 1977, RFC 742 faisait d'une ligne réduite à CRLF la requête par défaut pour obtenir la liste des utilisateurs en ligne, leurs noms et, si possible, l'emplacement de leur terminal.
  • RFC 1288 conserva l'échange TCP d'une ligne, mais obligea le serveur à répondre ou à refuser activement certaines demandes et recommanda un réglage champ par champ de la divulgation.
  • Le port 79 coordonnait le lieu de la question. Il n'authentifiait ni la personne décrite ni la réponse, ne créait aucun droit d'accès aux données et ne rendait pas le texte reçu inoffensif pour un terminal.

Dans ce protocole, le blanc parlait

RFC 742, daté du 30 décembre 1977, décrit une opération sans cérémonie. Le client établit les connexions vers le socket 117 en octal, 79 en décimal, envoie une ligne terminée par CRLF et reçoit un rapport conçu pour un lecteur humain. Le serveur ferme une fois le texte transmis.

Une ligne nulle déclenche le rapport le plus large : toutes les personnes utilisant le système à cet instant. Le document demande au moins les noms complets et, dans la mesure où la machine le sait, la position physique des terminaux. Il juge également raisonnables le nom du job et le temps écoulé depuis la dernière frappe ou activité.

Avec un nom d'utilisateur, le service vise une personne. Il peut indiquer sa connexion présente, son dernier logout et un court message conservé dans un fichier particulier. Ce « plan » permet de signaler un horaire, un déplacement, un projet ou une façon de joindre l'auteur. La présence informatique devient ainsi une petite surface sociale accessible par le réseau.

Le cadre initial était étroit et identifiable. RFC 742 cite SAIL, SRI et plusieurs systèmes ITS ; il rattache FINGER de Les Earnest à la naissance de NAME sur ITS et attribue le protocole à Earl Killian et Brian Harvey. Entre groupes de recherche qui se connaissent, voir qui est là peut raccourcir une collaboration.

La structure ne demande pourtant ni identité ni motif au visiteur. La requête par défaut ne cherche pas un collègue précis : elle demande la population entière. Lorsque le réseau dépasse le cercle d'origine, la commodité reste identique tandis que l'audience devient indéterminée.

La liberté de mise en forme élargissait la fuite possible

Finger n'impose aucun format de sortie. C'est un choix fonctionnel : les systèmes ne possèdent pas les mêmes champs et le texte doit rester intelligible pour un humain. Mais cette souplesse autorise une réponse à accumuler identifiant, nom civil, terminal, bureau, téléphone, shell, répertoire, courrier et texte personnel.

L'option /W sollicite davantage de détails. Le texte de 1977 la nomme « Whois switch ». RFC 1288 la replace au début de la grammaire ; le dernier serveur peut l'interpréter comme une demande de verbosité supérieure ou l'ignorer. Ce n'est pas une seconde porte protégée par une preuve d'identité.

La recherche par nom ajoute une autre largeur. Le login doit être compris, mais un serveur peut accepter un nom de famille ou un nom complet. Une entrée ambiguë peut produire plusieurs candidats. Ce mécanisme rend service à celui qui ne connaît pas le compte exact, tout en permettant à un demandeur persistant de reconstituer des noms même si la liste générale est coupée.

Deux réponses lisibles ne sont pas nécessairement comparables. « Idle » peut mesurer la frappe sur un système et l'activité d'un job sur un autre. L'absence d'une ligne peut signifier aucune session, une donnée inconnue ou une politique restrictive. L'utilisateur reçoit la présentation locale de l'hôte, non une mesure universelle.

La norme fit du refus un résultat, pas un silence

En décembre 1990, RFC 1196 s'appuie sur le comportement BSD devenu courant. Il cherche à clarifier sans casser les nombreuses installations existantes et avertit que restituer des informations sur les utilisateurs est une matière sensible.

RFC 1288 paraît un an plus tard. Il corrige la position de /W, précise les espaces et décrit plus exactement la fermeture. Le trajet demeure : TCP 79, une ligne ASCII finie par CRLF, une réponse, puis la fermeture. La mutation principale porte sur l'attribution des décisions.

Pour la requête vide {C}, le serveur doit répondre ou refuser activement. S'il répond, il donne au minimum les noms complets ; l'administrateur devrait décider d'ajouter ou non terminal, bureau, téléphone professionnel, job et durée d'inactivité. Si la liste est désactivée, un message de refus est une réponse conforme.

Cette formulation sépare deux observations. Une liste vide prétend décrire le monde : personne n'est connecté. Un refus décrit la règle du site : la population ne sera pas exposée. Le second résultat ne transforme pas une décision de confidentialité en fausse donnée opérationnelle.

RFC 1288 appelle aussi à une « décharge atomique » : chaque atome d'information doit pouvoir être choisi. Un site peut publier bureau, téléphones et heures de login ; un autre seulement le contact de bureau ; un troisième le seul nom exigé. Une syntaxe commune ne force plus un paquet commun de données personnelles.

Le relais déplaçait la frontière de celui qui peut demander

Une requête Q2 peut chaîner des éléments @hostname. Le premier RUIP ouvre alors une autre connexion Finger, transmet le reste de la question et renvoie la réponse vers l'amont. La grammaire ne pose pas de limite arbitraire au nombre d'hôtes.

RFC 1288 exige que ce relais soit fourni ou refusé explicitement. Il recommande le refus par défaut, particulièrement sur une passerelle. Une machine joignable depuis l'extérieur peut, en relayant, donner accès à un service intérieur que le demandeur ne pouvait pas atteindre directement.

Le relais n'authentifie pas l'origine. Il ne rend pas publique une réponse interne. Il prête simplement la joignabilité du nœud intermédiaire. Une chaîne peut respecter chaque octet de la norme et néanmoins franchir une séparation institutionnelle que personne n'avait voulu ouvrir.

L'inventaire d'exposition doit donc regarder au-delà des sockets directement accessibles. Il faut savoir quels serveurs acceptent Q2, quelle destination finale répond, comment le refus apparaît et quel journal associe les étapes.

Le plan donnait la plume, pas la maîtrise de l'audience

Le fichier plan a une qualité rare : l'utilisateur écrit lui-même ce que les autres liront. Pourtant l'auteur ne voit pas nécessairement toutes les personnes capables d'interroger le serveur. L'écriture et la distribution appartiennent à deux autorités distinctes.

RFC 1288 avertit qu'un fichier modifiable par l'utilisateur peut diffuser librement n'importe quelle information sur le système. Une note de bonne foi peut révéler un détail interne ; un contenu malveillant peut tromper ; le code qui trouve et lit le fichier peut dépendre d'hypothèses fragiles.

Certaines variantes permettent même de lancer un programme utilisateur en réponse. Une lecture distante devient alors un déclencheur d'exécution. L'administrateur doit pouvoir supprimer cette fonction, et le programme ne doit jamais compromettre le système. Le même canal minimal rejoint ainsi la surface d'exécution.

Il faut préserver trois responsabilités : l'utilisateur choisit son message, l'opérateur décide ce qui sort de l'hôte, et le client décide comment rendre les octets. Le consentement de l'un ne vaut pas mandat pour les deux autres.

Un texte destiné à l'œil restait une entrée hostile

L'absence de format strict ne retire pas aux caractères leur pouvoir. RFC 1288 recommande que le client filtre par défaut tout ce qui n'est pas ASCII imprimable sur sept bits, tabulation ou CRLF. Des séquences de contrôle pourraient sinon modifier le nom d'une fenêtre X ou provoquer d'autres actions déroutantes.

Le problème existe aussi à l'envoi. Dès 1977, RFC 742 note qu'un client Telnet généraliste peut injecter ses négociations IAC dans la ligne Finger et fausser son interprétation. Deux protocoles transportent du texte ; ils ne partagent pas pour autant les commandes invisibles.

« Lisible par l'humain » désigne le destinataire, non une propriété de sûreté. Le client émetteur doit respecter la grammaire d'une ligne ; le client récepteur doit considérer la réponse comme des données étrangères avant de l'offrir à un terminal.

Sécuriser le daemon et limiter les informations sont deux contrôles

RFC 1288 invoque le ver Morris pour placer Finger au périmètre de sécurité de l'hôte, au même titre que Telnet, FTP ou SMTP. Même un petit parseur exposé au réseau doit subir des essais contre les entrées malformées et des tests de pénétration.

Un serveur techniquement robuste peut toutefois trop parler. Le RFC évoque une implémentation qui révélait dernière connexion, dernière lecture du courrier, présence de messages non lus et expéditeur du plus récent. Sans détourner le code, un observateur pouvait suivre une conversation et l'attention d'une personne.

À l'inverse, répondre avec peu de champs ne prouve pas l'absence de vulnérabilité. Entrées malformées, relais, hooks exécutables et caractères de contrôle restent à tester. La sûreté du processus et la minimisation des données ne se remplacent pas.

Le journal des requêtes rend l'abus visible : noms répétés, ambiguïtés exploitées, /W, relais. Mais ce journal cartographie aussi l'intérêt porté à des personnes. Il lui faut donc sa propre finalité, un accès restreint et une échéance de conservation.

IANA garde l'adresse, pas le droit d'obtenir la réponse

Le registre IANA des services et ports de transport conserve finger sur le port 79 en TCP et en UDP. RFC 1288 spécifie l'échange TCP. L'inscription permet de partager un point de rendez-vous historique.

Elle ne constate pas qu'un hôte exécute aujourd'hui le service, ni que sa sortie est fiable ou sûre. Un numéro de port indique où poser une question si le service existe. Il ne commande pas à l'opérateur d'ouvrir, au sujet de se laisser décrire, ni au destinataire de croire le texte.

Finger décrit surtout l'état momentané vu par une machine et parfois une auto-description. Ce n'est ni une attestation signée de la personne ni un dossier administratif doté d'une chaîne de modification.

La question commune survécut en perdant son autorité par défaut

L'histoire ne se réduit pas à une innocence corrigée par la sécurité. Le premier texte savait déjà que les formats divergeaient et que Telnet pouvait polluer la ligne. Les normes suivantes n'ont pas nié l'utilité sociale ; elles ont rendu visibles les lieux de décision.

La requête vide subsiste, mais peut être refusée. Le profil détaillé subsiste, mais ses champs sont sélectionnés. Le relais subsiste, mais son défaut doit être négatif. Le plan subsiste, mais son auteur ne détermine pas seul toute sa portée. Le texte libre subsiste, mais le client filtre les commandes cachées.

Finger n'apporte pas automatiquement la confidentialité. Il cesse de cacher où elle doit être gouvernée. Le port 79 répond « où demander » ; l'opérateur répond « quoi divulguer » ; le client répond « comment afficher ». La grammaire commune n'autorise aucun de ces acteurs à parler au nom des autres.

Sources et limites

Ces sources établissent l'histoire normative, la grammaire, les recommandations de sécurité et l'enregistrement du port. Elles ne mesurent ni déploiement actuel, ni fréquence d'attaque, ni politique d'un site donné. L'entrée IANA n'est donc pas prise pour une preuve d'activation, et les exemples RFC ne sont pas attribués à toutes les implémentations historiques.