Discussion :

[Christian Olivier]

Les développeurs de Chrome et Firefox envisagent de supprimer le support de FTP sur leur navigateur respectif
Pour des raisons de sécurité

Il semble que, depuis plus de 4 ans, les développeurs Google plaident pour la suppression du support de FTP dans Chrome en raison notamment de sa faible utilisation. À ce propos, ils ont déclaré dans un rapport de bogues datant de 2014 :

« Nous devrions envisager de supprimer la prise en charge intégrée de FTP dans Chrome et de la transférer vers une application […] sur une période de sept jours, seuls 0,1 à 2 % des utilisateurs accèdent à une URL FTP quelconque (avec des chiffres légèrement supérieurs parmi les utilisateurs de postes de travail Linux) ».

Ils déplorent également le fait que la prise en charge de FTP sur Chrome ajoute une surface d’attaque supplémentaire sur le navigateur de la firme de Mountain View et demeure moins sécurisée qu’une connexion HTTPS :

« FTP est un protocole hérité non sécurisable. Nous avons le support du protocole FTP WONTFIXed sur iOS, mais son utilisation dans Chrome qui est basé sur Blink est suffisamment élevée pour qu’il semble difficile de tout supprimer en même temps ».

À l’heure actuelle, lorsqu’un utilisateur ouvre un fichier enregistré sur un serveur FTP par le biais du navigateur de Google, Chrome tente de restituer ce fichier (image, son, ou autre) directement sur le navigateur.

Les développeurs de Google ont l’intention de modifier Chrome afin qu’à l’avenir, il évite de restituer les fichiers accessibles via « une URL ftp:// » directement sur le navigateur. Ils voudraient plutôt que l’ouverture d’une URL ftp:// conduise au téléchargement du ou des fichiers cibles. Toutefois, Chrome devrait continuer à afficher les index de répertoire FTP.

D’après les développeurs de la filiale d’Alphabet : « Cela semble être un moyen raisonnable de réduire sa viabilité en tant que surface d’attaque, en tant que tremplin en lieu et place d’une élimination complète ».

Les développeurs de Chrome ne sont pas les seuls à vouloir supprimer la prise en charge FTP sur leur navigateur. Mozilla aussi nourrirait les mêmes ambitions de son côté. L’éditeur de Firefox a confirmé il y a cinq mois de cela, dans un ticket ouvert sur Bugzilla il y a plus de 18 ans, qu’il envisage à terme de supprimer également la prise en charge de FTP sur Firefox.

Il y a fort à parier que si Chrome et Firefox décident tous deux de supprimer le support du protocole FTP de leurs navigateurs respectifs, d’autres éditeurs de navigateurs concurrents s’engageront très probablement sur la même voie afin de réduire la complexité de leur code de base et de supprimer les fonctionnalités rarement utilisées.

Source : Google, Bleeping Computer

Et vous ?

Qu’en pensez-vous ?

Voir aussi

Firefox : le chargement de ressources FTP dans une page Web ne sera plus autorisé le protocole FTP ne supportant pas le chiffrement moderne
Google pince à nouveau les responsables Web : l'accès aux ressources via FTP sera marqué comme non sécurisé sous Chrome 63
Selon Troy Hunt, le protocole HTTPS a atteint son point critique et deviendra bientôt la norme du web plutôt que l'exception sur la toile
Google donne des précisions sur le déploiement HTTPS sur ses produits et services et fait une liste des pays qui s'en servent le plus

[Steinvikel]

Le support de FTP peut-il être apporté via les extensions ?
Ça permettrait de réduire les problèmes des deux parties : ceux qui développent le navigateurs, et ceux qui utilisent FTP.

[Jarodd]

N'imp'. Je récupère régulièrement des extensions et des packs de langue sur le FTP de... Mozilla, je n'ai pas besoin de sécurité pour cela. Et puis je peux toujours vérifier son empreinte si j'ai un doute sur son intégrité.

[Mulongo Emmanuel]

Bonjour à tous, je trouve que la sécurité dépends plus de l'user que du navigateur quand on trouve qu'un truc est pas bon, suffit de le désactiver

[Steinvikel]

