Postfix et TLS. Comment bien paramétrer ses ciphers ?
Hello Mesdames et Messieurs Je m'amuse à monter un petit serveur postfix à la maison, et j'ai mis un peu le nez dans la configuration TLS. Sauf que j'avoue être confronté à l'interopérabilité avec les serveurs SMTP tiers. J'ai pris la décision de "respecter" certains standard et actes conseillé, cependant je crois que cela est un poil barbare. Je vois quelques logs passer m'indiquant des erreurs de configuration du TLS. Pourtant certains mails passent, d'autre non. Exemple : 2020-04-03T06:45:32.116577+00:00 mail postfix/smtpd[21357]: connect from lstlambert-656-1-48-236.w92-154.abo.wanadoo.fr[92.154.95.236] 2020-04-03T06:45:32.188745+00:00 mail postfix/smtpd[21357]: setting up TLS connection from lstlambert-656-1-48-236.w92-154.abo.wanadoo.fr[92.154.95. 236] 2020-04-03T06:45:32.190314+00:00 mail postfix/smtpd[21357]: lstlambert-656-1-48-236.w92-154.abo.wanadoo.fr[92.154.95.236]: TLS cipher list "TLSv1.2: ECDHE:!AES128:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!EXP:!MEDIUM:!LOW:!SSLv2:!MD5:!DES:!ADH:!RC4:!PSD:!SRP:!3DES:!eNULL:!aNULL" 2020-04-03T06:45:32.192204+00:00 mail postfix/smtpd[21357]: SSL_accept:before SSL initialization 2020-04-03T06:45:32.208266+00:00 mail postfix/smtpd[21357]: SSL_accept:before SSL initialization 2020-04-03T06:45:32.210173+00:00 mail postfix/smtpd[21357]: SSL3 alert write:fatal:protocol version 2020-04-03T06:45:32.211278+00:00 mail postfix/smtpd[21357]: SSL_accept:error in error 2020-04-03T06:45:32.212614+00:00 mail postfix/smtpd[21357]: SSL_accept error from lstlambert-656-1-48-236.w92-154.abo.wanadoo.fr[92.154.95.236]: -1 2020-04-03T06:45:32.213057+00:00 mail postfix/smtpd[21357]: warning: TLS library problem: error:14209102:SSL routines:tls_early_post_process_client_ hello:unsupported protocol:ssl/statem/statem_srvr.c:1660: 2020-04-03T06:45:32.214265+00:00 mail postfix/smtpd[21357]: lost connection after STARTTLS from lstlambert-656-1-48-236.w92-154.abo.wanadoo.fr[92.15 4.95.236] 2020-04-03T06:45:32.215988+00:00 mail postfix/smtpd[21357]: disconnect from lstlambert-656-1-48-236.w92-154.abo.wanadoo.fr[92.154.95.236] ehlo=1 sta rttls=0/1 commands=1/2 Comme vous pouvez le constater ma cipherlist est "réduite" TLSv1.2:ECDHE:!AES128:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!EXP:!MEDIUM:!LOW:!SSLv2:!MD5:!DES:!ADH:!RC4:!PSD:!SRP:!3DES:!eNULL:!aNULL On peut retrouver la liste des ciphers rattaché avec openssl cphers -V 'TLSv1.2:ECDHE:!AES128:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!EXP:!MEDIUM:!LOW:!SSLv2:!MD5:!DES:!ADH:!RC4:!PSD:!SRP:!3DES:!eNULL:!aNULL' Mon idée de départ était de respecter les préco suivantes : Pas de SSLv2, SSLv3 Pas de TLS1.0, ni TLS1.1 (fin de vie de ce derneir cette année) retrait de l'AES 128 (ainsi que du camellia128) car il existe leur équivalent en 256. A la vue de ce log, est-ce que cela signifie que Wanadoo (!) transmets encore ces mails par le biais du SSLv3 ? Pourtant SSLv3 est faillible à POODLE... Est-il judicieux d'indiquer que tous les échanges avec le daemon smtpd se font en TLS ? l'option afférente étant : smtpd_tls_auth_only = yes Finalement est-il pertinent de "respecter" les recommendations du TLS, si certains ne les respectent pas. La question est plus ou moins inutile, car oui c'est pertinent, mais n'est ce pas de la discrimination que de laisser ceux qui sont à la traîne pour mettre à jour leur confs, au risque de leur retirer leur moyens d'expression ? Prochaienement la campagne des impots va commencer, et je souhaiterais recevoir le mail du centre des finances. Mais si ces percepteurs disposent de serveurs mails foireux, je ne sais si je vais parvenir à payer mes impots. Bien à vous, PM.
Salut, Le ven. 3 avr. 2020 à 12:06, P. MARCHAND <kikadisa@gmail.com> a écrit :
Sauf que j'avoue être confronté à l'interopérabilité avec les serveurs SMTP tiers. J'ai pris la décision de "respecter" certains standard et actes conseillé, cependant je crois que cela est un poil barbare.
Il y a 2-3 ans, j'ai tenté la même chose sur une partie de mon infra : j'ai très rapidement dû faire un rollback devant l'état catastrophique des configurations TLS de la plupart des serveurs SMTP. 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. En l'état actuel des choses, activer une configuration TLS "moderne" en SMTP c'est forcer une bonne partie des mails à transiter en clair, malheureusement. -- Jonathan Leroy
Bonjour tout le monde, Répondre me démangeait depuis le début de ce thread, je saute le pas (et le ton sera volontairement provocateur, en plus !) Ce sera a double tranchants, soit j'apporterai ma pierre à l'édifice soit je serai trainé devant la justice pour l'infamie mise en place sur certains de mes serveurs. Contexte : j'ai développé des services de mail2fax. Des clients envoient des e-mails vers <numéro destinataire>@mon-tld, je converti ça en fax et hop, j'envoie ça au destinataire. Sur le serveur SMTP mis en place pour ça, y'a QUE du SMTP non authentifié. Pas de TLS, même pas de SSL. Rien, juste du SMTP en clair. "Olala il a mal fait son travail, mort au roi !" Sauf que dans mon cas, je m'en fiche un peu ! Pourquoi je m'emmerderais à mettre du TLS sur mon postfix ? Le risque est ou ? La chose la plus sensible de l'e-mail, c'est la pièce jointe qui sera transmise ensuite par fax. Mais du coup, comme la partie la moins sécurisée est l'envoi du fax lui-même, implémenter TLS c'est fermer une fenêtre mais laisser la porte grande ouverte. L'implémenter ne serait pas pire, mais ça n'améliorerait pas non plus la situation, honnêtement. Du coup, DMARC/DKIM/SPF sont déclarés pour mon fax2mail/mail2fax parce que ça améliore ma note de SPAM, mais tant que les providers de comptes e-mails ne me pénaliseront pas sur le fait que je ne fais que du non-chiffré sur ce service précis, bah je ne passerai pas plus de temps de mon côté. Le jour ou Google et Microsoft (parce que ce sont eux qui font tourner le monde des e-mails, grosso modo) décideront de me coller un malus, j'y jetterai un oeil. (si vous avez des arguments contre, je suis preneur quand même :p) Alexis Le 03/04/2020 à 12:53, Jonathan Leroy - Inikup via FRsAG a écrit :
Salut,
Le ven. 3 avr. 2020 à 12:06, P. MARCHAND <kikadisa@gmail.com> a écrit :
Sauf que j'avoue être confronté à l'interopérabilité avec les serveurs SMTP tiers. J'ai pris la décision de "respecter" certains standard et actes conseillé, cependant je crois que cela est un poil barbare. Il y a 2-3 ans, j'ai tenté la même chose sur une partie de mon infra : j'ai très rapidement dû faire un rollback devant l'état catastrophique des configurations TLS de la plupart des serveurs SMTP.
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.
En l'état actuel des choses, activer une configuration TLS "moderne" en SMTP c'est forcer une bonne partie des mails à transiter en clair, malheureusement.
Bonjour, En effet, ça ne te sert à rien à toi. Par contre, ça serait utile à tes clients, ça éviterait qu'ils aient des mails en clair qui se baladent sur Internet. C'est utile directement si quelqu'un écoute le réseau et indirectement parce que ça augmente le flux chiffré général de ce qui sort de son tuyau. Je n'y connais rien en fax, mais il m'étonnerait que ce soit les mêmes techniques ou entités qui puissent écouter ces deux réseaux, donc chiffrer l'amont est toujours intéressant. Et dans tous les cas, TLS est tellement facile à mettre en place de nos jours sur la plupart des serveurs de messagerie que j'ai du mal à voir le gain de ne pas le faire. C'est ce qu'on appelle par chez moi une économie de bout de chandelle. En tout cas, j'appelle de mes vœux une prise en compte du TLS et de sa version dans la notation des mails, ça ferait en effet bouger les lignes. Guy. Le 2020-04-06 16:54, Alexis a écrit :
Bonjour tout le monde,
Répondre me démangeait depuis le début de ce thread, je saute le pas (et le ton sera volontairement provocateur, en plus !) Ce sera a double tranchants, soit j'apporterai ma pierre à l'édifice soit je serai trainé devant la justice pour l'infamie mise en place sur certains de mes serveurs.
Contexte : j'ai développé des services de mail2fax. Des clients envoient des e-mails vers <numéro destinataire>@mon-tld, je converti ça en fax et hop, j'envoie ça au destinataire. Sur le serveur SMTP mis en place pour ça, y'a QUE du SMTP non authentifié. Pas de TLS, même pas de SSL. Rien, juste du SMTP en clair.
"Olala il a mal fait son travail, mort au roi !"
Sauf que dans mon cas, je m'en fiche un peu ! Pourquoi je m'emmerderais à mettre du TLS sur mon postfix ? Le risque est ou ?
La chose la plus sensible de l'e-mail, c'est la pièce jointe qui sera transmise ensuite par fax. Mais du coup, comme la partie la moins sécurisée est l'envoi du fax lui-même, implémenter TLS c'est fermer une fenêtre mais laisser la porte grande ouverte. L'implémenter ne serait pas pire, mais ça n'améliorerait pas non plus la situation, honnêtement.
Du coup, DMARC/DKIM/SPF sont déclarés pour mon fax2mail/mail2fax parce que ça améliore ma note de SPAM, mais tant que les providers de comptes e-mails ne me pénaliseront pas sur le fait que je ne fais que du non-chiffré sur ce service précis, bah je ne passerai pas plus de temps de mon côté. Le jour ou Google et Microsoft (parce que ce sont eux qui font tourner le monde des e-mails, grosso modo) décideront de me coller un malus, j'y jetterai un oeil.
(si vous avez des arguments contre, je suis preneur quand même :p)
Alexis
Le 03/04/2020 à 12:53, Jonathan Leroy - Inikup via FRsAG a écrit :
Salut,
Le ven. 3 avr. 2020 à 12:06, P. MARCHAND <kikadisa@gmail.com> a écrit :
Sauf que j'avoue être confronté à l'interopérabilité avec les serveurs SMTP tiers. J'ai pris la décision de "respecter" certains standard et actes conseillé, cependant je crois que cela est un poil barbare. Il y a 2-3 ans, j'ai tenté la même chose sur une partie de mon infra : j'ai très rapidement dû faire un rollback devant l'état catastrophique des configurations TLS de la plupart des serveurs SMTP.
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.
En l'état actuel des choses, activer une configuration TLS "moderne" en SMTP c'est forcer une bonne partie des mails à transiter en clair, malheureusement.
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, C'est avec ce genre d'arguments que chez nous on a notre donneur d'ordre qui nous dit : " pourquoi prendre la peine de redonder le réseau si de toute façon ils ont pas mis leurs équipements sur onduleur ? De leur côté je soupçonne fortement qu'ils se disent : "Pourquoi prendre la peine de mettre des onduleurs si ils ont pas mis quelque chose d'aussi simple que de redonder le réseau ? Au final on se retrouve avec certains équipements critiques : - 1: sans onduleurs - 2 : pas de chemin réseau redondants Il faut bien commencer quelque part, que soit la partie la plus essentielle ou la partie la plus simple/ moins chère. L'excuse du "je le fais pas parce qu'une autre partie qui n'a rien a voir n'est pas faite", je pense pas qu'elle soit intégrée dans l'amélioration continue Arnaud Le mer. 13 mai 2020 à 15:58, Guy Larrieu via FRsAG <frsag@frsag.org> a écrit :
Bonjour,
En effet, ça ne te sert à rien à toi. Par contre, ça serait utile à tes clients, ça éviterait qu'ils aient des mails en clair qui se baladent sur Internet. C'est utile directement si quelqu'un écoute le réseau et indirectement parce que ça augmente le flux chiffré général de ce qui sort de son tuyau.
Je n'y connais rien en fax, mais il m'étonnerait que ce soit les mêmes techniques ou entités qui puissent écouter ces deux réseaux, donc chiffrer l'amont est toujours intéressant.
Et dans tous les cas, TLS est tellement facile à mettre en place de nos jours sur la plupart des serveurs de messagerie que j'ai du mal à voir le gain de ne pas le faire. C'est ce qu'on appelle par chez moi une économie de bout de chandelle.
En tout cas, j'appelle de mes vœux une prise en compte du TLS et de sa version dans la notation des mails, ça ferait en effet bouger les lignes.
Guy.
Le 2020-04-06 16:54, Alexis a écrit :
Bonjour tout le monde,
Répondre me démangeait depuis le début de ce thread, je saute le pas (et le ton sera volontairement provocateur, en plus !) Ce sera a double tranchants, soit j'apporterai ma pierre à l'édifice soit je serai trainé devant la justice pour l'infamie mise en place sur certains de mes serveurs.
Contexte : j'ai développé des services de mail2fax. Des clients envoient des e-mails vers <numéro destinataire>@mon-tld, je converti ça en fax et hop, j'envoie ça au destinataire. Sur le serveur SMTP mis en place pour ça, y'a QUE du SMTP non authentifié. Pas de TLS, même pas de SSL. Rien, juste du SMTP en clair.
"Olala il a mal fait son travail, mort au roi !"
Sauf que dans mon cas, je m'en fiche un peu ! Pourquoi je m'emmerderais à mettre du TLS sur mon postfix ? Le risque est ou ?
La chose la plus sensible de l'e-mail, c'est la pièce jointe qui sera transmise ensuite par fax. Mais du coup, comme la partie la moins sécurisée est l'envoi du fax lui-même, implémenter TLS c'est fermer une fenêtre mais laisser la porte grande ouverte. L'implémenter ne serait pas pire, mais ça n'améliorerait pas non plus la situation, honnêtement.
Du coup, DMARC/DKIM/SPF sont déclarés pour mon fax2mail/mail2fax parce que ça améliore ma note de SPAM, mais tant que les providers de comptes e-mails ne me pénaliseront pas sur le fait que je ne fais que du non-chiffré sur ce service précis, bah je ne passerai pas plus de temps de mon côté. Le jour ou Google et Microsoft (parce que ce sont eux qui font tourner le monde des e-mails, grosso modo) décideront de me coller un malus, j'y jetterai un oeil.
(si vous avez des arguments contre, je suis preneur quand même :p)
Alexis
Le 03/04/2020 à 12:53, Jonathan Leroy - Inikup via FRsAG a écrit :
Salut,
Le ven. 3 avr. 2020 à 12:06, P. MARCHAND <kikadisa@gmail.com> a écrit :
Sauf que j'avoue être confronté à l'interopérabilité avec les serveurs SMTP tiers. J'ai pris la décision de "respecter" certains standard et actes conseillé, cependant je crois que cela est un poil barbare. Il y a 2-3 ans, j'ai tenté la même chose sur une partie de mon infra : j'ai très rapidement dû faire un rollback devant l'état catastrophique des configurations TLS de la plupart des serveurs SMTP.
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.
En l'état actuel des choses, activer une configuration TLS "moderne" en SMTP c'est forcer une bonne partie des mails à transiter en clair, malheureusement.
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Liste de diffusion du FRsAG http://www.frsag.org/
Le 03/04/2020 à 12:04, P. MARCHAND a écrit :
Hello Mesdames et Messieurs
Je m'amuse à monter un petit serveur postfix à la maison, et j'ai mis un peu le nez dans la configuration TLS.
Sauf que j'avoue être confronté à l'interopérabilité avec les serveurs SMTP tiers. J'ai pris la décision de "respecter" certains standard et actes conseillé, cependant je crois que cela est un poil barbare.
C'est tout le problème d'Internet : des réseaux indépendants à gouvernance variable qui font au mieux pour discuter à peu près correctement avec à peu près tout le monde.
Je vois quelques logs passer m'indiquant des erreurs de configuration du TLS. Pourtant certains mails passent, d'autre non.
Exemple : 2020-04-03T06:45:32.116577+00:00 mail postfix/smtpd[21357]: connect from lstlambert-656-1-48-236.w92-154.abo.wanadoo.fr <http://lstlambert-656-1-48-236.w92-154.abo.wanadoo.fr>[92.154.95.236] 2020-04-03T06:45:32.188745+00:00 mail postfix/smtpd[21357]: setting up TLS connection from lstlambert-656-1-48-236.w92-154.abo.wanadoo.fr <http://lstlambert-656-1-48-236.w92-154.abo.wanadoo.fr>[92.154.95. 236] 2020-04-03T06:45:32.190314+00:00 mail postfix/smtpd[21357]: lstlambert-656-1-48-236.w92-154.abo.wanadoo.fr <http://lstlambert-656-1-48-236.w92-154.abo.wanadoo.fr>[92.154.95.236]: TLS cipher list "TLSv1.2: ECDHE:!AES128:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!EXP:!MEDIUM:!LOW:!SSLv2:!MD5:!DES:!ADH:!RC4:!PSD:!SRP:!3DES:!eNULL:!aNULL" 2020-04-03T06:45:32.192204+00:00 mail postfix/smtpd[21357]: SSL_accept:before SSL initialization 2020-04-03T06:45:32.208266+00:00 mail postfix/smtpd[21357]: SSL_accept:before SSL initialization 2020-04-03T06:45:32.210173+00:00 mail postfix/smtpd[21357]: SSL3 alert write:fatal:protocol version 2020-04-03T06:45:32.211278+00:00 mail postfix/smtpd[21357]: SSL_accept:error in error 2020-04-03T06:45:32.212614+00:00 mail postfix/smtpd[21357]: SSL_accept error from lstlambert-656-1-48-236.w92-154.abo.wanadoo.fr <http://lstlambert-656-1-48-236.w92-154.abo.wanadoo.fr>[92.154.95.236]: -1 2020-04-03T06:45:32.213057+00:00 mail postfix/smtpd[21357]: warning: TLS library problem: error:14209102:SSL routines:tls_early_post_process_client_ hello:unsupported protocol:ssl/statem/statem_srvr.c:1660: 2020-04-03T06:45:32.214265+00:00 mail postfix/smtpd[21357]: lost connection after STARTTLS from lstlambert-656-1-48-236.w92-154.abo.wanadoo.fr <http://lstlambert-656-1-48-236.w92-154.abo.wanadoo.fr>[92.15 4.95.236] 2020-04-03T06:45:32.215988+00:00 mail postfix/smtpd[21357]: disconnect from lstlambert-656-1-48-236.w92-154.abo.wanadoo.fr <http://lstlambert-656-1-48-236.w92-154.abo.wanadoo.fr>[92.154.95.236] ehlo=1 sta rttls=0/1 commands=1/2
Comme vous pouvez le constater ma cipherlist est "réduite" TLSv1.2:ECDHE:!AES128:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!EXP:!MEDIUM:!LOW:!SSLv2:!MD5:!DES:!ADH:!RC4:!PSD:!SRP:!3DES:!eNULL:!aNULL On peut retrouver la liste des ciphers rattaché avec openssl cphers -V 'TLSv1.2:ECDHE:!AES128:!aNULL:!eNULL:!LOW:!3DES:!MD5:!EXP:!PSK:!DSS:!RC4:!SEED:!EXP:!MEDIUM:!LOW:!SSLv2:!MD5:!DES:!ADH:!RC4:!PSD:!SRP:!3DES:!eNULL:!aNULL'
Mon idée de départ était de respecter les préco suivantes : Pas de SSLv2, SSLv3 Pas de TLS1.0, ni TLS1.1 (fin de vie de ce derneir cette année) retrait de l'AES 128 (ainsi que du camellia128) car il existe leur équivalent en 256.
A la vue de ce log, est-ce que cela signifie que Wanadoo (!) transmets encore ces mails par le biais du SSLv3 ? Pourtant SSLv3 est faillible à POODLE...
<https://tools.ietf.org/html/rfc7568> Le protocole SSLv3 est officiellement déprécié, il est en principe interdit de l'utiliser. Tu es en droit de le virer de ton côté. Et ce n'est pas Wanadoo qui essaie de te contacter, mais une adresse assignée à un abonnement Wanadoo. Peut-être quelqu'un qui s'auto-héberge (particulier ou entreprise), peut-être quelqu'un qui scanne, peut-être un robot malveillant.
Est-il judicieux d'indiquer que tous les échanges avec le daemon smtpd se font en TLS ? l'option afférente étant : smtpd_tls_auth_only = yes
Finalement est-il pertinent de "respecter" les recommendations du TLS, si certains ne les respectent pas. La question est plus ou moins inutile, car oui c'est pertinent, mais n'est ce pas de la discrimination que de laisser ceux qui sont à la traîne pour mettre à jour leur confs, au risque de leur retirer leur moyens d'expression ? Prochaienement la campagne des impots va commencer, et je souhaiterais recevoir le mail du centre des finances. Mais si ces percepteurs disposent de serveurs mails foireux, je ne sais si je vais parvenir à payer mes impots.
C'est un compromis foireux : d'un côté l'interopérabilité obligatoire, de l'autre la nécessaire protection des communications. Poser la question en ces termes implique qu'il est plus simple de ne rien faire. Bien cordialement, -- Maxime DERCHE OpenPGP public key ID : 0xAE5264B5 OpenPGP public key fingerprint : 7221 4C4F D57C 456F 8E40 3257 47F7 29A6 AE52 64B5 <https://www.mouet-mouet.net/maxime/blog/>
Salut, Le Friday 03 April 2020 12:04:12 P. MARCHAND a écrit :
Je m'amuse à monter un petit serveur postfix à la maison, et j'ai mis un peu le nez dans la configuration TLS.
Sauf que j'avoue être confronté à l'interopérabilité avec les serveurs SMTP tiers. J'ai pris la décision de "respecter" certains standard et actes conseillé, cependant je crois que cela est un poil barbare.
...
Mon idée de départ était de respecter les préco suivantes : Pas de SSLv2, SSLv3 Pas de TLS1.0, ni TLS1.1 (fin de vie de ce derneir cette année) retrait de l'AES 128 (ainsi que du camellia128) car il existe leur équivalent en 256.
C'est valable pour le web, beaucoup moins pour le mail. Il reste pas mal de mta qui ne supportent que des trucs obsolètes : des vieux serveurs jamais mis a jour, des boitiers "sécurité" d'il y a 15 ans ... En gros, laisser les paramètres par défaut de postfix, et si la distrib désactive TLSv1.0 et TLSv1.1 (coucou debian !), les réactiver. Sinon soit certains mails n'arriveront jamais, soit ils arriveront sans chiffrement du tout. 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 ...
A la vue de ce log, est-ce que cela signifie que Wanadoo (!) transmets encore ces mails par le biais du SSLv3 ? Pourtant SSLv3 est faillible à POODLE...
Pas SSLv3, mais TLSv1.0 oui. Et c'est pas les seuls. Mar 29 19:12:50 gaia postfix/smtpd[715389]: Anonymous TLS connection established from smtp08.smtpout.orange.fr[80.12.242.130]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) Autre exemple, en sortie cette fois : Mar 30 12:43:40 alpheratz postfix/smtp[703667]: Trusted TLS connection established to tiare1.inserm.fr[193.52.0.18]:25: TLSv1 with cipher AES128-SHA (128/128 bits) Et bien d'autres que je ne vois pas, car je n'ai pas énormément de trafic sur ces serveurs ...
Est-il judicieux d'indiquer que tous les échanges avec le daemon smtpd se font en TLS ?
Non. Il y a encore des mta qui envoient sans chiffrement. Il y a une flopée de trucs pour déterminer que le serveur distant requiert le tls sans repli en clair : DANE, mta-sts, RFC8689 ...
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
Finalement est-il pertinent de "respecter" les recommendations du TLS, si certains ne les respectent pas.
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é Vincent
C'est malheureusement normal. Niveau pro on a du s'ouvrir à d'anciens protocoles, niveau perso j'ai gardé que TLS 1.2 et 1.3 et un avantage fort c'est moins de spam. Les quelques correspondants qui se sont vu refuser leur mail me contactent par un autre canal et je fais de l'évangélisation et les aide à changer de smtp sortant. Le pire dans cette histoire à la rigueur les smtp bon ok c'est faillible mais c'est mieux qu'en clair car beaucoup de smtp ne chiffrent pas. Mais le véritable problème c'est des gens sous de vieilles version d'Outlook qui te disent "ha mais j'ai pas envie de changer de version, je l'ai payé je la garde" ou d'autres clients qui ne veulent pas aller sur les offres 365 avec abonnement et donc restent obsolète. Ceux là j'ai beau recommander de passer sur Thunderbird ils aime le côté Outlook ... J'ai même eu une personne qui nous a dit, je pars à la retraite dans 5 ans, j'ai pas prévu de débourser un centime de plus dans l'informatique d'ici là... C'est comme le RGPD qui a été renforcé dans certains états EU, les danois ont ainsi l'obligation d'utiliser TLS 1.2 minimum, dans les premiers mois du RGPD, tous les domaines d'Orange ne pouvait recevoir de mails venant de danois car leurs serveurs n'étaient pas compatible TLS 1.2. Je n'ai pas eu la fin de l'histoire, j'ose espérer que Orange a évolué.
Le Friday 03 April 2020 13:46:00 Wallace a écrit :
C'est comme le RGPD qui a été renforcé dans certains états EU, les danois ont ainsi l'obligation d'utiliser TLS 1.2 minimum, dans les premiers mois du RGPD
Moui, il a bon dos le RGPD ... Impressionnant la quantité de choses décidées unilatéralement sans aucune obligation légale que certains essayent de faire passer au nom du RGPD ...
tous les domaines d'Orange ne pouvait recevoir de mails venant de danois car leurs serveurs n'étaient pas compatible TLS 1.2. Je n'ai pas eu la fin de l'histoire, j'ose espérer que Orange a évolué.
Nope. Rien de changé. in : $ grep 'TLSv1 ' /var/log/mail.log | grep orange | tail -n1 Mar 29 19:12:56 gaia postfix/smtpd[708438]: Anonymous TLS connection established from smtp08.smtpout.orange.fr[80.12.242.130]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits) out : $ zgrep 'TLSv1 ' /var/log/mail.log.2.gz | grep orange | tail -n1 Mar 18 18:37:13 alpheratz postfix/smtp[535068]: Trusted TLS connection established to smtp-in.orange.fr[80.12.242.9]:25: TLSv1 with cipher DHE-RSA- AES256-SHA (256/256 bits) C'est orange hein, faut pas en demander trop ...
En essayant de rassembler tout ce qui a été échangé. Le ven. 3 avr. 2020 à 14:54, Vincent Tondellier via FRsAG <frsag@frsag.org> a écrit :
Le Friday 03 April 2020 13:46:00 Wallace a écrit :
C'est comme le RGPD qui a été renforcé dans certains états EU, les danois ont ainsi l'obligation d'utiliser TLS 1.2 minimum, dans les premiers mois du RGPD
Moui, il a bon dos le RGPD ... Impressionnant la quantité de choses décidées unilatéralement sans aucune obligation légale que certains essayent de faire passer au nom du RGPD ...
Ce point est intéressant, car la RGPD est une reglementation Européenne qui s'applique sur un espace sans limites de "frontières". Avec un peu de recul cela semble abérrant. Je comprends le besoin législatif à outrance, mais cela ne sert à personnes, et semble plutôt consituer une décharge de nombreuses responsabilité vers des acteurs hégémonique...
tous les domaines d'Orange ne pouvait recevoir de mails venant de danois car leurs serveurs n'étaient pas compatible TLS 1.2. Je n'ai pas eu la fin de l'histoire, j'ose espérer que Orange a évolué.
Nope. Rien de changé.
in :
$ grep 'TLSv1 ' /var/log/mail.log | grep orange | tail -n1 Mar 29 19:12:56 gaia postfix/smtpd[708438]: Anonymous TLS connection established from smtp08.smtpout.orange.fr[80.12.242.130]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
out :
$ zgrep 'TLSv1 ' /var/log/mail.log.2.gz | grep orange | tail -n1 Mar 18 18:37:13 alpheratz postfix/smtp[535068]: Trusted TLS connection established to smtp-in.orange.fr[80.12.242.9]:25: TLSv1 with cipher DHE-RSA- AES256-SHA (256/256 bits)
C'est orange hein, faut pas en demander trop ...
Ne pourrait-on pas les tacler législativement ? En soit ne mettent-il pas en risque leurs usagers ? ............Allô la Quadra ? 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. De : maxime@mouet-mouet.net C'est tout le problème d'Internet : des réseaux indépendants à gouvernance
variable qui font au mieux pour discuter à peu près correctement avec à peu près tout le monde.
Au départ, nous étions d'accord sur le TCP/IP, maintenant chacun fait en fait qu'a sa tête (Il ya 13 standards, attend j'ai une idée => Il y a 14 standards) Le protocole SSLv3 est officiellement déprécié, il est en principe interdit
de l'utiliser. Tu es en droit de le virer de ton côté.
Etrangement sur ce point, tout le monde semble avoir honnis le SSLv3, ce qui montre qu'il y a bien un consensus à minima pour s'accorder sur des standards. Et ce n'est pas Wanadoo qui essaie de te contacter, mais une adresse
assignée à un abonnement Wanadoo. Peut-être quelqu'un qui s'auto-héberge (particulier ou entreprise), peut-être quelqu'un qui scanne, peut-être un robot malveillant
Oui, c'était bien un scan; fausse alerte. 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. De : tonton+frsag@team1664.org
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 coupler au chiffrement opportuniste (starttls) cela permettait d'éviter le transfert non chiffré. 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... Bref, merci à tous pour vos retour. Ce que je conclus c'est : - disposez de sa boîte mail comme de sa boîte aux lettre semble compliqué. - Il est difficile de s'acorder ensemble sur les protocoles à tenir pour dialoguer - 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) Bonne journée, bon hardening, bons updates (oui, Haproxy et sa CVE cette nuit), exit 0 Le ven. 3 avr. 2020 à 14:54, Vincent Tondellier via FRsAG <frsag@frsag.org> a écrit :
Le Friday 03 April 2020 13:46:00 Wallace a écrit :
C'est comme le RGPD qui a été renforcé dans certains états EU, les danois ont ainsi l'obligation d'utiliser TLS 1.2 minimum, dans les premiers mois du RGPD
Moui, il a bon dos le RGPD ... Impressionnant la quantité de choses décidées unilatéralement sans aucune obligation légale que certains essayent de faire passer au nom du RGPD ...
tous les domaines d'Orange ne pouvait recevoir de mails venant de danois car leurs serveurs n'étaient pas compatible TLS 1.2. Je n'ai pas eu la fin de l'histoire, j'ose espérer que Orange a évolué.
Nope. Rien de changé.
in :
$ grep 'TLSv1 ' /var/log/mail.log | grep orange | tail -n1 Mar 29 19:12:56 gaia postfix/smtpd[708438]: Anonymous TLS connection established from smtp08.smtpout.orange.fr[80.12.242.130]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
out :
$ zgrep 'TLSv1 ' /var/log/mail.log.2.gz | grep orange | tail -n1 Mar 18 18:37:13 alpheratz postfix/smtp[535068]: Trusted TLS connection established to smtp-in.orange.fr[80.12.242.9]:25: TLSv1 with cipher DHE-RSA- AES256-SHA (256/256 bits)
C'est orange hein, faut pas en demander trop ... _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Le ven. 3 avr. 2020 à 16:33, P. MARCHAND <kikadisa@gmail.com> a écrit :
Ces acteurs font la loi ? Ca me dégoute.
"Your network, your rules". Mais il est vrai que quand t'as 1,5 milliards d'utilisateurs dans le monde, tes règles s'appliquent forcément un peu aux autres... -- Jonathan Leroy
re, Le 03/04/2020 à 16:30, P. MARCHAND a écrit :
En essayant de rassembler tout ce qui a été échangé.
Le ven. 3 avr. 2020 à 14:54, Vincent Tondellier via FRsAG <frsag@frsag.org <mailto:frsag@frsag.org>> a écrit :
Le Friday 03 April 2020 13:46:00 Wallace a écrit : > C'est comme le RGPD qui a été renforcé dans certains états EU, les > danois ont ainsi l'obligation d'utiliser TLS 1.2 minimum, dans les > premiers mois du RGPD
Moui, il a bon dos le RGPD ... Impressionnant la quantité de choses décidées unilatéralement sans aucune obligation légale que certains essayent de faire passer au nom du RGPD ...
Ce point est intéressant, car la RGPD est une reglementation Européenne qui s'applique sur un espace sans limites de "frontières". Avec un peu de recul cela semble abérrant. Je comprends le besoin législatif à outrance, mais cela ne sert à personnes, et semble plutôt consituer une décharge de nombreuses responsabilité vers des acteurs hégémonique...
Euh, non. Le RGPD est un Règlement qui s'applique aux données concernant des personnes citoyennes d'un État de l'Union Européenne. C'est tout. Moi ça me va bien de pouvoir *refuser* systématiquement tout traitement réalisé sur des données qui me concernent. Et j'aime l'idée que le rôle de Responsable du Traitement soit un rôle contraignant, endossant la responsabilité d'une fuite ou d'une corruption de ces données. Et toute initiative consistant à durcir, dans le respect des normes publiquement établies par des organismes à gouvernance ouverte, les conditions techniques de sécurité des données, est une initiative qu'il faut saluer et soutenir. En l'occurrence, TLS 1.2 a été publié en 2008, soit dix ans avant l'entrée en application du RGPD. Et encore, il y a eu une période de deux ans entre le vote et l'entrée en vigueur. Et même là, TLS 1.2 n'est pas parfait... Prétendre que le RGPD ne sert à personne, c'est légitimer l'abus. Prétendre que cela ne profite qu'aux gros c'est légitimer l'immobilisme. (Il y a plein de critiques à opposer au RGPD, notamment le fait qu'il vise à établir la libre circulation des données personnelles au sein de l'Union Européenne et des États disposant d'une législation jugée compatible, mais le volet protection existe, et il est utile. Ne tirons pas sur nos remparts, s'ils venaient à tomber nous devrions alors nous battre individuellement.) Bien cordialement, -- Maxime DERCHE OpenPGP public key ID : 0xAE5264B5 OpenPGP public key fingerprint : 7221 4C4F D57C 456F 8E40 3257 47F7 29A6 AE52 64B5 <https://www.mouet-mouet.net/maxime/blog/>
re, Le Friday 03 April 2020 17:16:34 Maxime DERCHE a écrit :
Le ven. 3 avr. 2020 à 14:54, Vincent Tondellier a écrit : Le Friday 03 April 2020 13:46:00 Wallace a écrit : > C'est comme le RGPD qui a été renforcé dans certains états EU, les > danois ont ainsi l'obligation d'utiliser TLS 1.2 minimum, dans les > premiers mois du RGPD
Moui, il a bon dos le RGPD ... Impressionnant la quantité de choses décidées unilatéralement sans aucune obligation légale que certains essayent de faire passer au nom du RGPD ...
Je clarifie mes propos, j'ai l'impression que ça a été surinterprété : Je suis entièrement pour le RGPD lui même et la protection des données personnelles (je n'ai pas de facebook, par exemple, et j'utilise le plus souvent un pseudo). MAIS : dans mon travail, je suis en contact avec des professionnels et des données de santé. Donc en plein dans les données les plus personnelles. On voit de tout, de l'informatique gérée par le cybercafé du coin avec un dlink et qui proposent un teamviewer (ou pire) en version gratuite, a ceux qui refusent toute connexion a internet et tout moyen d'intervention et dépannage a distance, quelque soient les protections et garanties en place. Et dans ce dernier cas c'est souvent justifié par un "le RGPD l'interdit". Et bien non, justement. C'est encadré, limité par le rgpd. Pas interdit. Ou alors le document de type contrat ou questionnaire de 150 pages a signer en plus du contrat qui nous lie déjà. Au nom du rgpd, même si ce n'est que des politiques locales ou des questions de sécurité informatique. Ou encore "depuis le rgpd, les comptes vpn doivent être nominatifs". Bah non, nous sommes une entreprise, c'est pas la responsabilité personnelle qui entre en jeu, le nom de l'entreprise suffit. Le rgpd ne demande pas ca (voir même le contraire, limiter la collecte de données personnelles). Bref, chacun interprète cette loi a sa façon, et surtout essaie d'imposer ses propres politiques en invoquant "le rgpd". Comme personne ne sait vraiment ce qu'il y a dedans ... Et dans un tout autre registre, on a aussi les "confirmez votre adresse email, c'est le rgpd qui le veut" de source inconnue. Mais bien sur, ce n'est pas du tout pour se créer une liste d'emails valides pour spammer derrière, non non non, pas du tout ... Et aussi ces immondes panneaux cookies "RGPD" avec 850 cases a décocher sur chaque site qu'on visite. Comme si les "inscrivez vous a la newsletter" n'étaient pas déjà assez pénibles. Mon navigateur indique déjà "do not track". Respectez ca, et arrêtez de me casser les pieds, vos cookies passés a travers les anti trackers seront détruits a la fermeture de toute façon. Donc pour en revenir au sujet initial, imposer des protocoles informatiques dans le cadre du RGPD, ça me semble un autre détournement du but initial de cette loi qui est la protection des données personnelles, ce qui est déjà assez complexe, pas la protection des systèmes informatiques et des communications, qui l'est tout autant ou plus encore. Ne mélangeons pas tout, ce n'est déjà pas assez clair.
Ce point est intéressant, car la RGPD est une reglementation Européenne qui s'applique sur un espace sans limites de "frontières". Avec un peu de recul cela semble abérrant. Je comprends le besoin législatif à outrance,
On dit "diarrhée legislative"
mais cela ne sert à personnes, et semble plutôt consituer une décharge de nombreuses responsabilité vers des acteurs hégémonique...
Euh, non.
Le RGPD est un Règlement qui s'applique aux données concernant des personnes citoyennes d'un État de l'Union Européenne. C'est tout.
Pas tout a fait. Il y a eu un jugement de rendu il n'y a pas très longtemps entre google et la cnil concernant le droit a l'oubli et son périmètre d'application. C'est ce que je comprends par "sans limites de frontières" au dessus. En l'occurence, "Le "droit à l'oubli" s'arrête aux frontières de l'UE, a tranché la Cour de justice de l'UE (CJUE)". Donc c'est "Le RGPD est un Règlement qui s'applique *dans l'UE* aux données concernant des personnes citoyennes d'un État de l'Union Européenne", et ne s'applique pas en dehors des frontières de l'UE.
Moi ça me va bien de pouvoir *refuser* systématiquement tout traitement réalisé sur des données qui me concernent. Et j'aime l'idée que le rôle de Responsable du Traitement soit un rôle contraignant, endossant la responsabilité d'une fuite ou d'une corruption de ces données.
En théorie, oui, c'est bien. Reste a voir si ça sera vraiment appliqué (et surtout respecté) un jour.
Et toute initiative consistant à durcir, dans le respect des normes publiquement établies par des organismes à gouvernance ouverte, les conditions techniques de sécurité des données, est une initiative qu'il faut saluer et soutenir. En l'occurrence, TLS 1.2 a été publié en 2008, soit dix ans avant l'entrée en application du RGPD. Et encore, il y a eu une période de deux ans entre le vote et l'entrée en vigueur. Et même là, TLS 1.2 n'est pas parfait...
Je ne suis pas d'accord pour tout mettre dans la même loi fourre tout. Surtout quand il s'agit de choses évoluant rapidement, un décret est plus adapté. Et je préfère avoir des lois simples et lisibles plutôt qu'un pavé indigeste. C'est raté, je sais.
Prétendre que le RGPD ne sert à personne, c'est légitimer l'abus. Prétendre que cela ne profite qu'aux gros c'est légitimer l'immobilisme.
Je n'ai ni lu ni écrit ça ici ... Bien sur que ca sert d'encadrer la gestion des données personnelles. Mon opinion serait plus du coté "n'est interprété et mis en application correctement par personne". Vincent.
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
Pour être très précis, le RGPD est un règlement européen qui fait valeur de loi minimum mais il faut que chaque état le transcrive dans ses lois nationales. Les états peuvent simplement dire on l'applique strictement ou aller plus loin que le règlement. Dans le RGPD malheureusement il y a beaucoup de pays qui ont ajoutés des éléments. Lorsque l'on a regardé notre conformité, il ne fallait pas regarder que le droit français puisque l'on a des clients dans d'autres pays. Les avocats qu'on a fait travailler sur ce sujet ont donc analysé les lois de chaque pays (et certains ont tardé à les sortir France en tête) pour sortir toutes les spécificités supplémentaires. C'est notamment là que l'on a vu qu'on devait avoir du TLS 1.2 pour le Danemark. De notre côté ça ne posait pas de souci on le gérait déjà mais du coup on l'a marqué dans les configs IaC pour tous les services vers Internet que cela ne pouvait être désactivé. Ce qui fait qu'avec les configurations Postfix et Dovecot on fait un sacré grand écart. Les serveurs ou personnes à jour sont en TLS 1.3 et les autres on propose en mode best effort, au pire c'est leur communications privées qui sont exposées, on aura prévenu. Et lorsque l'on a découvert tous ces petits arrangements dans chaque pays on a vitre compris pourquoi les non EU ont préféré pour certains ne plus permettre la connexion d'Européen sur leurs serveurs. Le 03/04/2020 à 16:30, P. MARCHAND a écrit :
En essayant de rassembler tout ce qui a été échangé.
Le ven. 3 avr. 2020 à 14:54, Vincent Tondellier via FRsAG <frsag@frsag.org <mailto:frsag@frsag.org>> a écrit :
Le Friday 03 April 2020 13:46:00 Wallace a écrit : > C'est comme le RGPD qui a été renforcé dans certains états EU, les > danois ont ainsi l'obligation d'utiliser TLS 1.2 minimum, dans les > premiers mois du RGPD
Moui, il a bon dos le RGPD ... Impressionnant la quantité de choses décidées unilatéralement sans aucune obligation légale que certains essayent de faire passer au nom du RGPD ...
Ce point est intéressant, car la RGPD est une reglementation Européenne qui s'applique sur un espace sans limites de "frontières". Avec un peu de recul cela semble abérrant. Je comprends le besoin législatif à outrance, mais cela ne sert à personnes, et semble plutôt consituer une décharge de nombreuses responsabilité vers des acteurs hégémonique...
> tous les domaines d'Orange ne pouvait recevoir de > mails venant de danois car leurs serveurs n'étaient pas compatible TLS > 1.2. Je n'ai pas eu la fin de l'histoire, j'ose espérer que Orange a évolué.
Nope. Rien de changé.
in :
$ grep 'TLSv1 ' /var/log/mail.log | grep orange | tail -n1 Mar 29 19:12:56 gaia postfix/smtpd[708438]: Anonymous TLS connection established from smtp08.smtpout.orange.fr <http://smtp08.smtpout.orange.fr>[80.12.242.130]: TLSv1 with cipher DHE-RSA-AES256-SHA (256/256 bits)
out :
$ zgrep 'TLSv1 ' /var/log/mail.log.2.gz | grep orange | tail -n1 Mar 18 18:37:13 alpheratz postfix/smtp[535068]: Trusted TLS connection established to smtp-in.orange.fr <http://smtp-in.orange.fr>[80.12.242.9]:25: TLSv1 with cipher DHE-RSA- AES256-SHA (256/256 bits)
C'est orange hein, faut pas en demander trop ...
Ne pourrait-on pas les tacler législativement ? En soit ne mettent-il pas en risque leurs usagers ? ............Allô la Quadra ?
Bonjour, Le 05/04/2020 à 10:06, Wallace a écrit :
Pour être très précis, le RGPD est un règlement européen qui fait valeur de loi minimum mais il faut que chaque état le transcrive dans ses lois nationales. Les états peuvent simplement dire on l'applique strictement ou aller plus loin que le règlement. Dans le RGPD malheureusement il y a beaucoup de pays qui ont ajoutés des éléments. Lorsque l'on a regardé notre conformité, il ne fallait pas regarder que le droit français puisque l'on a des clients dans d'autres pays. Les avocats qu'on a fait travailler sur ce sujet ont donc analysé les lois de chaque pays (et certains ont tardé à les sortir France en tête) pour sortir toutes les spécificités supplémentaires.
Alors, pour être un peu plus précis :) : <https://eur-lex.europa.eu/legal-content/FR/TXT/?uri=LEGISSUM%3Al14522> <https://fr.wikipedia.org/wiki/R%C3%A8glement_de_l%27Union_europ%C3%A9enne> Le RGPD a été mis en place pour remplacer la Directive Européenne de 1995. Une Directive étant un texte générique donnant une orientation, elle doit être transcrite dans les droits locaux, qui sont libres de l'interpréter localement en respect de la démocratie locale, et on se retrouve avec des disparités fortes entre le Sud et le Nord, l'Est et l'Ouest, et des gens qui en profitent (souvent les mêmes qui profitent des disparités fiscales). Donc, fini la Directive, on passe à un Règlement, qui est une loi supra-nationale s'appliquant partout de la même manière. Par contre, dans le texte du RGPD de 2016, il y a plusieurs endroits où certaines décisions sont laissées aux gouvernement locaux, par exemple l'âge de la "majorité numérique" de l'Article 8 ("Les États membres peuvent prévoir par la loi un âge inférieur pour ces finalités pour autant que cet âge inférieur ne soit pas en-dessous de 13 ans."). Il y a donc des divergences entre les droits locaux mais ce sont des points mineurs au regard du corps du texte (registre des traitements, catégorisation des données sensibles, analyse de risque, rôle du DPO, etc.). Et ouais ça peut être emmerdant si certains chipotent sur des points techniques tordus et non alignés, et ça peut l'être encore plus si d'autres lois locales s'y ajoutent, mais finalement ce n'est pas différent de la situation d'avant le RGPD. :p Bien cordialement, -- Maxime DERCHE OpenPGP public key ID : 0xAE5264B5 OpenPGP public key fingerprint : 7221 4C4F D57C 456F 8E40 3257 47F7 29A6 AE52 64B5 <https://www.mouet-mouet.net/maxime/blog/>
On Fri, 3 Apr 2020 13:46:00 +0200 Wallace <wallace@morkitu.org> wrote: Bonjour, je sais que c'est toujours délicat de demander aux utilisateurs de regarder du bon côté de la force, cependant, je leur fournis quelques arguments avec des analogies prises dans la vie courante. Par exemple,
Mais le véritable problème c'est des gens sous de vieilles version d'Outlook qui te disent "ha mais j'ai pas envie de changer de version, je l'ai payé je la garde"
J'ai payé pour ce superbe rôti de bœuf. Hélas, il a pourri au frigo. Ça fait rien, je l'ai payé je le garde ! Et je vais même le manger (en famille ^^) (Ils l'ont payé il y a combien d'années ? Et depuis quelle date cet achat a-t-il fini d'être comptablement amorti ?)
ou d'autres clients qui ne veulent pas aller sur les offres 365 avec abonnement et donc restent obsolète. Ceux là j'ai beau recommander de passer sur Thunderbird ils aime le côté Outlook ...
Quoi, Thunderbird ne ressemble pas assez à Outlook ? :)
J'ai même eu une personne qui nous a dit, je pars à la retraite dans 5 ans, j'ai pas prévu de débourser un centime de plus dans l'informatique d'ici là...
Mauvais client. Changer de client. :) Comment ose-t-il annoncer à son prestataire qu'il va le priver de revenus qui lui reviennent légitimement de droit ? :D
C'est comme le RGPD qui a été renforcé dans certains états EU, les danois ont ainsi l'obligation d'utiliser TLS 1.2 minimum, dans les premiers mois du RGPD, tous les domaines d'Orange ne pouvait recevoir de mails venant de danois car leurs serveurs n'étaient pas compatible TLS 1.2. Je n'ai pas eu la fin de l'histoire, j'ose espérer que Orange a évolué.
Un jour, un de mes mails ayant disparu, et certains de mes clients se plaignant d'avoir des tags "***SPAM***" dans les en-têtes reçus de leurs correspondants légitimes, j'ai fait une recherche sur Orange du point de vue de leur traitement des mails. Et là, j'ai lu quelque part sur le web (il y a plus de deux ou trois ans, actuellement je ne sais pas), j'ai lu donc que Orange utilisait un service tiers sur le sol US pour un filtrage automatique des spams. Vous imaginez tout le bien que je pense des fournisseurs de boites mails tels que Orange et autres FAI. Et en référence pour parler côté sécurité dans l'acheminement des mails, sans parler de l'ANSSI, un extrait d'une courte interview très éclairante (et drôle en même temps) du lanceur d'alerte Edward SNOWDEN par le reporter humoriste John Oliver. Le lien ci-dessous démarre presque à la fin de la vidéo, au début d'une discussion qui va mener John Oliver à faire dire à son interviewé comment les données sont interceptées et à quel moment, (mails, échanges téléphoniques et mms), le tout en prenant un exemple qui concerne la vie intime des couples (ça ne manque pas de faire réagir l'homme et la femme de la rue). https://youtu.be/XEVlyP4_11M?t=1424 Si quelqu'un veut des sous-titres en français (traduction que j'ai récupérée et révisée depuis amara.org) je peux mettre à disposition le fichier .srt Côté bonnes pratiques/bons choix de versions de SSL/TLS, diriez-vous que l'article suivant contient les bonnes infos à jour ? https://www.globalsign.fr/fr/blog/difference-entre-ssl-et-tls/ Cordialement, Joyce MARKOLL -- Orditux Informatique https://orditux.org https://orditux.org/aol
participants (9)
-
Alexis -
contact＠orditux.org -
Guy Larrieu -
Jonathan Leroy - Inikup -
Maxime DERCHE -
P. MARCHAND -
SERRUT Arnaud -
Vincent Tondellier -
Wallace