[FRsAG] Postfix et TLS. Comment bien paramétrer ses ciphers ?

Vincent Tondellier tonton+frsag at team1664.org
Sam 4 Avr 00:17:19 CEST 2020


Le Friday 03 April 2020 16:30:53 P. MARCHAND a écrit :
> Le ven. 3 avr. 2020 à 14:54, Vincent Tondellier via FRsAG <frsag at frsag.org>
> > C'est orange hein, faut pas en demander trop ...
> 
> Ne pourrait-on pas les tacler législativement ?

IANAL, mais j'en doute. Je ne pense pas qu'il y ait de loi qui oblige qui que 
se soit a chiffrer quoi que ce soit (mis a part dans le domaine de la défense, 
et encore ?).
Même pour le commerce en ligne, c'est un consortium bancaire PCI-DSS qui 
définit les obligations, pas une loi.
Et là, déjà c'est chiffré. Pas avec les derniers protocoles, pas avec une 
sécurité maximale. Mais c'est chiffré. Ce n'est pas toujours le cas.


> En soit ne mettent-il pas en risque leurs usagers ?

TLSv1, ce n'est pas cassé a ce point là non plus. Il y a des faiblesses, ok, 
mais il faut un minimum de moyens pour arriver a le déchiffrer.

> ............Allô la Quadra ?

Ou alors, il faut interpréter très librement le RGPD ...
Je sais bien que c'est le principe des lois d'être a la fois très vagues et 
très obscures (faut bien justifier l'existence des professions juridiques !), 
mais je ne pense pas qu'on puisse trouver un passage qui demande une sécurité 
maximale pour les mails.
 
> De : jonathan at inikup.com
> > C'est triste à dire, mais ça va sûrement se terminer comme pour HTTPS
> > : un beau jour Google, Yahoo! et Microsoft vont décréter que leurs
> > serveurs ne parleront plus avec ceux n'ayant pas une configuration TLS
> > valide et moderne. Et alors en 6 mois 90 % des serveurs SMTP de la
> > planète seront mis à jour.
> 
> Ces acteurs font la loi ? Ca me dégoute.

Dans le mail, oui. On peut même éliminer les miettes de yahoo, il ne reste 
quasi que gmail (tiens donc, je réponds a un gmail !) et outlook. Et 
représentant une très large majorité des mails échangés entre personnes 
(j'exclus les mailchimp et autre qui ne font qu'envoyer), il se permettent de 
tout marquer en spam par défaut, sauf si ça vient de chez eux (en gros). C'est 
eux qui décident, et aucun moyen de se plaindre. Leur loi.


[...]

> > Oui il y a des algo obsolètes et vulnérables, et des tests en ligne (comme
> > internet.nl) vont râler, mais c'est toujours mieux (IMHO et celle
> > d'autres
> > personnes comme les dévs de postfix) que le repli vers le texte clair ...
> 
> Je veux bien la source de tes propos sur les devs de Postfix pour enrichir
> mes connaissances.

Dernier exemple en date sur la liste :
https://marc.info/?l=postfix-users&m=158344470515844&w=2

Implicitement, un peu partout dans la doc :
http://www.postfix.org/postconf.5.html#tls_low_cipherlist
"You are strongly encouraged to not change this setting"

Ailleurs :
https://bettercrypto.org/#_tls_usage_in_mail_server_protocols
"accept all cipher suites, as the alternative would be to fall back to 
cleartext transmission"


A noter quand même que les algos et protocoles requis peuvent varier en 
fonction de la présence ou pas de dane et/ou de mta-sts.


> > > l'option afférente étant : smtpd_tls_auth_only = yes
> > 
> > Ca c'est pas du tout pour forcer le tls. C'est pour forcer que
> > l'authentification soit annoncée et se fasse uniquement si tls est
> > présent. Il
> > ne faut activer ca que pour le msa sur le port submission/587 ou 465.
> > Voir
> > http://www.postfix.org/TLS_README.html
> > et
> > http://www.postfix.org/SASL_README.html
> 
> Pardon pour la mauvaise info, merci pour l'enrichissement ;)
> je croyais que couplé au chiffrement opportuniste (starttls) cela
> permettait d'éviter le transfert non chiffré.


http://www.postfix.org/TLS_README.html#server_enable

"You can ENFORCE the use of TLS, so that the Postfix SMTP server announces 
STARTTLS and accepts no mail without TLS encryption, by setting 
"smtpd_tls_security_level = encrypt". According to RFC 2487 this MUST NOT be 
applied in case of a publicly-referenced Postfix SMTP server."

Pareil coté client.

Voir aussi (encore une fois) DANE et mta-sts.

> > Ces recommandations sont faites pour le web ou les clients tls (les
> > navigateurs) sont mis a jour régulièrement.
> > Pour le mail, c'est beaucoup plus lent, voir même fossilisé. Dans certains
> > cas, il faut même attendre que le boitier utm/sécurité/antivirus/antispam
> > jamais mis a jour (et pas forcément a cause de l'utilisateur) tombe en
> > panne
> > pour qu'il soit remplacé
> 
>  C'est vrai, je n'y avais pas pensé à ce décalage entre le "oueb" et le
> mail, par contre en jetant un oeil à la RFC du TLS 1.1 (pour l'exemple)
> 
>    This document specifies Version 1.1 of the Transport Layer Security
>    (TLS) protocol.  The TLS protocol provides communications security
>    over the Internet.  The protocol allows client/server applications to
>    communicate in a way that is designed to prevent eavesdropping,
>    tampering, or message forgery.
> 
> Il est nullement question d'une segmentation Web/Mail...

Les versions TLS s'appliquent bien a tous les protocoles.
Mais les recommandations d'usage varient en fonction du protocole et surtout 
de son ecosystème.


> Bref, merci à tous pour vos retour.
> Ce que je conclus c'est :
>   - disposer de sa boîte mail comme de sa boîte aux lettre semble compliqué.

Avec la quantité de spam/phishing/virus et d'attaques de botnets, et vu les 
moyens mis en place dans cette lutte (dmarc, arc, dkim, spf, FCrDNS, dane, 
mta-mts, rbl, dnswl, greylisting, antispam, antivirus ...) non, le mail ce 
n'est pas/plus simple du tout, contrairement a ce que le S de SMTP prétend.

> - Il est difficile de s'acorder ensemble sur les protocoles à tenir pour
> dialoguer

Interopérabilité ...

>   - Il semble qu'il y ait une dichotomie entre les reglementations et les
> RFC. Là où les premiers sont limité géographiquement, le second est global
> (sans frontières)

?

>   - Les versions du TLS sont mises à dispositions et sont retiré par chacun
> au fur et à mesure (exemple pour le retrait du TLS 1.1 de firefox :
> https://blog.mozilla.org/security/2018/10/15/removing-old-versions-of-tls/)
> à coup de décisions unilatéral sans consortium (je veux bien une
> confirmation)

C'est plus un consensus qu'un consortium je pense.
Mais recommander quelque chose ne veut pas dire que tout le monde va le faire 
tout de suite, et probablement pas sans carotte ni contrainte (tant que ca 
fonctionne, on ne touche pas ...). Les navigateurs utilisent ici la 
contrainte.
On parle d'ailleurs d'ossification de l'internet, terme cher a "Mr. RFC" 
Stéphane Bortzmeyer ...


> Bonne journée, bon hardening, bons updates (oui, Haproxy et sa CVE cette
> nuit),

Fait. Hier soir.

:wq


Plus d'informations sur la liste de diffusion FRsAG