Si l'utilisateur est un élément prédominant dans les facteurs de sécurité, ce n'est pas le seul.
On peut évidemment recevoir un colis piégé dans un tunnel sécurisé, mais le faire dans un tunnel non sécurisé, est encore pire.

La question que je me pose, c'est quels sont les fonctionnalités fondamentalement différentes entre un échange de données FTP et la même opération par HTTP(s), ainsi que la différence de performance.
N'y a t'il pas moyen d'encapsuler un flux FTP dans du TLS ?

[tes49]

Salut

Dans certains cas autant utiliser un logiciel client de FTP et cela sera donc possible d'utiliser ce protocole, encore pour un bon bout de temps...
Logiciels clients de FTP

Dans une autre situation le FTP à déjà été évoqué... et ma réponse était... https://www.developpez.net/forums/d1...plus-autorise/

Chose qui est certaine, c'est qu'à moyen terme, toutes connexions non-sécurisés vont venir à disparaitre, donc autant commencer à changer ses habitudes !

[zecreator]

Le FTP est un protocole préhistorique et je suis étonné que l'on puisse encore l'utiliser pour l'échange de données sensibles. Il est restrictif, poussif et n'apporte aucune sécurité (même en FTPS). Perso, pour de la manipulation de fichiers à distance, je passe par SSH (PuffY), et pour du partage de fichiers tiers à tiers, je passe par des services sécurisés de stockage de fichiers comme Tresorit ou SecurySafe si je n'ai pas d'autres choix.

Souvent, ceux sont mes clients qui m'imposent leur système de partage, et s'ils me parlent de FTP, je refuse tout net. J'ai plus confiance en ce protocole depuis des années.

Franchement du FTP à travers le navigateur web ? J'ai toujours trouvé cette idée farfelue. Et le fait que cela apporte un coté pratique à certain, le rend encore plus dangereux.

[Steinvikel]

je suppose que pour l'usage de SSH tu voulais parler de Putty, et non de Puffy... et par TCPS, tu voulais dire STCP (SSH TCP) ?

Je ne comprends pas ce que tu veux dire. Il est ici question de protocole : le TCP, et tu exposes des alternatives logicielles, qui pour certaines utilisent également TCP.
SSH permet aussi l'usage de TCP, mais en l'encapsulant.

Est-ce que c'est TCP lui même qui te rebute, ou bien la manière dont il est employé ?

[Olivier Famien]

Google annonce qu’il rendra le support FTP dans Chrome obsolète et procédera à sa suppression définitive
à partir de Chrome 82 qui sera disponible en 2020

Depuis un bout de temps, les éditeurs de navigateurs, notamment ceux de Chrome et Firefox, plaident en faveur de l’élimination pure et simple du support du protocole de transfert de fichier (FTP en anglais) dans leur navigateur respectif. Utilisé par les internautes, le protocole FTP est généralement sollicité sur la toile pour récupérer ou partager des fichiers à distance. En principe, de nombreux logiciels sont disponibles en tant que clients FTP et permettent d’effectuer les mêmes actions comme envoyer ou récupérer des fichiers via ce protocole. Toutefois, certains utilisateurs qui ne souhaitent pas s’embarrasser de l’installation d’un client autonome FTP préfèrent continuer à recourir au navigateur pour récupérer des données sur un serveur FTP. Pour ce faire, une simple saisie de la syntaxe « FTP://adresse_du_serveur » permet d’afficher dans la page du navigateur l’arborescence des fichiers contenus sur le serveur FTP si l’adresse saisie est correcte.

Mais pour les mainteneurs de Chrome, ce protocole pose des problèmes de sécurité, car les fichiers sont envoyés en clair sur le réseau. Ainsi, depuis plusieurs années, la firme de Mountain View est engagée dans une politique de délestage des fonctionnalités de l’implémentation FTP dans Chrome. À partir de Chrome 74+, un bug a conduit Google à supprimer le support de l’accès aux URL FTP via des serveurs proxy HTTP. Et avec Chrome 76, la prise en charge du proxy pour FTP a été entièrement supprimée. Dans les versions récentes de Chrome, le navigateur ne prend en charge ni les connexions chiffrées ni les proxys. Il convient également de préciser que Google a déjà procédé à la suppression de la prise en charge du rendu des ressources et de la récupération de sous-ressources via FTP. Les fonctionnalités restantes de la mise en œuvre FTP dans Google Chrome sont limitées à l’affichage d’une liste de répertoires ou au téléchargement d’une ressource via des connexions non chiffrées.

