Le Friday 03 April 2020 16:30:53 P. MARCHAND a écrit :
Le ven. 3 avr. 2020 à 14:54, Vincent Tondellier via FRsAG frsag@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@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