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" -vvvPlutô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 Ambroise . É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 Big Pete . É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 Samuel (site web personnel) . É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 🚲 Tanguy Ortolo (site web personnel) . Évalué à 10.
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 RoyalPanda . Évalué à 6. Dernière modification le 12 juillet 2017 à 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 Anonyme . Évalué à 1. Dernière modification le 12 juillet 2017 à 11:50.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: mauvais protocole ?
Posté par claudex . Évalué à 5.
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 Anonyme . Évalué à 3. Dernière modification le 12 juillet 2017 à 12:40.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: mauvais protocole ?
Posté par wismerhill . É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 Anonyme . Évalué à 2. Dernière modification le 15 juillet 2017 à 16:02.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: mauvais protocole ?
Posté par Kerro . É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 Anonyme . Évalué à 1. Dernière modification le 15 juillet 2017 à 23:17.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 1.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: mauvais protocole ?
Posté par Kerro . Évalué à 2.
Ça me semble être une limitation inutile, mais ça met par terre une (bonne ?) partie de l'utilité de REST.
[^] # Commentaire supprimé
Posté par Anonyme . Évalué à 2.
Ce commentaire a été supprimé par l’équipe de modération.
[^] # Re: mauvais protocole ?
Posté par Marotte ⛧ . Évalué à 5. Dernière modification le 17 juillet 2017 à 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 barmic . É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 oinkoink_daotter . Évalué à 6.
La concomitance temporelle entre ce post et celui de Tanguy< ici m'amuse :)
[^] # Re: curlftpfs
Posté par barmic . É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)
[^] # Re: curlftpfs
Posté par Pol' uX (site web personnel) . Évalué à 5.
Ou pas. Perso j'ai passé 1/2 journée à essayer de comprendre pourquoi curlftpfs ne fonctionnais pas ; sur un cas d'usage de base : un fopen en mode "ab".
J'ai découvert n'avoir pas été seul :
Depuis je suis passé à autre chose. :)
Adhérer à l'April, ça vous tente ?
# GNOME - nautilus
Posté par Pierre Tramo (site web personnel) . Évalué à 0.
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 Samuel (site web personnel) . É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 à celles et ceux qui les ont postés. Nous n’en sommes pas responsables.