Au regard de tous ces efforts pour se débarrasser de FTP sur Chrome, de nombreux utilisateurs ont depuis longtemps tourné leurs regards vers les logiciels FTP, en tout cas pour ceux qui continuent toujours à utiliser ce protocole pour leur transfert de fichiers. Du côté de Google, les développeurs de Chrome relèvent que sur Chrome stable l’utilisation de FTP représente environ 0,1 % pour les utilisateurs Windows sur environ 7 jours. Sur toutes les plateformes, seul environ 0,01 % d’utilisateur a recours à ce protocole sur une période de 28 jours. Et pendant la même période de 28 jours, environ 0,03 % des utilisateurs de toutes les plateformes téléchargent quelque chose via FTP — ce qui est la seule chose que les utilisateurs peuvent faire avec les URL FTP, souligne Google.

Aussi, en raison de la faible utilisation de FTP dans Chrome, les développeurs du navigateur avancent maintenant qu’il n’est plus nécessaire d’investir dans le support du client FTP existant et vont par conséquent rendre obsolète et supprimer la prise en charge de FTP dans Chrome à travers les URL. À partir de Chrome 78, le support FTP sera désactivé dans les préversions et des contrôles de stratégie ainsi qu’un indicateur pour le contrôle du protocole FTP seront ajoutés. Dans Chrome 80, la désactivation progressive du support FTP commencera. Et à partir de Chrome 82, dont la publication est prévue pour le deuxième trimestre de 2020, tout le code et les ressources liées à FTP seront supprimés. Après cette étape, Chrome ne parviendra plus à traiter ou à reconnaitre les URL ftp://.

Toutefois, si un utilisateur tentait de saisir une URL FTP dans la barre d’adresse, le navigateur essaiera d’appeler le gestionnaire par défaut pour les URL ftp://, car des clients FTP plus performants sont déjà disponibles sur toutes les plateformes affectées.. Il sera dument tenu compte des situations dans lesquelles le navigateur est déjà le gestionnaire par défaut pour les URL ftp://, précise Google.

En outre, pour les utilisateurs qui récupèrent les scripts de Configuration Automatique de Proxy (PAC en anglais), dès que la prise en charge de FTP sera rendue obsolète, l’extraction des scripts PAC via FTP ne sera plus possible. Les utilisateurs devront migrer vers d’autres moyens pour récupérer les scripts PAC, avance Google. Enfin, pour les développeurs web qui seraient impactés par la suppression du support FTP, Google suggère comme alternative de se tourner vers les protocoles HTTP et HTTPS.

Source : Chrome, Chromium Forum

Et vous ?

Que pensez-vous de cette décision ?

Selon vous, Google a-t-il bien de supprimer le support FTP dans Chrome ?

À défaut du navigateur Chrome, quel client FTP utilisez-vous comme alternative ? Et pourquoi ?

Voir aussi

Google pince à nouveau les responsables Web : l'accès aux ressources via FTP sera marqué comme non sécurisé sous Chrome 63
Firefox : le chargement de ressources FTP dans une page Web ne sera plus autorisé le protocole FTP ne supportant pas le chiffrement moderne
Selon Troy Hunt, le protocole HTTPS a atteint son point critique et deviendra bientôt la norme du web plutôt que l'exception sur la toile
Google donne des précisions sur le déploiement HTTPS sur ses produits et services et fait une liste des pays qui s'en servent le plus

[Steinvikel]

Dans les versions récentes de Chrome, le navigateur ne prend en charge ni les connexions chiffrées ni les proxys. Il convient également de préciser que Google a déjà procédé à la suppression de la prise en charge du rendu des ressources et de la récupération de sous-ressources via FTP. Les fonctionnalités restantes de la mise en œuvre FTP dans Google Chrome sont limitées à l’affichage d’une liste de répertoires ou au téléchargement d’une ressource via des connexions non chiffrées.
...
Enfin, pour les développeurs web qui seraient impactés par la suppression du support FTP, Google suggère comme alternative de se tourner vers les protocoles HTTP et HTTPS.

