La crypto n’a pas que des avantages
►https://www.bortzmeyer.org/crypto-debug.html
[L’usage systématique de la cryptographie] est tout à fait justifié. Mais il ne faut pas s’imaginer qu’il va être gratuit : tout chiffrer va faire perdre certaines possibilités, notamment en matière de déboguage.
#Analyseur_de_paquets #Chiffrement #Cryptographie #Déboguage #Développement_de_logiciel #Informatique #Internet #Perfect_Forward_Secrecy #Réseau #Sécurité_informatique
Blog Stéphane Bortzmeyer : La crypto n’a pas que des avantages
►http://www.bortzmeyer.org/crypto-debug.html
Même si on n’est pas sûr que la cryptographie protège bien contre un adversaire de la puissance de la NSA, ne pas se protéger serait une folie, puisque la NSA et tous les espions plus petits pourraient alors regarder le contenu du trafic sans problème. Donc, il faut chiffrer. Mais, personnellement, je regrette que les géniaux outils de déboguage réseau comme tcpdump et Wireshark soient de moins en moins utiles à cause du « tout chiffrement ».
Alors, certains et certaines vont me dire « mais il existe des outils qui savent déchiffrer le trafic chiffré, si on leur fournit la(les) clés privée(s), par exemple Wireshark ». Mais ce n’est plus vrai non plus. Voyons d’abord les outils disponibles :
tcpdump ne sait déchiffrer que l’IPsec, protocole peu utilisé.
ssldump sait déchiffrer le TLS (autrefois nommé SSL).
Wireshark sait déchiffrer le TLS.
Aucun ne sait déchiffrer le SSH.
La crypto n’a pas que des avantages
Suite aux révélations du héros Edward Snowden, bien des gens ont pris conscience de ce que tous les experts en sécurité annonçaient depuis longtemps : les services d’espionnage espionnent et ne respectent aucune limite. Notamment, tout le trafic envoyé sur l’Internet peut être écouté, si on ne prend pas de précautions particulières. La solution technique la plus souvent citée est l’usage systématique de la #cryptographie. Ce choix est tout à fait justifié. Mais il ne faut pas s’imaginer qu’il va être gratuit : tout chiffrer va faire perdre certaines possibilités, notamment en matière de déboguage.
Petit retour d’expérience de ces dernières semaines qui va dans ton sens.
1) Un serveur web mutualisé. Je souhaite le rendre « conforme », c’est à dire pas de FTP en clair. J’implémente un FTP/S explicite, pensant qu’avec la disponibilité de FileZilla, tout va fonctionner tout seul chez les clients. Erreur... Les firewall, aléatoirement, refusent de laisser passer le flux... là où pour le FTP en clair, ils laissent passer normalement le flux. C’est tout récent, pas encore réussi à comprendre les raisons de ces disparités.
2) Accès à un serveur RDP. Le prospect trouve qu’un accès direct, port 3389, ce n’est pas sécurisé. Je lui dis qu’il a raison, lui propose un client IPSEC pour se connecter à l’infra. Il répond que ça ne marche pas, son réseau d’entreprise ne lui permet pas. Je lui propose un client RDP en mode web, sur du https, authentification préliminaire HTTP. Il trouve que la double authentification, c’est pénible, et surtout, il ne parvient pas à se connecter, car en effet, son réseau d’entreprise prévoit que les sites https, c’est sur liste blanche uniquement... Bien... Ce n’est qu’un prospect, son service info ne met pas en liste blanche n’importe quel prospect... Alors je passe tout en port 80, sans authentification. Youpie. (ça crépite dans les logs...).
Et je peux aussi évoquer la gestion des mots de passe... Où l’attribution d’un mot de passe fort peut conduire à des heures de support avec certains clients, qui préfèrent se passer du service plutôt que de devoir taper un mot de passe convenablement.
Conclusion : pour permettre aux utilisateurs de bosser, j’en reviens à des solutions sans cryptage et à mot de passe faible. C’est consternant.
Parce que les firewalls interprètent le protocole FTP pour définir les ports « aleatoire » a ouvrir pour les transferts... Si c’est chiffré, ça marche moins bien.
Il faut alors définir une plage de port dédié au FTP que le firewall va naté directement.
Exemple avec la conf de « proftpd » :
PassivePorts 50000 59999
Dans le firewall avec netfilter :
iptables -t filter -A INPUT —in-interface eth0 —protocol tcp —dport 50000:59999 —jump ACCEPT
Voila.
