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
Bonjour,
Le 06/12/2017 à 17:04, 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
> im
Le 06/12/2017 à 17:32, Bruno Pagani a écrit :
> Le 06/12/2017 à 17:04, Julien Escario a écrit :
>> 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/SNIClien
nginx est un serveur http, à la base...
Fortinet a un load balancer (FortiADC) qui fait du SSL offload et
supporte SNI.
Ca existe au format virtuel.
my 2 cents
Le 06/12/2017 à 17:04, Julien Escario a écrit :
Bonjour la liste,
Nous sommes en train de 'rêver' à un joli reverse proxy pour le
Le 06/12/2017 à 17:44, Guillaume Tournat a écrit :
> nginx est un serveur http, à la base...
C'est négliger un peu vite ça quand même :
http://nginx.org/en/docs/mail/ngx_mail_core_module.html
OK, ce n'est pas 'coeur' de métier pour Nginx mais l'idée c'est aussi de ne pas
multiplier les produits (e
Le 06/12/2017 à 17:32, Bruno Pagani a écrit :
> Mes vhosts ce sont des directives serveurs comme ça :
> server {
> listen 443 ssl http2 ;
> listen [::]:443 ssl http2 ;
> ssl_certificate /path/to/.crt;
> ssl_certificate_key /path/to/.key;
> }
>
> J’aurais ten
Le 06/12/2017 à 18:13, Bruno Pagani a écrit :
> Le 06/12/2017 à 17:32, Bruno Pagani a écrit :
>> Mes vhosts ce sont des directives serveurs comme ça :
>> server {
>> listen 443 ssl http2 ;
>> listen [::]:443 ssl http2 ;
>> ssl_certificate /path/to/.crt;
>> ssl_ce
Vrai question : quels client supportent SNI ? Sent from my Mobile Original Message Subject: Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTPFrom: Julien Escario To: French SysAdmin Group CC: Le 06/12/2017 à 18:13, Bruno Pagani a écrit :> Le 06/12/2017 à 17:32, Bruno Pagani a écrit :>> Mes vh
Le Wed, Dec 06, 2017 at 06:36:22PM +0100, r...@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."
Bonsoir,
Je pense qu'il faut plutôt regarder HaProxy que j'utilise comme
redirection de flux(dernière un NAT) sur le port 943.
---
Cordialement,
Antoine Nivard.
Le 06-12-2017 17:59, Julien Escario a écrit :
> Le 06/12/2017 à 17:44, Guillaume Tournat a écrit :
>
>> nginx est
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
___
Liste de
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
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 t
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 divulgatio
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
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,
> > mai
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
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 as
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,
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 com
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
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
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
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:0
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'a
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 s
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 sup
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
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
Le 7 décembre 2017 à 19:51, 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 a écrit :
> En quoi TLS/SSL assur
Le Fri, Dec 08, 2017 at 09:54:10AM +0100, Jonathan Leroy
[jonat...@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 fau
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 (g
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
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 t
34 matches
Mail list logo