...à lire l'article, le support de FTP et sa maintenance, requiert des ressources conséquentes et présente de grandes difficultés. Moi qui pensait que ce protocole était aussi vieux qu'internet. Ya que moi que ça fait tiquer de présenter FTP désuet car non sécurisé alors qu'il existe SFTP et FTPS depuis un certain temps maintenant ?

[B]Que pensez-vous de cette décision ?[\B]
Que c'est la première fois que j'entend Google énoncer que 0,01% des utilisateurs sur un total se comptant en milliard journalier représente un chiffre ridicule pour qualifier une fonctionnalité de "inutilisé".

[B]Selon vous, Google a-t-il bien (fait) de supprimer le support FTP dans Chrome ?[\B]
Non, encore moins en prétextant que ce protocole est non chiffré ...à croire que SFTP et FTPS n'existent pas. =,='

[B]À défaut du navigateur Chrome, quel client FTP utilisez-vous comme alternative ? Pourquoi ?[\B]
FileZilla, parce qu'il est développé tout spécialement pour cet usage (échanger des fichiers), et est un logiciel "libre", sous licence libre.

[sevyc64]

alors qu'il existe SFTP et FTPS depuis un certain temps maintenant ?

FTP n'est pas sécurisé. La notion de sécurité ne fait pas partie du protocole. Parler de ftp sécurisé en évoquant SFTP ou FTPS est un abus de langage. Ces 2 implémentations sont a différencier du protocole FTP car n'est faisant pas partie, et sont presque, même, à considérer comme des protocoles à part entière.

FTPS n'apporte rien en matière de sécurité, c'est comme mettre une peinture couleur chair sur une jambe de bois pour la faire passer pour une vrai jambe.

SFTP est un vrai protocole sécurisé sur le principe de FTP. Malheureusement, peu de serveurs l'implémentent, et d'ailleurs peu de clients le supporte.

Mais bon, il n'en faut qu'un client,le principal, Filezilla. Il supporte le FTP, le FXP, FTPS, SFTP, l'IPv6 (et oui, tous les clients ne sont pas forcément compatible IPv6, aussi bizarre et stupide que ça puisse paraitre), ....

[Steinvikel]

Parler de ftp sécurisé en évoquant SFTP ou FTPS est un abus de langage. Ces 2 implémentations sont a différencier du protocole FTP car n'est faisant pas partie, et sont presque, même, à considérer comme des protocoles à part entière.

Oui, j'assume totalement cet abus de langage.
Ce que je veux souligner (par ma citation du post précédent), c'est qu'il n'est fait mention que de FTP et que sans support de connexion chiffré pas de FTPS, et que comme il n'est jamais fait référence à SFTP, il est fort probable que le support soit abandonné pour tout ce qui touche de près ou de loin à FTP ...S ou pas S.

Ce que je ne sais pas c'est ce qu'apporte FTP comme avantages sur HTTP pour les échanges de fichiers. Je ne sais pas non plus si, aujourd'hui, un protocole le remplace intégralement (tout ses avantages), car rien d'autre que "vous devrez utiliser HTTPS" n'est proposé (en restant sur Chrome).

[sevyc64]

et que comme il n'est jamais fait référence à SFTP, il est fort probable que le support soit abandonné pour tout ce qui touche de près ou de loin à FTP ...S ou pas S.

Comme on parle ici de navigateur, je n'ai jamais fait le test, mais il est probable que, déjà actuellement, les navigateurs ne supporte pas le SFTP. Déjà que tous les clients FTP ne le supporte pas forcément ..

Ce que je ne sais pas c'est ce qu'apporte FTP comme avantages sur HTTP pour les échanges de fichiers.

Si c'est juste pour faire du download, pas grand chose. Même au contraire, http étant du web, tu peux avoir (et tu as normalement) une interface plus UserFriendly coté client.

Sur FTP, on est sur une gestion distante d'une arborescence de dossier et fichier, avec souvent une interface très basique, digne du premier gestionnaire de fichier de Windows 3.0. Mais l'échange peut être dans les 2 sens, download, upload, ajout, suppression, déplacement de fichiers, etc ...
Chose déjà moins courante en http, bien que certain logiciel serveur savent faire, comme par exemple HFS

