Re: [obsdfr-misc] HS: sftp

["Cédric THIBAULT" <cedric POINT thibault AT gmail.com>]

Le 28/11/07, Nicolas Bernard <
nbernard-openbsd-france-misc-0db344c2cee665147c3f8eb57c6fe87ce7c5b0d1 AT lafraze POINT net>
a écrit :
>
> Cédric THIBAULT(cedric POINT thibault AT gmail.com)@2007.11.28 09:47:58 +0100
> wrote:
> > Bonjour,
> >
> > Sans vouloir troller inutilement
>
> Aller, je marche dedans! ;-)


effectivement :-)

> Quand on parle de FTP over SSH, il peut s'agir de 2 choses différentes.
> Soit
> > l'utilisation du protocole FTP sur un tunnel SSH,
>
> Je n'ai ni essayé ni cherché sur Internet, mais j'ai dans l'idée
> qu'encapsuler le protocole FTP standard avec ses connexions multiples
> dans un tunnel SSH ne doit pas être simple...


Absolument pas, le protocole FTP n'utilise que 2 ports (1 data et 1
commandes)  et par conséquent faire un tunnel via SSH ne pose
a priori pas de problèmes. Le seul point important est de vérifier que lors
de la négociation du port data à la connexion , le numéro de port soit
toujours le même. Autrement dit, il faut effectuer du FTP en mode passif et
laisser le serveur fixer le port data (classiquement le TCP 20).

> Maintenant, concernant le problème de fiabilité du transfert, il est vrai
> > qu'en plus des fonctions de confidentialité, SSH ajoute des fonctions
> > d'intégrité. Ces fonctions viennent s'ajouter au contrôle de
> transmission
> > effectué par TCP et permet en cas de modification du paquet lors de son
> > transfert sa réémission automatique.
>
> Je pense que les problèmes mentionnés de FTP sont plus liés à une
> implémentation qu'au protocole lui-même. Il est facile de supposer
> qu'un appel système du type read/write renvoie soit -1 soit la valeur
> attendue (ce qui est pratiquement toujours le cas). Si les tests ne sont
> pas trop poussés, les cas ou la valeur renvoyée est différente
> passeront facilement inaperçus.
>
> Dans le cas de scp, d'une part les programmeurs font attention à ce
> genre de choses, d'autre part, si jamais ils oublient, ils auront des
> problèmes de checksum (au niveau "applicatif", i.e. ssh) plus tard et
> dans un protocole sécurisé, elles doivent être prises au sérieux,
> donc ils vont chercher à voir d'où elles viennent... ce qui leur
> permettra de trouver le bug en question!


Je ne suis qu'en partie d'accord avec toi.
Je te rejoins sur le fait que le protocole FTP est un protocole fiable et
robuste. Mais cela est d'autant plus vrai qu'il repose sur la couche TCP qui
assure les fonctions d'acheminement fiable de la donnée. Le problème est que
dans FTP, il n'est null part prévu de vérifier l'intégrité de la donnée
transférée sauf utilisation de la commande SITE MD5 par le client. Donc, les
paquets FTP seront bien transférés et réceptionnés, mais la garantie que
ceux ci ne soient pas modifiés durant le transfert ne peut être apportée par
FTP.

Là ou je suis d'accord avec toi, c'est quand tu évoques le checksum
applicatif réalisé par SSH, c'est d'ailleurs ce que j'évoquai en parlant de
fonction d'intégrité...

Et là ou je suis sur que nous sommes tous d'accord c'est que FTP date de
plus de 30 ans (RFC 114 à l'originie) et qu'il est plus que temps de passer
à autre chose comme SSH et ses divers fonctionnalitées (tunnels, sftp,
scp...) !

:-)

Amicalement,
> Nicolas
>
>
> ________________________________
> French OpenBSD mailing list
> misc AT openbsd-france POINT org
> http://www.openbsd-france.org/ml
>
>