====== proftpd TLS SSL ====== ===== Serveur ===== ==== reuse SSL session ==== Avec la configuration standard [[http://www.howtoforge.com/setting-up-proftpd-tls-on-debian-squeeze|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 [[http://www.proftpd.org/docs/howto/TLS.html#TLSDataTransfer|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 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 ==== NAT Firewall ==== 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 ([[http://irp.nain-t.net/doku.php/130netfilter:020_conntrack|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. * [[http://www.proftpd.org/docs/howto/TLS.html#TLSFirewall|l'explication]] du pourquoi et comment s'en sortir (FAQ proftpd) * [[http://kiteplans.info/2012/02/18/centos-virtualmin-secure-ftp/|un exemple]] de traitement des problèmes de pare-feu sur **CentOS** ===== Clients ===== ==== Konqueror ==== === Ajout de la fonctionnalité FTPS === 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 [[http://kde-apps.org/content/show.php?content=35875|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é. . === Autorité de certification inconnue === 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. == CaCert == Après insertion, **via Kleopatra****(( L'insertion de certificats-racines, via le panneau de contrôle KDE (Configuration du système > Réseau et connectivité > Préférences SSL ), ne fonctionne pas. ))**, 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. ==== Filezilla ==== === Réglages === 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 === Blocages === Filezilla [[https://forum.filezilla-project.org/viewtopic.php?f=3&t=18402|refuse d'implenter le ccc]] car une __bonne__ configuration de serveur permet de s'en passer.