[vanquish]

FTPS n'apporte rien en matière de sécurité, c'est comme mettre une peinture couleur chair sur une jambe de bois pour la faire passer pour une vrai jambe.

On sort du sujet, mais pouvez-vous développer ?
Il y a eu plusieurs mentions de ce type dans le fil, mais je ne comprend pas pourquoi.

Il y a chiffrement (et éventuellement authentification) par certificat dès l'envoi du login et mdp.
En quoi le protocole n'est-il pas sécurisé ?

J'ai essayé google, mais on tombe sur des articles qui restent très superficiels.

[sevyc64]

3 points principaux pour le FTPS :
Avec FTPS (tout comme HTTPS d'ailleurs) seule une partie de la communication est chiffré.
La connexion au serveur FTP se fait en clair, donc déjà les premières commandes passent en clair.
Ensuite, suivant l’implémentation ou la configuration du serveur, il est parfois nécessaire de s'être authentifié avant de pouvoir basculer en SSL, ce qui fait que login et mot de passe peuvent passer en clair malgré le "FTPS".

De plus FTPS fonctionne avec le protocole SSL (ou sa déclinaison TLS). La spécificité de ce protocole est qu'il n'y a aucun authentification, ni coté client, ni coté serveur. Pour faire simple, le client qui se connecte et reçoit le certificat n'a aucun moyen de savoir que c'est bien sur le serveur qu'il désire qu'il est connecté. De même le serveur qui reçoit la demande n'a aucun moyen de savoir qui est le client qui émet la demande et si c'est un client autorisé.

FTPS nécessite 2 connexions sous SSL puisque c'est le flux, une fois la connexion établie, qui est chiffré.
De plus, lorsque la connexion "COMMAND" n'est pas maintenue durant le transfert, il y a un système de reconnexion automatique, et donc à la reconnexion le chiffrage SSL est renégocié avec donc une partie de l'échange en clair au départ.


Concernant SFTP, déjà le protocole utilisé est SSH. Celui-ci est basé sur l'échange de clés privées/publiques. Le client doit présenter une clé propre au serveur, qu'il aura reçu préalablement d'une quelconque manière, mail, courrier, dongle, etc ....
Le serveur lui, même s'il ne connait pas plus le client, peut le considérer comme autorisé, puisqu'il présentera une clé propre au serveur qui aura du lui être fourni volontairement.
(certaines implémentations permettent de gérer plusieurs clés serveur et donc de fournir une clé serveur propre à chaque client).

De plus, avec SSH, le chiffrement ne se fait pas dans la session FTP, mais au niveau des machines elles-mêmes. C'est un tunnel chiffré qui est établi, une sorte de VPN. Ensuite la connexion au serveur FTP, ainsi que tout le trafic passe à travers ce tunnel.


En FTPS, tu peux, par exemple, avoir une attaque MIM avec un serveur pirate qui présente un certificat SSL authentique et qui se connecte lui-même en SSL (ou pas d'ailleurs) sur le serveur FTP de destination. Le client, ni le serveur de destination n'y verront rien, et le serveur pirate peut aspirer tout le trafic.
En SFTP, tu ne peux établir de connexion que sur le vrai serveur à qui appartient la clé que tu présente. Ayant une partie aléatoire dans cette clé, si un serveur pirate s'intercale, il est quasiment impossible qu'il puisse avoir la même clé que le serveur de destination, la connexion depuis le client ne pourra pas se faire. De plus aucune donnée, y compris d'authentification, sur le serveur FTP ne pourra être interceptée puisque le chiffrage SSH sera déjà en place au moment où elles transiteront.

En FTPS, comme HTTPS, le chiffrage est disponible à tout moment pour tout le monde sans distinction, mais sans garantie pour le client de se connecter au bon serveur. Seule une partie de l'échange est chiffré et pas forcément les éléments de d’authentification.
En SFTP, seul les clients autorisés pourront se connecter, à qui il aura d'abords fallu fournir la clé du serveur. Les clients sont sur de se connecter au bon serveur. La totalité de l'échange FTP est chiffrée.

[vanquish]

3 points principaux pour le FTPS :

Merci pour cette réponse détaillée.

[Stéphane le calme]

Google supprime le code du protocole de transfert de fichiers FTP du navigateur Chrome dans Chrome 95,
après avoir évoqué des problèmes de sécurité

Pendant des années, les éditeurs de navigateurs, notamment ceux de Chrome et Firefox, ont plaidé en faveur de l’élimination pure et simple du support du protocole de transfert de fichier (FTP en anglais) dans leur navigateur respectif. Utilisé par les internautes, le protocole FTP est généralement sollicité sur la toile pour récupérer ou partager des fichiers à distance. En principe, de nombreux logiciels sont disponibles en tant que clients FTP et permettent d’effectuer les mêmes actions comme envoyer ou récupérer des fichiers via ce protocole. Toutefois, certains utilisateurs qui ne souhaitent pas s’embarrasser de l’installation d’un client autonome FTP préfèrent continuer à recourir au navigateur pour récupérer des données sur un serveur FTP. Pour ce faire, une simple saisie de la syntaxe « FTP://adresse_du_serveur » permettait d’afficher dans la page du navigateur l’arborescence des fichiers contenus sur le serveur FTP si l’adresse saisie est correcte.

Mais pour les mainteneurs de Chrome, ce protocole pose des problèmes de sécurité, car les fichiers sont envoyés en clair sur le réseau. Raison pour laquelle Google s'est engagé dans une politique de délestage des fonctionnalités de l’implémentation FTP dans Chrome. Avec Chrome 74, un bogue a conduit Google à supprimer le support de l’accès aux URL FTP via des serveurs proxy HTTP. Avec Chrome 76, la prise en charge du proxy pour FTP a été entièrement supprimée. Dans des versions qui ont été publiées après, le navigateur ne prenait en charge ni les connexions chiffrées ni les proxys. Google avait déjà procédé à la suppression de la prise en charge du rendu des ressources et de la récupération de sous-ressources via FTP. Les fonctionnalités restantes de la mise en œuvre FTP dans Google Chrome étaient limitées à l’affichage d’une liste de répertoires ou au téléchargement d’une ressource via des connexions non chiffrées.

Avec Chrome 78, le support FTP a été désactivé dans les préversions et des contrôles de stratégie ainsi qu’un indicateur pour le contrôle du protocole FTP ont été ajoutés. Dans Chrome 80, la désactivation progressive du support FTP a commencé. Avec Chrome 82, tout le code et les ressources liées à FTP ont été supprimés. Depuis cette étape, Chrome ne parvient plus à traiter ou à reconnaitre les URL ftp://.

Suppression de la base de code

Cette fois-ci, l'équipe Chromium est passé à une autre étape : la prise en charge du protocole de transfert de fichiers (FTP) n'est pas seulement obsolète, mais supprimée de la base de code dans la dernière version stable du navigateur Chrome, la version 95.

Un manque de prise en charge des connexions chiffrées dans l'implémentation FTP de Chrome, associé à un désintérêt général de la majorité des utilisateurs du navigateur et à l'existence d'alternatives tierces plus performantes a provoqué cette situation.

Dans la version 88, il était désactivé pour tous les utilisateurs, mais pouvait toujours être réactivé. Maintenant, le code pour le supporter a enfin été supprimé une fois pour toutes, un peu plus tard que prévu.

« Les capacités restantes de la mise en œuvre FTP de Google Chrome sont limitées à l'affichage d'une liste de répertoires ou au téléchargement d'une ressource via des connexions non chiffrées. Nous aimerions déprécier et supprimer cette fonctionnalité restante plutôt que de maintenir une implémentation FTP non sécurisée », ont expliqué.

Mozilla a définitivement mis fin au support du protocole FTP avec la sortie de Firefox 90

Selon Mozilla, bien que ce protocole standard était pris en charge par tous les principaux navigateurs depuis sa création, il est aujourd'hui l'un des plus anciens protocoles encore utilisés et souffre par la même occasion d'un certain nombre de graves problèmes de sécurité. Dans un billet de blogue publié en juillet, la société a expliqué qu'il s'agit de l'une des raisons soutenant sa suppression de Firefox.

Le plus grand risque pour la sécurité est que le protocole FTP transfère les données en clair, ce qui permet aux cybercriminels de voler, d'usurper et même de modifier les données transmises. À ce jour, de nombreuses campagnes de distribution de logiciels malveillants lancent leurs attaques en compromettant des serveurs FTP et en téléchargeant des logiciels malveillants sur l'appareil d'un utilisateur final à l'aide du protocole FTP. En outre, la position de Mozilla est appuyée par plusieurs noms de l'industrie qui s'accordent à dire qu'à l'origine, le protocole FTP n'a pas été conçu pour être sécurisé.

Il est généralement considéré comme un protocole non sécurisé, car il repose sur des noms d'utilisateur et des mots de passe en clair pour l'authentification et n'utilise pas le chiffrement. Les données envoyées par FTP sont vulnérables aux attaques par reniflage, par usurpation et par force brute, entre autres méthodes d'attaque de base. Dans la pratique, il existe plusieurs approches communes pour relever ces défis et sécuriser l'utilisation de FTP. À titre d'exemple, le protocole FTPS (File Transfer Protocol Secure) est une extension/variante du protocole FTP qui permet de chiffrer les connexions à la demande du client.

Transport Layer Security (TLS), Secure Socket Layer (SSL) et SSH File Transfer Protocol (également connu sous le nom de Secure File Transfer Protocol ou SFTP) sont souvent utilisés comme des alternatives plus sûres à FTP, car ils utilisent des connexions chiffrées. Ainsi, le risque de sécurité élevé, la vieillesse du protocole et les alternatives existantes ont encouragé les fournisseurs de navigateurs tels que Google et Mozilla à abandonner sa prise en charge. Mozilla a confirmé son intention en mars 2020, environ un an après que Google a déclaré qu'il supprimera l'implémentation du protocole FTP de Chrome 82.

De son côté, Mozilla a désactivé en avril le protocole FTP par défaut dans Firefox 88 et Firefox 90, publié en juillet, ne prend plus en charge le protocole FTP. Mozilla explique si vous êtes un utilisateur de Firefox, vous n'avez rien à faire pour bénéficier de cette « avancée » en matière de sécurité. D'après le billet de blogue de Mozilla, lorsque Firefox effectuera automatiquement la mise à jour vers la version 90, les utilisateurs seront protégés contre toute attaque reposant sur le protocole non sécurisé FTP. Ces attaques sont désormais rendues inutiles puisque le protocole FTP n'est plus pris en charge.

« Conformément à notre intention de supprimer le protocole HTTP non sécurisé et d'augmenter le pourcentage de connexions sécurisées, nous avons décidé, comme d'autres grands navigateurs Web, de ne plus prendre en charge le protocole FTP. La suppression de FTP nous rapproche d'un Web plus sécurisé qui est en passe de devenir exclusivement HTTPS. Les mécanismes modernes de mise à niveau automatique tels que HSTS ou le mode HTTPS-Only de Firefox, mettant automatiquement à niveau toute connexion pour qu'elle devienne sécurisée et chiffrée, ne s'appliquent pas à FTP », explique Mozilla.

Par ailleurs, si certains ont bien accueilli la nouvelle, le geste de Mozilla semble n'avoir pas séduit tous les utilisateurs de Firefox. Un commentaire sur le sujet explique que les navigateurs équipés d'un support FTP sont plus utiles et conviviaux que les clients FTP. « Le FTP est lié à la navigation sur le Web depuis le début du Web, il y a 31 ans. Pendant peut-être une décennie, la majeure partie du Web se trouvait sur des serveurs FTP – pas seulement la plupart des téléchargements de logiciels, mais aussi la plupart des pages HTML », a écrit une personne qui n'est pas totalement ravie de la suppression.

« Les navigateurs Web constituent une bien meilleure interface avec les serveurs FTP que les clients FTP dédiés, car vous pouvez cliquer sur un lien dans une page HTML (soit un répertoire généré statiquement, éventuellement sur le serveur FTP lui-même, soit une page de résultats de recherche générée dynamiquement) et obtenir le fichier à partir du serveur FTP », a-t-il ajouté. Selon lui, le client FTP de votre choix est absolument inutile s'il ne peut pas rendre le HTML et que le lien ftp:// renvoie à un fichier HTML. Pour lui, plutôt que de supprimer le support FTP, il fallait envisager des moyens de le sécuriser.

« L'idée fondamentale du Web était en fait de fournir une interface universelle et uniforme à toutes les informations sur Internet, quel que soit le protocole. L'abandon de Gopher était peut-être raisonnable, il n'y a tout simplement pas beaucoup de serveurs Gopher, mais FTP est toujours un protocole largement utilisé. En d'autres termes, il s'agit d'un compromis entre la vision traditionnelle du Web comme une vaste bibliothèque, dans laquelle les connaissances humaines s'accumulent au fil du temps et deviennent accessibles à tous, et la vision du Web comme un moyen de vendre aux gens des choses dont ils n'ont pas besoin ».

Et les autres ?

Quant à Microsoft, bien que son navigateur Edge puisse être basé sur Chromium, il y a toujours Internet Explorer, qui devrait toujours faire l'affaire si vous avez besoin d'un peu d'action de transfert de fichiers rétro basée sur le navigateur.

Des options plus sécurisées existent désormais (comme FTPS et SFTP). Mais il semble que les principaux navigateurs préfèrent que les utilisateurs optent pour une application de transfert dédiée plutôt que de s'embêter à maintenir le code dans le navigateur.

Il reste un bon nombre de sites FTP, bien que beaucoup aient maintenant des alternatives pour le transfert de fichiers. L'éjection finale du code de Chrome, qui revendique une énorme base d'utilisateurs, signifie qu'il est peut-être temps de passer à autre chose

Source : feuille de route

Et vous ?

Qu'en pensez-vous ?

Et vous ?

Google a-t-il bien fait de supprimer de son code la prise en charge du protocole FTP ?
Utilisiez-vous Chrome pour les connexions FTP avant la suppression du support ?
Si oui, avez-vous une objection par rapport à la suppression du support FTP de Chrome ?
Pensez-vous aussi que les navigateurs permettent une meilleure connexion FTP que les clients dédiés ?
Quelles retombées potentielles y voyez-vous ?

[BakaOnigiri]

J'en pense que si les serveurs fournissent ces fichiers par FTP, et donc en clair, c'est bien parce-que le fait qu'il soient transmis en clair ne pose pas de problème. Donc, à mon avis, c'est juste qu'il ne veulent pas maintenir ce protocole. Par flemme.

[TotoParis]

Next Step : éjecter Chrome tout court.

[sevyc64]

J'en pense que si les serveurs fournissent ces fichiers par FTP, et donc en clair, c'est bien parce-que le fait qu'il soient transmis en clair ne pose pas de problème.

Il est beaucoup plus probable que la raison soit que les admins ne se soient jamais poser la question de la sécurité.
Beaucoup de ces serveurs ne sont pas référencés, et donc accessible (théoriquement) que si l'on en connait explicitement l'adresse.

Bon ok, souvent il suffit de remplacer le http://www.machin.truc, par ftp://ftp.machin.truc . Mais franchement qui pourrait avoir l'idée de tenter un jour une telle manipulation. Faut vraiment avoir un esprit farfelu pour imaginer qu'il suffit de changer l'adresse pour réussir


Ben en fait non, je suis toujours là
Si je me trompe pas, ce n'est pas Chrome qui est touché cette fois, mais bien Chromium. Donc cela impacte aussi bien Chrome que Edge. Mozilla y a déjà mis fin dans Firefox, Safari n'a jamais supporté le protocole, si je me trompe pas.
Quant à Opera, je ne sais pas.

il y a toujours Internet Explorer, qui devrait toujours faire l'affaire si vous avez besoin d'un peu d'action de transfert de fichiers rétro basée sur le navigateur

IE va être éjecté, à priori, manu-militari, de Windows avant l'été prochain normalement (on a pas fini de pleurer avec tout ce qui ne va plus marcher). Donc c'est une mauvaise solution.

Donc on aura plus aucun support FTP dans aucun navigateur .
De toute façon, le protocole FTP en tant que tel, est voué à disparaitre. Il en sera de même sans doute avec le FTPS, car tous les acteurs qui sécurisent leur FTP passent directement sur du SFTP.

Pour le SFTP (comme le FTPS d'ailleurs), ce n'est plus dans le navigateur, il faut des outils spécifiques adaptés. Les plus connus étant certainement Filezilla, WinSCP et CoreFTP