Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP
Le Wed, Dec 06, 2017 at 06:36:22PM +0100, raph@futomaki.net a écrit:
Vrai question : quels client supportent SNI ?
Pas postfix... Ok, sur le côté serveur. Sur le côté client, ça supporte. http://www.postfix.org/TLS_README.html "There are no plans to implement SNI in the Postfix SMTP server." Tiens, ya une mini liste là: https://wiki.dovecot.org/SSL/SNIClientSupport Bref le SNI côté client mail, ça n'a pas l'air gagné pour le moment. Arnaud.
On 06/12/2017 18:54, Arnaud Launay wrote:
Bref le SNI côté client mail, ça n'a pas l'air gagné pour le moment.
Bah ouais c'est bien ce que je pensais. Du coup l'interet de le faire est globalement limité non ? Cdt, -- Raphael Mazelier
Le 06/12/2017 à 22:09, Raphael Mazelier a écrit :
On 06/12/2017 18:54, Arnaud Launay wrote:
Bref le SNI côté client mail, ça n'a pas l'air gagné pour le moment.
Bah ouais c'est bien ce que je pensais.
Faudrait tester et ajouter cette info sur https://en.wikipedia.org/wiki/Comparison_of_email_clients par exemple.
Du coup l'interet de le faire est globalement limité non ?
Comme je disais plus tôt, dans mon cas 100 % des clients utilisés font du SNI. Donc pour moi c’était utile, les utilisateurs ont pas un message « bizarroïde » quand ils configurent leur client et je n’ai pas non plus à indiquer un nom de serveur qui n’a rien à voir avec leur nom de domaine pour éviter ça : je fournis mail.<domaine> comme SMTP/IMAP à tous, avec leur <domaine> à eux. Maintenant il faut voir le parc de clients en face, et ce qu’il en est du support de SNI chez ceux-ci. Par exemple, est-ce que Outlook sous Windows gère ça mieux que sous Mac ? Moi il y a zéro Windows dans mon parc, donc bon… Bruno
Le Wed, Dec 06, 2017 at 10:09:12PM +0100, Raphael Mazelier a écrit:
Bref le SNI côté client mail, ça n'a pas l'air gagné pour le moment. Bah ouais c'est bien ce que je pensais. Du coup l'interet de le faire est globalement limité non ?
Je vois assez bien l'intérêt côté client: configurer tous tes potes avec "smtp.domain.tld" (avec auth) et "imap.domain.tld", te permet de changer de FSI plus facilement que si tu utilises smtp.fsi.tld et imap.fsi.tld, qui t'oblige à passer sur tous tes postes clients pour la moindre modif... (Evidemment, la solution c'est "pas de SSL", mais sur du smtp authentifié, c'est quand même très très moche) (sur l'imap aussi, mais ça permet moins facilement d'envoyer du spam qui tache, par contre, en terme de divulgation d'infos, ça...) Arnaud.
Le mercredi 06 décembre 2017 à 22:27 +0100, Arnaud Launay a écrit :
(Evidemment, la solution c'est "pas de SSL", mais sur du smtp authentifié, c'est quand même très très moche) (sur l'imap aussi, mais ça permet moins facilement d'envoyer du spam qui tache, par contre, en terme de divulgation d'infos, ça...)
On est en 2017, bientôt en 2018, conseiller à quelqu’un de **ne pas** mettre en place TLS, c’est criminel. -- Johan Fleury PGP Key ID : 0x5D404386805E56E6
Le 07.12.2017 à 00:15, Johan Fleury a écrit :
Le mercredi 06 décembre 2017 à 22:27 +0100, Arnaud Launay a écrit :
(Evidemment, la solution c'est "pas de SSL", mais sur du smtp authentifié, c'est quand même très très moche) (sur l'imap aussi, mais ça permet moins facilement d'envoyer du spam qui tache, par contre, en terme de divulgation d'infos, ça...)
On est en 2017, bientôt en 2018, conseiller à quelqu’un de **ne pas** mettre en place TLS, c’est criminel.
il y a un sacré paquet de criminels dans le monde alors =)
Le Wed, Dec 06, 2017 at 06:15:37PM -0500, Johan Fleury [jfleury@arcaik.net] a écrit:
Le mercredi 06 décembre 2017 à 22:27 +0100, Arnaud Launay a écrit :
(Evidemment, la solution c'est "pas de SSL", mais sur du smtp authentifié, c'est quand même très très moche) (sur l'imap aussi, mais ça permet moins facilement d'envoyer du spam qui tache, par contre, en terme de divulgation d'infos, ça...)
On est en 2017, bientôt en 2018, conseiller à quelqu???un de **ne pas** mettre en place TLS, c???est criminel.
Tu sais, en 2017, il y a encore des gens qui utilisent Windows XP, par exemple. (sinon Microsoft n'aurait pas eu a publier de correctif pour Wanacry en milieu d'année) -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 21 rue Frédéric Petit - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
Le 06/12/2017 à 22:27, Arnaud Launay a écrit :
Le Wed, Dec 06, 2017 at 10:09:12PM +0100, Raphael Mazelier a écrit:
Bref le SNI côté client mail, ça n'a pas l'air gagné pour le moment. Bah ouais c'est bien ce que je pensais. Du coup l'interet de le faire est globalement limité non ?
Je vois assez bien l'intérêt côté client: configurer tous tes potes avec "smtp.domain.tld" (avec auth) et "imap.domain.tld", te permet de changer de FSI plus facilement que si tu utilises smtp.fsi.tld et imap.fsi.tld, qui t'oblige à passer sur tous tes postes clients pour la moindre modif...
Bah voilà, c'est l'idée.
(Evidemment, la solution c'est "pas de SSL", mais sur du smtp authentifié, c'est quand même très très moche) (sur l'imap aussi, mais ça permet moins facilement d'envoyer du spam qui tache, par contre, en terme de divulgation d'infos, ça...)
Ca par contre, c'est non. Pas la peine d'argumenter, je vire direct les mecs de mon équipes qui font encore ça en 2017. Julien
Le Thu, Dec 07, 2017 at 12:52:44PM +0100, Julien Escario a écrit:
Je vois assez bien l'intérêt côté client: configurer tous tes potes avec "smtp.domain.tld" (avec auth) et "imap.domain.tld", te permet de changer de FSI plus facilement que si tu utilises smtp.fsi.tld et imap.fsi.tld, qui t'oblige à passer sur tous tes postes clients pour la moindre modif... Bah voilà, c'est l'idée.
A part que ce n'est pas possible pour le moment, au vu de la diversité des clients mails, ou alors il faut partir du principe que tu n'en supportes que quelques-uns.
(Evidemment, la solution c'est "pas de SSL", mais sur du smtp authentifié, c'est quand même très très moche) (sur l'imap aussi, mais ça permet moins facilement d'envoyer du spam qui tache, par contre, en terme de divulgation d'infos, ça...) Ca par contre, c'est non. Pas la peine d'argumenter, je vire direct les mecs de mon équipes qui font encore ça en 2017.
C'est la seule solution possible avec les contrainte de support de tous les clients mails possibles /et/ du domain.tld du client. La solution sécurisée ici, c'est smtp/imap.fsi.tld, et c'est tout. Quoi que si, il y en a une autre, à l'ancienne, d'avant le SNI: une IP par certificat SSL client. Faudrait se rappeler que le but de l'informatique, c'est d'offrir des outils à vos clients, pas de les faire chier au maximum. Si ça peut être sécurisé, tant mieux, sinon, il faut qu'ils puissent travailler quand même. C'est une simple application du https://en.wikipedia.org/wiki/Robustness_principle Ici par exemple, on fait tout en TLS, mais on supporte quand même les versions non chiffrées, parce que ce n'est pas à nous d'imposer à un client des règles de sécurité. On leur donne les outils pour respecter les best practices, mais ce n'est certainement pas notre rôle de les forcer. (Et bon courage devant les prud'hommes pour justifier un licenciement parce qu'un type a voulu faire en sorte qu'un client puisse être concentré sur son coeur de métier) Arnaud, qui se demande si on est vendredi, vu les trolls.
Le 7 décembre 2017 à 13:16, Arnaud Launay <asl@launay.org> a écrit :
Faudrait se rappeler que le but de l'informatique, c'est d'offrir des outils à vos clients, pas de les faire chier au maximum. Si ça peut être sécurisé, tant mieux, sinon, il faut qu'ils puissent travailler quand même.
Euh... Donc tu comptes sur Michel de la compta pour faire un choix éclairé sur le fait de configurer son MUA avec ou sans SSL ? J'aimerai bien connaître une seule raison valable, en 2017, de configurer son client mail de façon non sécurisée. Perso j'en vois pas. -- Jonathan Leroy.
HAProxy n''est qu'un reverse-proxy TCP de "base" pour ce qui concerne le POP / IMAP, mais il saura très bien route des connexions en fonction du SNI. Après, tu peux l'utiliser aussi pour loguer le fameux SNI envoyé par le client, ça te permet de faire un "audit" et de savoir s'il est pertienent de mettre ça en place. Voici un petit lien, puisse-t-il t'inspirer: https://www.haproxy.com/fr/blog/enhanced-ssl-load-balancing-with-server-name... La partie qui t'interesse, c'est les lignes 15 à 19 du premier exemple de conf. Baptiste
Le Thu, Dec 07, 2017 at 01:24:43PM +0100, Jonathan Leroy [jonathan@unsigned.inikup.com] a écrit: [...]
Euh... Donc tu comptes sur Michel de la compta pour faire un choix éclairé sur le fait de configurer son MUA avec ou sans SSL ?
J'aimerai bien connaître une seule raison valable, en 2017, de configurer son client mail de façon non sécurisée. Perso j'en vois pas.
Parceque le firmware du copieur-qui-a-10-ans qui fait du mail2fax ne sait faire ni TLS, ni authentificaiton. Pareil pour l'application métier XZTY qui récupère des mails en POP-et-rien-d-autre. -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 21 rue Frédéric Petit - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
Dominique Rousseau:
Le Thu, Dec 07, 2017 at 01:24:43PM +0100, Jonathan Leroy [jonathan@unsigned.inikup.com] a écrit: [...]
Euh... Donc tu comptes sur Michel de la compta pour faire un choix éclairé sur le fait de configurer son MUA avec ou sans SSL ?
J'aimerai bien connaître une seule raison valable, en 2017, de configurer son client mail de façon non sécurisée. Perso j'en vois pas.
Parceque le firmware du copieur-qui-a-10-ans qui fait du mail2fax ne sait faire ni TLS, ni authentificaiton. Pareil pour l'application métier XZTY qui récupère des mails en POP-et-rien-d-autre.
Une solution de compromis que j'ai vu chez certains hébergeurs : faire un hôte dédié pour ça, type « unsecure.example.org ». Ça permet de faire une politique différente pour ce qui est d'un changement régulier de mots de passe ou de restreindre des comptes à certaines adresses IPs. -- Lunar
Autoriser le trafic en clair, c'est punir le bon avec le mauvais, en fragilisant l'ensemble de ton système, pour tous (et pas que pour le gueux avec son fax) Si ce type veut supporter son système antédiluvien, c'est son choix, mais qu'il l'assume seul. Vive le TLS obligatoire; On 12/07/2017 05:08 PM, Dominique Rousseau wrote:
Parceque le firmware du copieur-qui-a-10-ans qui fait du mail2fax ne sait faire ni TLS, ni authentificaiton. Pareil pour l'application métier XZTY qui récupère des mails en POP-et-rien-d-autre.
-- "UNIX was not designed to stop its users from doing stupid things, as that would also stop them from doing clever things." – Doug Gwyn
Le 07/12/2017 à 19:51, frsag@jack.fr.eu.org a écrit :
Autoriser le trafic en clair, c'est punir le bon avec le mauvais, en fragilisant l'ensemble de ton système, pour tous (et pas que pour le gueux avec son fax)
Si ce type veut supporter son système antédiluvien, c'est son choix, mais qu'il l'assume seul.
Vive le TLS obligatoire;
En quoi TLS/SSL assure une meilleure sécurité ? certes cela ne coute pas bien cher de nos jours et c'est pas pire. Mais bon clairement si l'on recherche à échanger des informations confidentielles ce n'est certainement pas le mail qu'il faut utiliser. (à la limite avec du GPG/PGP et encore). J'ai un peu de mal avec les discours du type : on est secure parce qu'on a activé du 's' partout ; surtout quand il est dogmatique; aka les mecs qui ne font pas sont des idiots. C'est bien plus compliqué que cela. La sécurité c'est aussi/souvent d'abord une analyse de risque, et des procédures adaptés en conséquences. -- Raphael Mazelier
Le 07.12.2017 à 22:11, Raphael Mazelier a écrit :
Le 07/12/2017 à 19:51, frsag@jack.fr.eu.org a écrit :
Autoriser le trafic en clair, c'est punir le bon avec le mauvais, en fragilisant l'ensemble de ton système, pour tous (et pas que pour le gueux avec son fax)
Si ce type veut supporter son système antédiluvien, c'est son choix, mais qu'il l'assume seul.
Vive le TLS obligatoire;
En quoi TLS/SSL assure une meilleure sécurité ? certes cela ne coute pas bien cher de nos jours et c'est pas pire. Mais bon clairement si l'on recherche à échanger des informations confidentielles ce n'est certainement pas le mail qu'il faut utiliser. (à la limite avec du GPG/PGP et encore). J'ai un peu de mal avec les discours du type : on est secure parce qu'on a activé du 's' partout ; surtout quand il est dogmatique; aka les mecs qui ne font pas sont des idiots. C'est bien plus compliqué que cela. La sécurité c'est aussi/souvent d'abord une analyse de risque, et des procédures adaptés en conséquences.
-- Raphael Mazelier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ +1
Spa parce que TLS n'est pas suffisant pour sécuriser qu'il n'a aucun rapport avec le sujet; Je ne sais pas si ton protocol est secure, mais clairement, si un simple tcpdump / ethercap / truc me permet de voir l'intégralité de ta communication, il y a un petit problème Nécessaire != suffisant On 08/12/2017 04:58, Jean Théry wrote:
Le 07.12.2017 à 22:11, Raphael Mazelier a écrit :
Le 07/12/2017 à 19:51, frsag@jack.fr.eu.org a écrit :
Autoriser le trafic en clair, c'est punir le bon avec le mauvais, en fragilisant l'ensemble de ton système, pour tous (et pas que pour le gueux avec son fax)
Si ce type veut supporter son système antédiluvien, c'est son choix, mais qu'il l'assume seul.
Vive le TLS obligatoire;
En quoi TLS/SSL assure une meilleure sécurité ? certes cela ne coute pas bien cher de nos jours et c'est pas pire. Mais bon clairement si l'on recherche à échanger des informations confidentielles ce n'est certainement pas le mail qu'il faut utiliser. (à la limite avec du GPG/PGP et encore). J'ai un peu de mal avec les discours du type : on est secure parce qu'on a activé du 's' partout ; surtout quand il est dogmatique; aka les mecs qui ne font pas sont des idiots. C'est bien plus compliqué que cela. La sécurité c'est aussi/souvent d'abord une analyse de risque, et des procédures adaptés en conséquences.
-- Raphael Mazelier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ +1
Liste de diffusion du FRsAG http://www.frsag.org/
Bonjour, Bon, c'est vendredi mais on va peut être gentiment pouvoir arrêter le troll parce qu'on s'éloigne à vitesse grand V du sujet initial et on se rapproche pas mal du point Godwin. On fait le tour des poncifs de notre métier : oui, un point de sécu tout seul ne sert à rien (aka TLS si le mec se connecte à partir d'un poste tout vérolé), oui, il faut assurer une compatibilité raisonnable avec d'anciennes versions et ne pas tordre le bras aux clients chaque fois que la nouvelle-techno-à-la-mode-avec-un-joli-buzzword sort. Après, chacun voit midi à sa porte concernant ces choix : est-ce la compatibilité doit être assurée pendant 3 jours, 3 mois, 3 ans ? Maintenant, qu'on me balance sur une liste qu'il faut encore supporte IE6 sous XP ou qu'on contraire, il faut bannir tout avant IE10 win8, ben en fait, vous pissez dans un violon les mecs. C'est pas votre problème puisque vous ne connaissez pas mon environnement de boulot. Maintenant, les vérités : * En 2018, TOUT service doit être dispo en chiffré (forcé ou non, c'est votre choix). * Les gens qui traînent des vieilles versions DOIVENT savoir qu'elles prennent un risque non négligeable. * C'est AUSSI notre boulot de faire passer la bonne parole. Anecdote : hier, on était à une formation RIPE sur DNSSEC. Le grand argument, c'est qu'actuellement, c'est que l'ensemble de la chaîne de confiance est basée sur UN seul groupe de personnes (7 sous l'égide de l'ICANN dont Vinton Cerf 'le trouble') au lieu des quelques 700 autorités de certifications reconnues actuellement. OK, mais ça me gêne un peu : à aucun moment n'a été évoqué la raison pour laquelle je devrais faire confiance à ces mecs. La réponse ne tiendrait pas ici et chacun doit se faire son avis. Ce n'est pas parce que la communauté fait un truc qu'on est forcément tous d'accord. C'est d'ailleurs le principe des RFCs et comme ça qu'on a bâti l'informatique et le net en général. Pareil pour let's encrypt d'ailleurs : chouette projet très utile, mais ne vous faites pas d'illusion, ça va merder techniquement ou politiquement un jour ou l'autre. Allé, bon trollday à toutes et à tous (je ne perds pas espoir que notre métier se féminise davantage), Julien Le 08/12/2017 à 09:14, frsag@jack.fr.eu.org a écrit :
Spa parce que TLS n'est pas suffisant pour sécuriser qu'il n'a aucun rapport avec le sujet;
Je ne sais pas si ton protocol est secure, mais clairement, si un simple tcpdump / ethercap / truc me permet de voir l'intégralité de ta communication, il y a un petit problème
Nécessaire != suffisant
On 08/12/2017 04:58, Jean Théry wrote:
Le 07.12.2017 à 22:11, Raphael Mazelier a écrit :
Le 07/12/2017 à 19:51, frsag@jack.fr.eu.org a écrit :
Autoriser le trafic en clair, c'est punir le bon avec le mauvais, en fragilisant l'ensemble de ton système, pour tous (et pas que pour le gueux avec son fax)
Si ce type veut supporter son système antédiluvien, c'est son choix, mais qu'il l'assume seul.
Vive le TLS obligatoire;
En quoi TLS/SSL assure une meilleure sécurité ? certes cela ne coute pas bien cher de nos jours et c'est pas pire. Mais bon clairement si l'on recherche à échanger des informations confidentielles ce n'est certainement pas le mail qu'il faut utiliser. (à la limite avec du GPG/PGP et encore). J'ai un peu de mal avec les discours du type : on est secure parce qu'on a activé du 's' partout ; surtout quand il est dogmatique; aka les mecs qui ne font pas sont des idiots. C'est bien plus compliqué que cela. La sécurité c'est aussi/souvent d'abord une analyse de risque, et des procédures adaptés en conséquences.
-- Raphael Mazelier _______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/ +1
Liste de diffusion du FRsAG http://www.frsag.org/
_______________________________________________ Liste de diffusion du FRsAG http://www.frsag.org/
Oui et sans compter que le plus grand trou de sécurité d'un compte mail, c'est que l'utilisateur connaisse son propre mot de passe et puisse le donner volontairement ou non autour de lui, oralement ou par écrit, en pensant que c'est sans importance. Quand on aura de l'authentif mail par jeton (genre FortiToken ou Google Authenticator) avec renouvellement forcé toutes les 2h, ce problème là sera réglé. Le 8 déc. 2017 à 09:51, Julien Escario a écrit :
Bonjour, Bon, c'est vendredi mais on va peut être gentiment pouvoir arrêter le troll parce qu'on s'éloigne à vitesse grand V du sujet initial et on se rapproche pas mal du point Godwin.
On fait le tour des poncifs de notre métier : oui, un point de sécu tout seul ne sert à rien (aka TLS si le mec se connecte à partir d'un poste tout vérolé), oui, il faut assurer une compatibilité raisonnable avec d'anciennes versions et ne pas tordre le bras aux clients chaque fois que la nouvelle-techno-à-la-mode-avec-un-joli-buzzword sort.
Le 08/12/2017 à 09:51, Julien Escario a écrit :
Bonjour, Bon, c'est vendredi mais on va peut être gentiment pouvoir arrêter le troll parce qu'on s'éloigne à vitesse grand V du sujet initial et on se rapproche pas mal du point Godwin.
Peut être pas quand même, on est bien élevé :)
On fait le tour des poncifs de notre métier : oui, un point de sécu tout seul ne sert à rien (aka TLS si le mec se connecte à partir d'un poste tout vérolé), oui, il faut assurer une compatibilité raisonnable avec d'anciennes versions et ne pas tordre le bras aux clients chaque fois que la nouvelle-techno-à-la-mode-avec-un-joli-buzzword sort.
Après, chacun voit midi à sa porte concernant ces choix : est-ce la compatibilité doit être assurée pendant 3 jours, 3 mois, 3 ans ?
Maintenant, qu'on me balance sur une liste qu'il faut encore supporte IE6 sous XP ou qu'on contraire, il faut bannir tout avant IE10 win8, ben en fait, vous pissez dans un violon les mecs. C'est pas votre problème puisque vous ne connaissez pas mon environnement de boulot. Oui la je pense qu'on est tous d'accord : chacun son environnement, contraintes, et priorités.
Maintenant, les vérités : * En 2018, TOUT service doit être dispo en chiffré (forcé ou non, c'est votre choix). C'est un choix. Comme je disais parfois cela ne coute pas cher, donc parfois il n'y a pas de réel raisons objectives de ne pas le faire. Parfois c'est plus compliqué et je peux comprendre qu'on investisse pas (encore) de temps la dessus ; et malheureusement sur des parties bien plus critiques que le sous domaine mail (DNS, BGP). * Les gens qui traînent des vieilles versions DOIVENT savoir qu'elles prennent un risque non négligeable. Comme tous les gens qui utilisent un ordinateur pour communiquer en fait :) elles prennent juste un peu plus de risque. Le problème c'est que ce n'est absolument pas quantifiable/quantifié. Si on prend une analogie foireuse, on pourrait arguer que toutes les mesures concernant la sécurité routière ont eu un effet bénéfique si on en croit les chiffres officiels du nombre de morts/accidents. Sur la sécurité informatique j'aimerais bien avoir des indicateurs qui m'aiguille sur quelle mesure prendre en priorité, et qu'est ce que cela a apporté. Vous avez un nombre de combien d'usurpation d'identité d'une boite mail a empêché TLS/SSL ? moi non. (après on est bien d'accord cet exemple précis est pourri parce que cela ne coute rien à faire, la compat cliente est bonne, donc c'est un peu triste de ne pas le faire).
* C'est AUSSI notre boulot de faire passer la bonne parole.
Quelle est la bonne parole ? :) Pour moi c'est d'abord l'éducation des utilisateurs et professionnels de l'outil informatique. Comment ça marche, qu'est ce que cela implique, quels sont les risques, et quels sont les bonnes pratiques ?
Anecdote : hier, on était à une formation RIPE sur DNSSEC. Le grand argument, c'est qu'actuellement, c'est que l'ensemble de la chaîne de confiance est basée sur UN seul groupe de personnes (7 sous l'égide de l'ICANN dont Vinton Cerf 'le trouble') au lieu des quelques 700 autorités de certifications reconnues actuellement. OK, mais ça me gêne un peu : à aucun moment n'a été évoqué la raison pour laquelle je devrais faire confiance à ces mecs. La réponse ne tiendrait pas ici et chacun doit se faire son avis. Ce n'est pas parce que la communauté fait un truc qu'on est forcément tous d'accord. C'est d'ailleurs le principe des RFCs et comme ça qu'on a bâti l'informatique et le net en général.
Pareil pour let's encrypt d'ailleurs : chouette projet très utile, mais ne vous faites pas d'illusion, ça va merder techniquement ou politiquement un jour ou l'autre.
Autre énorme sujet que les autorités de confiance. Qui décide qui est de confiance ou pas ? Google au moins visiblement (voir l'histoire Thawte/Symantec en cours).
Allé, bon trollday à toutes et à tous (je ne perds pas espoir que notre métier se féminise davantage), Julien
PUB : on doit avoir une des DT les plus féminines de France , au moins 40% de femmes :) et nous recrutons encore (femmes, hommes, dev, ops, devops). -- Raphael Mazelier
On 12/07/2017 10:11 PM, Raphael Mazelier wrote:
Le 07/12/2017 à 19:51, frsag@jack.fr.eu.org a écrit :
Autoriser le trafic en clair, c'est punir le bon avec le mauvais, en fragilisant l'ensemble de ton système, pour tous (et pas que pour le gueux avec son fax)
Si ce type veut supporter son système antédiluvien, c'est son choix, mais qu'il l'assume seul.
Vive le TLS obligatoire;
En quoi TLS/SSL assure une meilleure sécurité ? certes cela ne coute pas bien cher de nos jours et c'est pas pire. Mais bon clairement si l'on recherche à échanger des informations confidentielles ce n'est certainement pas le mail qu'il faut utiliser. (à la limite avec du GPG/PGP et encore). J'ai un peu de mal avec les discours du type : on est secure parce qu'on a activé du 's' partout ; surtout quand il est dogmatique; aka les mecs qui ne font pas sont des idiots. C'est bien plus compliqué que cela. La sécurité c'est aussi/souvent d'abord une analyse de risque, et des procédures adaptés en conséquences.
Exemple de scénario : il faut supporter des clients qui se connectent depuis des wifi ouverts sans ouvrir à tous les vents les boîtes mail ni broadcaster les mots de passe. Je ne sais pas si beaucoup de monde gère un serveur mail qui ne doit pas supporter ce genre de cas d'usage. Autant je suis d'accord normalement sur l'idée de l'analyse de risque avant de hurler à la faille de sécurité, autant au moins mettre une couche de chiffrement quand il y a des mots de passes qui transitent ça m'a l'air du strict minimum, surtout maintenant que c'est quasi-gratuit et qu'on ne peut plus argumenter qu'il y a plus important à faire pour moins cher. Et tout ça sans lien avec la sécurité des communications, qui est encore un autre sujet, pour le coup nettement plus compliqué à gérer correctement.
Le 7 décembre 2017 à 19:51, <frsag@jack.fr.eu.org> a écrit :
Autoriser le trafic en clair, c'est punir le bon avec le mauvais, en fragilisant l'ensemble de ton système, pour tous (et pas que pour le gueux avec son fax)
Tout à fait. Le 7 décembre 2017 à 22:11, Raphael Mazelier <raph@futomaki.net> a écrit :
En quoi TLS/SSL assure une meilleure sécurité ? certes cela ne coute pas bien cher de nos jours et c'est pas pire. Mais bon clairement si l'on recherche à échanger des informations confidentielles ce n'est certainement pas le mail qu'il faut utiliser. (à la limite avec du GPG/PGP et encore).
Sans TLS, les identifiants sont transmis en clair au serveur. Ce qui pour moi est une raison suffisante pour déployer TLS.
J'ai un peu de mal avec les discours du type : on est secure parce qu'on a activé du 's' partout ; surtout quand il est dogmatique; aka les mecs qui ne font pas sont des idiots. C'est bien plus compliqué que cela. La sécurité c'est aussi/souvent d'abord une analyse de risque, et des procédures adaptés en conséquences.
Personne n'a dit que déployer TLS allait résoudre tous les problèmes de sécurité. Je dis juste que c'est la base. Devoir argumenter sur ça en 2017 sur FRSAG me déprime un peu. -- Jonathan Leroy.
Le Fri, Dec 08, 2017 at 09:54:10AM +0100, Jonathan Leroy [jonathan@unsigned.inikup.com] a écrit: [...]
Devoir argumenter sur ça en 2017 sur FRSAG me déprime un peu.
Il n'est pas question d'argumenter sur le fait qu'il faut déployer TLS ou non. On est globalement tous d'accord pour dir qu'il faut proposer des connexions "sécurisées" par TLS. La divergence est plus sur "il faut absolument que tout soit sur TLS, sinon c'est mega dangereux" vs la vraie vie où ce n'est pas toujours possible (et où ce n'est pas forcément grave). (et je +1 le dernier message de Julien qui dit qu'on va arreter là, meme si on est vendredi, parceque ca n'a plus rien à voir avec le sujet initial) -- Dominique Rousseau Neuronnexion, Prestataire Internet & Intranet 21 rue Frédéric Petit - 80000 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop
Le Fri, Dec 08, 2017 at 09:59:50AM +0100, Dominique Rousseau a écrit:
si on est vendredi, parceque ca n'a plus rien à voir avec le sujet initial)
Et le sujet initial, c'était "SNI avec des clients mail", et la réponse au doigt mouillé est "oui, avec des clients mails / OS (très) récents". Que ce soit fait avec haproxy, perdition, dovecot ou autre, c'est son choix, ça fera le boulot. Arnaud.
participants (13)
-
Arnaud Launay -
Baptiste -
Bruno Pagani -
David Ponzone -
Dominique Rousseau -
frsag＠jack.fr.eu.org -
Jean Théry -
Johan Fleury -
Jonathan Leroy -
Julien Escario -
Leo Gaspard -
Lunar -
Raphael Mazelier