FTP pas sécurisé ?!

L'auteur de ce sujet a trouvé une solution à son problème.
Auteur du sujet

Bonjour,
Sur ce cours: https://openclassrooms.com/courses/reprenez-le-controle-a-l-aide-de-linux/transferer-des-fichiers
j'apprends que… le protocole ftp n'est pas sécurisé ?
Ça veut dire que si je fais par exemple "ftp ftp.monserveur.com" et qu'il me demande login/mot de passe, ça ne sera pas crypté ?!
Plus loin, il dit qu'on peut utiliser le sftp, mais que peu d'hébergeurs l'utilisent. Donc si l'hébergeur n'a ni ssh ni sftp, les données sont condamnées à ne pas être cryptées ?!
Ou alors j'ai manqué quelque chose, parce qu'à mon avis, c'est forcément sécurisé…
Vous confirmez ce que je dis ? Merci d'avance.

+0 -0
Staff

les communications ftp ne sont effectivement pas chiffrés, si tu n'a pas ssh ou sftp effectivement tout va transiter en clair. Cependant ça ne concerne que le transport, les données peuvent être chiffrés indépendamment pour le stockage sur le serveur.

+0 -0

FTP est comme telnet, il transmet les informations (dont les logins) en clair. Une personne écoutant ton réseau peut récupérer tes logins. Pour ajouter la confidentialité, tu dois utiliser SFTP (qui utilise un tunnel ssh pour sécuriser la connexion) ou FTPS.

Comme l'a dit Kje, tu peux chiffrer toi même tes données (ce que tu peux faire aussi avant d'envoyer des fichiers sur des stockage de cloud privée, style dropbox, pour éviter qu'on te les vole par exemple).

Édité par Nicox11

+0 -0
Auteur du sujet

Ah. Mais alors, le programme FileZilla communique -t- il en FTP ?
Si oui, ça veut dire que si quelqu'un écoutait mon réseau, il a maintenant mes logins et passwords…
Aussi, pour les hébergeurs qui ne proposent ni sftp, ni ssh, comme ceci:
Pas de ssh/sftp
Comment faire ? Si je chiffre login et mot de passe, le serveur ne saura pas déchiffrer…

Édité par Random Coder 99

+0 -0

Tu peux utiliser FTPS qui utilise SSL. FileZilla doit communiquer de base en FTP mais tu dois pouvoir le régler.

Si quelqu'un écoute ton réseau il a effectivement tes logins. Ça pourrait être judicieux de les changer.

+0 -0

Filezilla peut transférer des fichiers en FTP, FTPS et SFTP. IL sufit d'indiquer les bons paramètres de connexion.

Ce que tu dis est tout à fait juste, en FTP tout circule en clair.

Je trouve effectivement très curieux que la variante chiffrée de FTP, soit donc FTPS, soit extrêmement peu populaire, alors que HTTPS est aujourd'hui une évidence. Pourtant ce n'est techniquement pas plus compliqué à mettre en place !

Par contre il existe une subtilité, on peut passer en mode chiffré depuis une connexion en clair avec la commande starttls, avant même d'envoyer son login/pass. Si tu as vu le protocole SMTP, c'est exactement le même principe. Il vaut donc la peine de paramétrer filezilla pour qu'il le tente à chaque connexion; si le serveur le supporte, la communication peut passer en chiffré et donc personne ne pourra voir tes identifiants. Sauf erreur, tu peux aussi le configurer en mode parano, c.à.d. refuser d'aller plus loin si le serveur ne supporte pas starttls.

Ma plateforme avec 23 jeux de société classiques en 6 langues et 13000 joueurs: http://qcsalon.net/ | Apprenez à faire des sites web accessibles http://www.openweb.eu.org/

+0 -0
Staff

Ça n'a rien de surprenant. En fait c'est même plutôt rassurant.

FTP est un protocole de transfert de fichiers, c'est son métier : il a été pensé pour administrer un système de fichiers distant, et il fait ça très bien depuis des décennies. À l'opposé, le métier de TLS/SSL est de chiffrer les communications. Il est donc plutôt rassurant de constater que les deux protocoles ont été pensés pour être à la fois spécialisés, et compatibles entre eux.

Sans ça, imagine le bordel si HTTP, FTP, RTP, IRC, etc. devaient tous gérer leur façon propre de chiffrer les communications : les protocoles deviendraient tous 2 fois plus gros que nécessaire, et on ne s'y retrouverait plus.

Édité par nohar

I was a llama before it was cool

