J'ai cru comprendre que la directive "smtp_tls_security_level = may" (entre autres) permet d'activer un mode chiffrement opportuniste nommé STARTTLS et donc que ce dernier est vulnérable aux attaques en MITM.
Plus précisément, le niveau may implique les deux comportements suivants :
ton serveur demande au serveur d’en face que la communication soit chiffrée, mais accepte d’envoyer le mail en clair si le serveur d’en face ne propose pas le chiffrement (ou si un attaquant actif supprime l’option STARTTLS en chemin) ;
même si la communication est chiffrée, ton serveur ne vérifiera pas la validité du certificat d’en face.
Est-il possible de ne pas utiliser STARTTLS avec "smtp_tls_security_level = enforce", par exemple ?
Comment ça, ne pas utiliser STARTTLS ? A priori tu veux forcer l’utilisation de STARTTLS, au contraire...
Pour rendre le chiffrement obligatoire, tu peux en principe (mais voir la question suivante d’abord) utiliser smtp_tls_security_level = encrypt. La différence par rapport au niveau inférieur may est qu’à ce niveau, ton serveur coupera court à la communication si le serveur d’en face n’utilise pas TLS (que ce soit parce qu’il ne supporte pas le chiffrement ou parce qu’un attaquant a supprimé l’option STARTTLS en chemin).
Est-il raisonnable d'interdire la communication avec des serveurs n'utilisant pas le chiffrement, sachant qu'ils sont peu nombreux ?
Peu nombreux, peu nombreux... la dernière fois que j’ai analysé les logs de mon serveur pour voir l’utilisation du chiffrement, il y avait encore environ 15% de serveurs qui n’acceptaient que des communications en clair. Pour moi c’est encore beaucoup trop pour que je sois confortable avec l’idée d’interdire toute connexion en clair.
Faut-il autoriser l'utilisation d'algorithmes cryptographiques obsolètes, pour garantir une compatibilité optimale ?
Il y a quelques années j’aurais dit « oui », en partant du principe qu’une communication chiffrée avec un algorithme obsolète est toujours mieux qu’une communication en clair.
Je n’en suis plus si sûr aujourd’hui. Toujours d’après les logs de mon serveur, il semble que les serveurs mails dans la nature se répartissent désormais en deux grandes catégories :
ceux qui supportent le chiffrement : ceux-là supportent les dernières versions de TLS (1.2, 1.3) et les algorithmes les plus modernes ;
ceux qui ne supportent pas du tout le chiffrement.
Concrètement, contrairement à ce qui se passait il y a encore deux ou trois ans, je ne vois plus dans mes logs aucune trace de serveurs « intermédiaires », qui supporteraient le chiffrement mais n’offreraient que des versions dépassées de TLS (SSLv3, TLS 1.0, TLS 1.1) et/ou que des algorithmes « faibles . C’est bien sûr à pondérer avec le fait qu’il ne s’agit que de ce que voit mon serveur (je ne prétends pas que c’est représentatif de tout le paysage des serveurs mails), mais je ne pense pas qu’on perde beaucoup aujourd’hui à refuser de supporter des protocoles et algorithmes dépassés.
# No subject
Posté par gouttegd . En réponse au message TLS et Postfix. Évalué à 8.
Plus précisément, le niveau may implique les deux comportements suivants :
STARTTLSen chemin) ;Comment ça, ne pas utiliser STARTTLS ? A priori tu veux forcer l’utilisation de STARTTLS, au contraire...
Pour rendre le chiffrement obligatoire, tu peux en principe (mais voir la question suivante d’abord) utiliser
smtp_tls_security_level = encrypt. La différence par rapport au niveau inférieur may est qu’à ce niveau, ton serveur coupera court à la communication si le serveur d’en face n’utilise pas TLS (que ce soit parce qu’il ne supporte pas le chiffrement ou parce qu’un attaquant a supprimé l’optionSTARTTLSen chemin).Peu nombreux, peu nombreux... la dernière fois que j’ai analysé les logs de mon serveur pour voir l’utilisation du chiffrement, il y avait encore environ 15% de serveurs qui n’acceptaient que des communications en clair. Pour moi c’est encore beaucoup trop pour que je sois confortable avec l’idée d’interdire toute connexion en clair.
Il y a quelques années j’aurais dit « oui », en partant du principe qu’une communication chiffrée avec un algorithme obsolète est toujours mieux qu’une communication en clair.
Je n’en suis plus si sûr aujourd’hui. Toujours d’après les logs de mon serveur, il semble que les serveurs mails dans la nature se répartissent désormais en deux grandes catégories :
Concrètement, contrairement à ce qui se passait il y a encore deux ou trois ans, je ne vois plus dans mes logs aucune trace de serveurs « intermédiaires », qui supporteraient le chiffrement mais n’offreraient que des versions dépassées de TLS (SSLv3, TLS 1.0, TLS 1.1) et/ou que des algorithmes « faibles . C’est bien sûr à pondérer avec le fait qu’il ne s’agit que de ce que voit mon serveur (je ne prétends pas que c’est représentatif de tout le paysage des serveurs mails), mais je ne pense pas qu’on perde beaucoup aujourd’hui à refuser de supporter des protocoles et algorithmes dépassés.