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

Posté par . Licence CC by-sa
3
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.

    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.

      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.

      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.

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

      • [^] # Commentaire supprimé

        Posté par . Évalué à 1. Dernière modification le 12/07/17 à 11:50.

        Ce commentaire a été supprimé par l'équipe de modération.

        • [^] # Re: mauvais protocole ?

          Posté par (page perso) . Évalué à 5.

          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

          • [^] # Commentaire supprimé

            Posté par . Évalué à 3. Dernière modification le 12/07/17 à 12:40.

            Ce commentaire a été supprimé par l'équipe de modération.

        • [^] # Re: mauvais protocole ?

          Posté par . Évalué à 6.

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

          • [^] # Commentaire supprimé

            Posté par . Évalué à 2. Dernière modification le 15/07/17 à 16:02.

            Ce commentaire a été supprimé par l'équipe de modération.

            • [^] # Re: mauvais protocole ?

              Posté par (page perso) . Évalué à 3.

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

              • [^] # Commentaire supprimé

                Posté par . Évalué à 1. Dernière modification le 15/07/17 à 23:17.

                Ce commentaire a été supprimé par l'équipe de modération.

                • [^] # Commentaire supprimé

                  Posté par . Évalué à 1.

                  Ce commentaire a été supprimé par l'équipe de modération.

                • [^] # Re: mauvais protocole ?

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

                  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.

                  • [^] # Commentaire supprimé

                    Posté par . Évalué à 2.

                    Ce commentaire a été supprimé par l'équipe de modération.

                  • [^] # Re: mauvais protocole ?

                    Posté par . Évalué à 5. 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.

    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.

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

      • [^] # Re: curlftpfs

        Posté par . Évalué à 4.

        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.

    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.

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

Suivre le flux des commentaires

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