+1 -0

Bah justement, FTPS est exactement à FTP ce que HTTPS est à HTTP. D'un côté comme de l'autre on utilise SSL/TLS comme une surcouche totalement indépendante exactement de la même façon. C'est pour ça que je me demande pourquoi FTPS n'a pas vraiment pris, contrairement à HTTPS.

C'est SSH et donc SFTP qui est complètement différent et qui n'utilise pas du tout SSL/TLS; mais c'est le seul il me semble. Tous les autres protocoles -S se basent sur SSL/TLS: HTTPS, FTPS, IMAP-S, POP-S, IRC-S, …

Ma plateforme avec 23 jeux de société classiques en 6 langues et 13000 joueurs: http://qcsalon.net/ | Apprenez à faire des sites web accessibles http://www.openweb.eu.org/

+0 -0

@nohar : Je trouve que tu propose une vision un peu trop idéalisée des choses…

Il est donc plutôt rassurant de constater que les deux protocoles ont été pensés pour être à la fois spécialisés, et compatibles entre eux.

FTP date de 1971 et il est notoire que la sécurité n'était pas vraiment une préoccupation à l'époque (le terme "security" n’apparaît pas une seule fois dans les premières RFCs, ce qui est assez révélateur en soi). D'ailleurs, SSL n'existait pas à l'époque, et n'est apparu que beaucoup plus tard.

Et, sans un être un spécialiste du sujet, la compatibilité ne semble pas particulièrement à l'honneur, il suffit de voir qu'il a fallu ajouter le support de la sécurité au protocole FTP explicitement dans FTPS, et que SFTP a été développé en parallèle. (je n'en connais pas les raisons, mais c'est quand même un symptôme).

@QuentinC : Justement non, HTTPS n'est pas totalement comparable à FTPS (du moins la version explicite décrite par l'IETF). HTTPS est simplement constitué d'une couche SSL/TLS en dessous du protocole. Alors que FTPS (ainsi que POPS et IMAPS d'ailleurs) sont bel et bien des extensions au protocole, pour pouvoir garder le service sur le même port et par souci de compatibilité avec les clients (plus de détails dans la RFC 2595 section 7).

Édité par yoch

+1 -0

Justement non, HTTPS n'est pas totalement comparable à FTPS (du moins la version explicite décrite par l'IETF). HTTPS est simplement constitué d'une couche SSL/TLS en dessous du protocole. Alors que FTPS (ainsi que POPS et IMAPS d'ailleurs) sont bel et bien des extensions au protocole, pour pouvoir garder le service sur le même port et par souci de compatibilité avec les clients

En fait, il y a deux versions. La version implicite est bien en tout point comparable à HTTPS. ET c'est cette version implicite que je me demandais pourquoi elle n'a pas eu un succès comparable à HTTPS.

Entre temps j'ai trouvé la réponse, il semblerait que ce soit surtout une question de firewall. On conseille visiblement la version explicite pour pouvoir garder les ports standards historiques (20 et 21 pour FTP), qui ont nettement plus de chance de passer.

C'est la version explicite, celle que j'ai appelée starttls, qui a ajouté des commandes pour gérer le chiffrement à postériori. Après une recherche rapide, la commande ne s'appelle pas starttls dans le cadre de FTP mais c'est pas grave, l'idée était la même. Pour POP et IMAP, il existe de la même manière une version implicite et une version explicite, et on recommande pareillement les versions explicites à cause des firewalls.

ON a donc les deux raison, je faisais allusion à la version implicite et toi à la version explicite, et je pensais à tort que FTPS faisait référence uniquement à la version implicite.

Ma plateforme avec 23 jeux de société classiques en 6 langues et 13000 joueurs: http://qcsalon.net/ | Apprenez à faire des sites web accessibles http://www.openweb.eu.org/

+0 -0
Staff

Je me suis mal exprimé. Les protocoles n'ont pas été explicitement pensés pour être compatibles entre eux, mais chaque protocole est pensé à l'origine pour faire un boulot et un seul, donc un bon protocole doit être par définition stackable. Ce qui les rend non mutuellement exclusifs (compatibles, quoi), c'est le formalisme par couches des modèles comme OSI.

Édité par nohar

I was a llama before it was cool

+0 -0
Vous devez être connecté pour pouvoir poster un message.
Connexion

Pas encore inscrit ?

Créez un compte en une minute pour profiter pleinement de toutes les fonctionnalités de Zeste de Savoir. Ici, tout est gratuit et sans publicité.
Créer un compte