Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP
On 12/07/2017 10:11 PM, Raphael Mazelier wrote: > Le 07/12/2017 à 19:51, fr...@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. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP
Le 07.12.2017 à 22:11, Raphael Mazelier a écrit : > Le 07/12/2017 à 19:51, fr...@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/
Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP
Le 07/12/2017 à 19:51, fr...@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/
Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP
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 ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP
Dominique Rousseau: > Le Thu, Dec 07, 2017 at 01:24:43PM +0100, Jonathan Leroy > [jonat...@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 signature.asc Description: PGP signature ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP
Le Thu, Dec 07, 2017 at 01:24:43PM +0100, Jonathan Leroy [jonat...@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 - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP
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-indication-sni-tls-extension/ La partie qui t'interesse, c'est les lignes 15 à 19 du premier exemple de conf. Baptiste ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP
Le 7 décembre 2017 à 13:16, Arnaud Launay 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. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP
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. signature.asc Description: PGP signature ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP
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 ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP
Pour ma part, j'ai testé 1/ Perdition comme ReverseProxy POP/IMAP. c'est pas mal du tout. très léger. Cela gère un backend fichier(avec regex) ou Mysql. Il gère le TLS. (à voir si le SNI est supporté) 2/ Dovecot en Proxy IMAP/POP. Le backend se fait avec Mysql avec une bonne gestion du cache pour éviter les surcharges. sur la liste, j'ai lu que Dovecot gere le SNI peut-être ta solution ? -- Jean-christophe PAROLA Le mercredi 06 décembre 2017 à 17:04 +0100, Julien Escario a écrit : > Bonjour la liste, > Nous sommes en train de 'rêver' à un joli reverse proxy pour les > connexions > IMAP, POP (hum) et SMTP avec du ssl offloading et toussa. > > L'idéal serait que l'on puisse écouter sur (par exemple), le port 993 > pour > imap.domaine1.com, imap.domaine2.com, etc ... > Le tout en présentant un certificat valide pour chaque domaine et ça, > s'appelle > SNI (RFC 6066 section 3). C'est une extension TLS donc indépendant du > protocole. > > Je prends les devants : nous ne souhaitons pas avec un gros > certificat qui > comprenne tous les vhosts. > > SNI donc, on le fait déjà massivement en HTTP over SSL (aka HTTPS), > tous les > browser modernes le supportent. > > Le soucis c'est déjà que l'on s'y est pris avec Nginx et ca semble > pas vraiment > supporté : impossible de déclarer deux vhosts qui écoutent sur le > port 993, ca > gère un conflit : > nginx: [emerg] duplicate "993" address and port pair > > Nginx tout frais : nginx version: nginx/1.13.6 > > Aucune doc là dessus chez Nginx, du coup la question : est-ce que > quelqu'un a > une trace d'un tel hack avec Nginx ? Quitte à regarder du côté d'un > module > 'custom' qu'on veut bien compiler, tester de debugger. > > Sinon, Haproxy semble le faire et on investira le temps nécessaire à > l'apprentissage. > > Mais, question subsidiaire : je ne trouve aucune liste du support SNI > par les > clients IMAP ou SMTP ? C'est si exotique ce que l'on veut faire ? > OK, il y a : https://wiki.dovecot.org/SSL/SNIClientSupport pour avoir > une idée > du support en IMAP. > > Est-ce que quelqu'un s'est déjà lancé dans ça ? Avec du succès ou pas > ? > > Merci d'avance ! > Julien > ___ > Liste de diffusion du FRsAG > http://www.frsag.org/___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] Gateway Anti SPAM
Bonjour, Nous, on utilise Baruwa, qui a été opensource, et qui ne l’est plus maintenant. (http://baruwa.com). Très bonne intégration des briques de base (exim,MailScanner, …), console très propre. Il déverse dans notre Exchange. Ce qui nous a fait décider pour cette plate-forme, c’est le fait qu’elle segmente par client, et donc que l’on peut spécifier des règlages Mailscanner ou autre réglage, par client. Par exemple, le fait de déverser les SPAM dans les Courriers Indésirables d’Exchange, est un réglage client par client. Bon support technique, assez réactif. Seul inconvénient : je me sens un peu seul à l’utiliser. Je n’ai aucune idée du nombre de clients que Baruwa a, mais cela n’a pas l’air énorme. Il est sud-africain. My 2 cents Sylvain Donnet DDO Organisation De : FRsAG au nom de Guillaume LAPOUGE Date : jeudi 7 décembre 2017 10:17 À : "'frsag@frsag.org'" Objet : [FRsAG] Gateway Anti SPAM Bonjour, Je souhaiterais faire un sondage sur les personnes utilisant une gateway antispam open source en frontal d’un exchange avec leurs avantages / incovéniants. Merci de vos retours. ___ Liste de diffusion du FRsAG http://www.frsag.org/
[FRsAG] Gateway Anti SPAM
Bonjour, Je souhaiterais faire un sondage sur les personnes utilisant une gateway antispam open source en frontal d'un exchange avec leurs avantages / incovéniants. Merci de vos retours. ___ Liste de diffusion du FRsAG http://www.frsag.org/
Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP
Le Wed, Dec 06, 2017 at 06:15:37PM -0500, Johan Fleury [jfle...@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 - 8 Amiens tel: 03 22 71 61 90 - fax: 03 22 71 61 99 - http://www.neuronnexion.coop ___ Liste de diffusion du FRsAG http://www.frsag.org/
