Re: [obsdfr-misc] HS: sftp

[Nicolas Bernard <nbernard-openbsd-france-misc-0db344c2cee665147c3f8eb57c6fe87ce7c5b0d1 AT lafraze POINT net>]

Re.

> 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.

Certes, mais dans la pratique je ne pense pas que les erreurs de
transmissions viennent de TCP, mais plutôt de l'utilisation de celui-ci
par l'implémentation de FTP (que ce soit côté client ou
serveur). Autrement dit, si vérifier au niveau FTP la somme de
contrôle est une assurance supplémentaire (la bonne vielle approche
"bretelles ET ceinture"), ce ne devrait pas être nécessaire s'il n'y a
de bug ni d'un côté ni de l'autre...

> 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é...

Oui, j'avais bien compris. Mais si SSH fait des contrôles
d'intégrités supplémentaires, c'est pour des questions de sécurité
et non de fiabilité: a priori on suppose que les données transmises
par TCP sont correctes (sauf attaque). Même si bien sûr une erreur
multiple qui passe le CRC de TCP peut toujours se produire et est en
effet alors détectée par la vérification cryptographique.

> 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...) !

FTP over IPsec? ;-)

N.