Journal Les clients graphiques FTP par défaut sous Debian ne gèrent pas TLS/SSL

Posté par . Licence CC by-sa
2
11
juil.
2017

Ce matin, j'ai été surpris de constater que lorsqu'on se connecte à un serveur FTP distant via gvfs (donc via Nautilus, PCManFM, …), le chiffrement TLS n'est pas pris en charge. Conséquence : les identifiants et les données sont transmis en clair sur le réseau. La commande suivante permet de le vérifier :

$ sudo tcpdump "port 21" -vvv

Plutôt attentif à la sécurité et étant sous Debian stable, je suis surpris de constater que TLS/SSL n'est pas activé par défaut. Le client lourd gFTP non plus ne permet pas de se connecter avec TLS/SSL ("le support SSL n'a pas été activé lors de la compilation"), pas plus que konqueror (il ne reconnaît pas le protocole ftps) ni même Firefox.

Des clients graphiques que j'ai pu tester, le seul à avoir le support de TLS/SSL pour FTP est FileZilla.

Bref, si vous faites du développement web, vous voilà avertis : n'utilisez pas l'explorateur de fichiers pour vous connecter, vérifiez que le client que vous utilisez chiffre bien la connexion.

Et si quelqu'un a une astuce pour ajouter le support TLS/SSL au backend FTP de gvfs, je suis preneur!

  • # mauvais protocole ?

    Posté par . Évalué à 8 (+9/-2).

    De mémoire, le FTPS est un hack au dessus du FTP. Et donc n'a jamais été vraiment bien supporté. On lui préfère plutôt le SFTP qui encapsule le FTP dans du SSH.

    Par contre, dans ton cas, est-ce que ce ne serait pas que les clients font du FTP explicite et que ton serveur ne supporte pas cette méthode ?

    • [^] # Re: mauvais protocole ?

      Posté par . Évalué à 9 (+7/-0).

      Le problème du FTPS c'est qu'il passe très mal les firewalls. Pour faire du suivi de session sur FTP, le firewall va écouter le flux de commande(port 21) pour intercepter le ou les port des flux data et ouvrir ce flux à la volée dans sa table de session. Du coup, si on chiffre la connexion, cela ne marche plus. Il faut donc configurer tout ça de façon plus ou moins statique, cela marche quand tu maitrise bien le coté client et le coté serveur, mais sinon …

      Faut pas gonfler Gérard Lambert quand il répare sa mobylette.

    • [^] # Re: mauvais protocole ?

      Posté par . Évalué à 1 (+1/-0).

      Dans ce cas, ce serait l'inverse. Le serveur accepte le FTP explicite (sur le port 21) mais pas le FTP implicite. Et les clients FTP ne semblent pas accepter le FTP "implicite" (qui serait le protocole ftps:// a priori).

      Et sinon, je préfère aussi le SFTP. Seulement, j'ai l'impression que la majorité des hébergeurs web proposent un accès FTP(s) par défaut, que l'accès SSH/SFTP est plus rare.

    • [^] # Re: mauvais protocole ?

      Posté par (page perso) . Évalué à 10 (+33/-1).

      On lui préfère plutôt le SFTP qui encapsule le FTP dans du SSH.

      Pas vraiment, même si le nom le suggère à tort. SFTP, c'est le SSH file transfer protocol. Dans ce nom, FTP fait référence au rôle de transfert de fichiers et non au vieux protocole FTP. Ce n'est en aucun cas du FTP sur SSH, ce qui passe dans SSH n'ayant pas grand chose à voir avec du FTP, à part le fait de concerner des fichiers.

      Contrairement à FTP, et contrairement à ce que son nom suggère, SFTP n'est pas un protocole de transfert de fichiers, en tout cas pas seulement : c'est en fait conçu comme un système de fichiers réseau, qui permet certes de transférer des fichiers, mais également d'en ouvrir en lecture, en écriture, de se positionner dedans, et toutes sortes d'opération qui relèvent vraiment du rôle d'un système de fichiers.

      Du coup, contrairement à FTP, un service SFTP peut par exemple être monté dans une arborescence sans trop de bidouilles. C'est possible aussi avec FTP, mais dans ce cas, ça relève justement de la bidouille, du hack, parce qu'il faut émuler des opérations qui ne sont pas du tout possible avec un simple protocole de transfert de fichiers.

      • [^] # Re: mauvais protocole ?

        Posté par . Évalué à 6 (+6/-1). Dernière modification le 12/07/17 à 10:38.

        Et boum ! Plein mes mirettes. Moi qui croyait bêtement que sftp c'était du ftp over ssh, je me prends un commentaire bien écrit, didactique et qui passe "crème" comme dise les djeunz.
        Merci M'sieur Ortolo, ça fait plaisir.

      • [^] # Re: mauvais protocole ?

        Posté par (page perso) . Évalué à 1 (+0/-1). Dernière modification le 12/07/17 à 11:50.

        Du coup, contrairement à FTP, un service SFTP peut par exemple être monté dans une arborescence sans trop de bidouilles.

        Juste par curiosité quelles sont les opérations non supportées par ftp pour un montage ? Cela fait plus de 25 ans que c'est pratiqué, je suis un peu dubitatif. Le système de montage est suffisamment souple pour supporter des systèmes de fichiers très différents, par exemple ISO 9660, FAT qui ne possèdent pas toute la sémantique posix. Pourtant, ce n'est pas des bidouilles.

        Qu'est-ce qui fait la différence avec ceux-ci ? N'est-ce pas plutôt que la chose n'intéresse plus grand monde et que les implémentation ne sont pas très abouties ?

        • [^] # Re: mauvais protocole ?

          Posté par (page perso) . Évalué à 5 (+3/-1).

          par exemple ISO 9660, FAT qui ne possèdent pas toute la sémantique posix. Pourtant, ce n'est pas des bidouilles.

          Le fait de devoir simuler une appartenance et des permission à un filesystem qui n'en a pas, c'est clairement des bidouilles.

          « Rappelez-vous toujours que si la Gestapo avait les moyens de vous faire parler, les politiciens ont, eux, les moyens de vous faire taire. » Coluche

          • [^] # Re: mauvais protocole ?

            Posté par (page perso) . Évalué à 3 (+2/-1). Dernière modification le 12/07/17 à 12:40.

            Je ne vois pas cela comme une bidouille. Le noyau fourni une abstraction basée qui décrit ce qu'il attend pour un système de fichier. Mais ces exigences ne sont pas des exigences dures. Cela est fait justement parce que tous les systèmes de fichiers ne supportent pas la même sémantique.

            • ISO 9660 est fait pour de la lecture seule
            • FAT est très simple et historique (locks?, droits?, …)

            FTP est fait initialement pour traiter des fichiers en entier de façon séquentielle à travers le réseau. Mais il permet aussi via les commandes APPEND, (REST, ABOR) de faire respectivement des appends et des seeks. Si on reste dans ce que FTP permet nativement, on a un montage relativement correct. Il y a potentiellement des choses non implémentées/non implémentables mais cela reste dans le range de qui est fait pour d'autres FS issus d'autres OS ou d'autres proto. réseau.

            J'ai des grandes difficultés à considérer cela un hack. L'abstraction faite par le noyau/fuse est faite pour cela : une implémentation partielle de primitives. On le sait dés le début qu'on n'aura pas une abstraction qui regroupe toutes les sémantiques de tous les OS, tous les protocoles. Certaines méthodes d'accès sont plus proches de la sémantique posix donc c'est plus simple pour eux. Mais en FAT et FTP, j'ai quand même du mal à voir qui est le plus loin de posix… Pourtant, personne, il me semble, ne qualifierait l'abstraction de FAT comme un Hack.

        • [^] # Re: mauvais protocole ?

          Posté par . Évalué à 6 (+5/-1).

          Par exemple, si tu as un programme qui ouvre un fichier en écriture, se place à l'offset 1730, change 5 octets puis ferme le fichier, la couche d'abstraction au-dessus de FTP doit télécharger tout le fichier (avant de rendre la main au programme!), et une fois l'enregistrement fait il doit renvoyer le fichier.
          Et faire un lock sur un fichier ne fonctionne probablement pas (la couche d'abstraction le simule peut-être en local, mais ça n'a aucune incidence sur le serveur distant).

          Il faut plutôt voit ça comme un moyen de transférer les fichiers sans devoir utiliser un client spécifique, mais pas comme un espace dans lequel on peut travailler directement (ce que des vrai systèmes de fichier réseau permettent).

          • [^] # Re: mauvais protocole ?

            Posté par (page perso) . Évalué à 2 (+0/-0). Dernière modification le 15/07/17 à 16:02.

            Euh non pas du tout. J'ai cité la commande rest (pour restore) dans le post, juste au-dessus du tiens. Cette commande permet de recommencer exactement où tu le souhaites.

            Pour ce qui est des locks c'est le cas pour d'autres (en réseau ou pas). Même NFS qui est quand même très "standard" à une sémantique non POSIX pour les locks.

            • [^] # Re: mauvais protocole ?

              Posté par (page perso) . Évalué à 3 (+2/-1).

              Ça ne change rien au débat : à ma connaissance, REST ne fonctionne que pour le téléchargement, et n'est pas obligatoirement géré (je n'ai pas d'exemple de serveur FTP qui ne le gère pas).

              • [^] # Re: mauvais protocole ?

                Posté par (page perso) . Évalué à 1 (+0/-1). Dernière modification le 15/07/17 à 23:17.

                REST ne fonctionne que pour le téléchargement,

                Du RFC :

                5.5.  REST Example
                
                   Assume that the transfer of a largish file has previously been
                   interrupted after 802816 octets had been received, that the previous
                   transfer was with TYPE=I, and that it has been verified that the file
                   on the server has not since changed.
                
                      C> TYPE I
                      S> 200 Type set to I.
                      C> PORT 127,0,0,1,15,107
                      S> 200 PORT command successful.
                      C> REST 802816
                      S> 350 Restarting at 802816. Send STORE or RETRIEVE
                      C> RETR cap60.pl198.tar
                      S> 150 Opening BINARY mode data connection
                      [...]
                      S> 226 Transfer complete.
                

                A noter particulièrement la ligne et le mot clef STORE.

                S> 350 Restarting at 802816. Send STORE or RETRIEVE

                (je n'ai pas d'exemple de serveur FTP qui ne le gère pas).

                Tout est dit.

                • [^] # Re: mauvais protocole ?

                  Posté par (page perso) . Évalué à 1 (+1/-2).

                  Ça ne change rien au débat : à ma connaissance,

                  Je ne vois pas vraiment de débat. Je souhaite des précisions. J'aimerais connaître les raisons que cela est plus un hack que d'autres montages supportés.

                  Est-ce que cela veut dire que peu importe l'énormité des erreurs commises la vérité absolue a été dite ?

                  Est-ce vraiment difficile d'ouvrir un RFC avant de dire des énormités ?

                  Bref, je ne sais toujours pas ce qui est un hack.

                • [^] # Re: mauvais protocole ?

                  Posté par (page perso) . Évalué à 2 (+1/-1).

                  and that it has been verified that the file on the server has not since changed.

                  Ça me semble être une limitation inutile, mais ça met par terre une (bonne ?) partie de l'utilité de REST.

                  • [^] # Re: mauvais protocole ?

                    Posté par (page perso) . Évalué à 2 (+2/-2).

                    Ce n'est pas ma question. Cela ne m'intéresse pas de discuter du protocole ftp en long et en large hors de ma question, ni du pourquoi de cette remarque dans un exemple. La raison est évidente. Mais cela implique de réfléchir 5 minutes, de penser en terme d'un transfert de fichier entier cohérent (le but de l'exemple) et de se rendre compte que c'est la même chose pour n'importe quel protocole dont la connexion a été rompue.

                    Je ne pense pas que j'aurai une réponse autre que des élucubrations.

                  • [^] # Re: mauvais protocole ?

                    Posté par . Évalué à 5 (+2/-0). Dernière modification le 17/07/17 à 02:25.

                    Une limitation inutile ? o_O

                    Au contraire, si cette vérification n’était pas faite, le client pourrait se retrouver avec un fichier différent de celui sur le serveur, qui sera très probablement un fichier corrompu.

                    Un protocole qui permettrait cela ne sera pas tellement utile, en tous cas comme protocole de transfert de fichiers généraliste.

  • # curlftpfs

    Posté par . Évalué à 5 (+2/-0).

    Des outils de montage comme http://curlftpfs.sourceforge.net/ devraient faire le job, non ?

    Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

    • [^] # Re: curlftpfs

      Posté par . Évalué à 6 (+4/-0).

      La concomitance temporelle entre ce post et celui de Tanguy< ici m'amuse :)

      • [^] # Re: curlftpfs

        Posté par . Évalué à 4 (+1/-0).

        Il a tout a fait raison, je ne dis pas que c'est pas du hack, juste que ça peut être une solution.

        Tous les contenus que j'écris ici sont sous licence CC0 (j'abandonne autant que possible mes droits d'auteur sur mes écrits)

  • # GNOME - nautilus

    Posté par (page perso) . Évalué à 0 (+0/-0).

    Et si quelqu'un a une astuce pour ajouter le support TLS/SSL au backend FTP de gvfs, je suis preneur!

    ftps://

    https://bugzilla.gnome.org/show_bug.cgi?id=526582
    ça a pris "quelques" années mais c'est supporté

    • [^] # Re: GNOME - nautilus

      Posté par . Évalué à 1 (+1/-0).

      En effet. Pourquoi ça ne marche pas chez moi ?
      Malgré mes différents tests, je n'ai pas réussi à le faire fonctionner la semaine dernière.

      (quelques nouveaux tests plus tard)

      Maintenant, c'est bon. Avec Nautilus (et PCManFM-Qt, et toutes les applications qui dépendent de gvfs), gvfs-mount se comporte correctement.
      Le seul truc (qui explique peut-être pourquoi je n'avais pas réussi), c'est que PCManFM-Qt ne propose, pour se connecter à un serveur distant, que SSH/FTP (en clair)/WebDAV/Secure WebDAV /HTTP/HTTPS. Mais pas FTPS. Si on sélectionne "FTP", ça envoie en clair, même si le serveur distant propose TLS/SSL, et pas moyen d'indiquer ftps://server/ comme adresse de serveur distant. Par contre, en faisant clic droit sur l'emplacement actuel, puis "Edit path" et en indiquant ftps://server/, là ça fonctionne. Ça propose de valider à la main le certificat s'il n'est pas valide.

      Par contre, ça ne marche pas avec konqueror, ni avec gFTP. Et cette modification dans gvfs semble avoir été ajoutée dans gvfs 1.24, donc cette fonctionnalité n'est pas dans Jessie (qui est de toutes façons oldstable aujourd'hui).

      Bref, ce que je dis dans le journal est faux. Il y aurait moyen de l'éditer ? (sinon, je peux juste l'inutiler …).

Envoyer un commentaire

Suivre le flux des commentaires

Note : les commentaires appartiennent à ceux qui les ont postés. Nous n'en sommes pas responsables.