Summary

  • FTP négociait les commandes sur une connexion de contrôle et transportait les fichiers sur une connexion de données distincte.
  • RFC 1579 réutilisait PASV pour inverser l’initiation de cette seconde connexion : le filtrage côté client devenait plus simple, mais le serveur devait accepter des ports entrants.

Une session FTP pouvait annoncer « envoyer ce fichier » sans transporter le fichier sur la connexion qui portait la commande. Cette séparation faisait partie de sa conception. Elle avait une conséquence pratique : réussir à ouvrir une session, puis obtenir une réponse positive à RETR, ne garantissait pas que les octets passeraient. Il fallait encore établir une seconde connexion TCP, dans le sens choisi par FTP.

La spécification de 1985, RFC 959, séparait un processus de contrôle pour les commandes et réponses et des processus de données pour les transferts. Dans le cas habituel, le client ouvrait la connexion de contrôle vers le serveur, généralement sur le port 21. Avant un transfert, il pouvait envoyer PORT avec son adresse et un port où il se mettrait à l’écoute. Le serveur ouvrait alors la connexion de données vers le client. Le canal de transfert n’était pas le canal de commande ; un pare-feu qui acceptait le premier n’acceptait donc pas automatiquement le second.

Le protocole comportait déjà une autre option. Avec PASV, le client demandait au processus de données du serveur de se mettre à l’écoute sur un port non standard. Le serveur renvoyait l’adresse et le port, puis le client ouvrait la connexion de données vers lui. Le fichier utilisait toujours une seconde connexion ; seul l’initiateur changeait. Le mode passif existait donc bien avant de devenir une réponse recommandée au filtrage par pare-feu.

En 1994, le comportement courant s’écartait parfois du modèle par défaut d’origine. Dans RFC 1579, Steven Bellovin écrit que les clients ouvraient généralement une nouvelle connexion de données pour chaque transfert, choisissaient un port client neuf pour éviter l’attente TCP TIME-WAIT, puis l’annonçaient avec PORT. Un filtre voyait alors un appel entrant vers un port imprévisible. Les pare-feu autorisaient souvent quelques services entrants tout en refusant ces connexions, même après l’authentification sur le canal de contrôle.

RFC 1579 recommandait aux éditeurs de faire utiliser PASV plutôt que PORT aux clients FTP, y compris aux agents mandataires de Gopher. Le canal de données devenait alors un appel sortant depuis le client. Pour un pare-feu situé du côté utilisateur, il était plus facile d’autoriser cette ouverture que d’accepter un appel entrant spontané vers un port aléatoire. La note ne proposait aucun nouveau protocole : la commande existait déjà et les deux modes exigeaient un échange préalable comparable avant le transfert.

Cette solution déplaçait la frontière difficile au lieu de la supprimer. En mode passif, le serveur devait accepter les appels entrants sur les ports choisis pour les transferts. RFC 1579 reconnaissait que cette option pouvait créer un problème de pare-feu côté serveur. L’argument était opérationnel : les serveurs étaient moins nombreux que les clients, et leur exploitant pouvait limiter la plage de ports de données. Il s’agissait d’une proposition sur l’endroit où gérer l’exposition, pas d’une preuve d’adoption générale.

Les textes normatifs aident à distinguer une capacité requise d’un comportement réellement répandu. RFC 1123, publié en 1989, imposait aux serveurs FTP d’implémenter PASV et précisait l’interprétation de sa réponse, tout en signalant que le format restait mal normalisé. RFC 1579 indique ensuite qu’au moins deux clients modifiés indépendants existaient. Aucun de ces textes ne mesure la part des utilisateurs ou des sites ayant changé de mode. La note de 1994 documente une recommandation et quelques implémentations, non une migration universelle.

FTP avait ainsi deux surfaces opérationnelles. Le canal de contrôle transportait identifiants, commandes et réponses de réussite ; le canal de données portait une liste ou un fichier. Une réponse telle que « ouverture de la connexion de données » n’était pas le fichier, et une authentification réussie ne prouvait pas que le transfert avait abouti. Pour diagnostiquer une panne, il fallait suivre les deux sockets et savoir quelle extrémité devait initier chacune.

La leçon de RFC 1579 est plus précise que « les pare-feu ont cassé FTP ». Le protocole proposait déjà plusieurs sens d’ouverture de la connexion de données. Le filtrage a rendu ce choix déterminant. PASV plaçait l’initiative du côté où le pare-feu du client était plus susceptible de l’autoriser, tout en demandant au serveur de gérer une plage d’entrées bornée. Le protocole restait identique ; la charge opérationnelle se déplaçait.

Sources