Avec la configuration standard recommandée, l'authentification de l'utilisatrice fonctionne mais pas le transfert de données : pas même le listing du répertoire d'arrivée. On ne peut rien en faire.

La réponse se trouve dans /var/log/proftpd/tls.log :

mars 16 12:16:00 mod_tls/2.4.2[10126]: client did not reuse SSL session, rejecting data connection (**see TLSOption NoSessionReuseRequired**)

mars 16 12:16:00 mod_tls/2.4.2[10126]: unable to open data connection: TLS negotiation failed

Comme expliqué dans la FAQ de proftpd, on suit les indications du message.

Ajouter l'option NoSessionReuseRequired dans /etc/proftpd/tls.conf :

TLSOptions NoCertRequest NoSessionReuseRequired

Au final, le résumé du fichier tls.conf opérationnel est le suivant :

# sed '/^$\|^#/d' tls.conf

<IfModule mod_tls.c>
TLSEngine on
TLSLog /var/log/proftpd/tls.log
TLSProtocol SSLv23
TLSRSACertificateFile /etc/proftpd/ssl/proftpd.crt 
TLSRSACertificateKeyFile /etc/proftpd/ssl/proftpd.key
TLSOptions NoCertRequest NoSessionReuseRequired
TLSVerifyClient off
TLSRequired on
</IfModule>

On peut également rencontrer des problèmes de pare-feu NAT/routage.

Avant même de parler de TLS, si le serveur FTP est accessible via un NAT-routeur, ce routeur doit impérativement pouvoir inspecter le contenu des paquets pour assurer le suivi de connexion (conntrack). Avec TLS, le paquet étant chiffré, ce suivi n'est plus possible.

Un pare-feu exploitant du routage-NAT peut bloquer l'échange des données (en laissant passer l'authentification utilisatrice). On peut contourner le problème, sans toucher au pare-feu, en utilisant la commande ccc (clear command channel). Cela permet de ne chiffrer que l'échange de mots de passe. L'échange de données se fait en clair, permettant ainsi à un NAT/routeur FTP-aware, d'inspecter les données pour y récupérer les numéros de ports utilisés, sans que ceux-ci soient préalablement déclarés.

• l'explication du pourquoi et comment s'en sortir (FAQ proftpd)
• un exemple de traitement des problèmes de pare-feu sur CentOS

L'installation par défaut de KDE Konqueror permet de faire du ftp, du sftp (ftp over ssh) mais pas du ftps (tls-ssl). Une URL de la forme « ftps:me@my.domain » n'est pas reconnue. Si seule la connexion en tls est acceptée par la serveur, une tentative de connexion via « ftp://me@my.domain » détectera la demande d'échange chiffré des identifiants provenant du serveur mais ne parviendra pas à l'honorer. Il faut installer le paquetage kio-ftps, qui dotera KDE - et donc Konqueror - de cette fonctionnalité : # apt-get install kio-ftps À la suite de quoi, les URLs du type « ftps:me@my.domain » sont reconnues.

Cette utilisation est transparente à la condition que l'autorité de certification du certificat ssl soit reconnue par Konqueror. Ce ne sera jamais le cas s'il s'agit d'un certificat auto-signé. .

Les configurations proposées dans la section « serveurs » (ci-avant) s'appuient sur des auto-signés. S'ils sont acceptés par Konqueror lors de connexion https (avec toutes les précautions d'usage), l'intégration est beaucoup moins aboutie en matière de connexion ftps.

À la différence de ce qu'il fait dans le cas d'une connexion https, Konqueror ne propose pas d'enregistrer le certificat (ni pour une session, ni pour toujours). Une pop-up affiche le message « The certificate is self-signed, and untrusted » et ne propose que « Continue » ou « Annuler ». Cliquer « Continue » permet d'établir une connexion mais la pop-up surgira de nouveau, de manière sporadique, lors des prochaines actions (navigation dans les répertoires, ouverture d'un fichier).On est loin d'une utilisation transparente des répertoires distants telle qu'on la connait à travers ftp ou sftp.

L'ajout manuel du certificat serveur (importation via Kleopatra, par exmple) ne résout pas le problème. La seule solution identifiée à ce jour passe par la création d'une autorité de certification. Le certificat serveur n'est alors plus auto-signé mais signé par cette autorité. L'ajout du certificat racine de cette autorité (via Kleopatra) entraîne le reconnaissance des certificats signés par elle.

Le plus futées relèveront que le certificat racine étant lui-même, par nature, auto-signé, il serait plus simple que Konqueror reconnaisse directement les certificats serveurs auto-signés, ajoutés manuellement. On est bien d'accord !

La création d'une autorité de certification dépasse le cadre de cette fiche.

Après insertion, via Kleopatra¹⁾, des 2 certificats racine de CaCert (Root CA : root et class3), les certificats signés par CaCert sont reconnus dans tout KDE.

L'utilisation d'un certificat CaCert quelconque est alors accepté par Konqueror, en ftps. Si les nom de domaines ne correspondent pas, le problème est signalé et il est proposé à l'utilisatrice de passer outre. Si elle accepte, la session se déroule sans accroc ni demande intempestive d'identification.

Sur Filezilla, les réglages suivants fonctionnent :

• port : vide (défaut)
• chiffrement : Connexion FTP explicite sur TLS
• type d'authenfication : normal
• paramètres de transfert : par défaut

Filezilla refuse d'implenter le ccc car une bonne configuration de serveur permet de s'en passer.