Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[Raphael Mazelier]

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
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[Arnaud Launay]

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.


signature.asc
Description: PGP signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[David Ponzone]

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.

___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[Dominique Rousseau]

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 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 - 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

[Jonathan Leroy]

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 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.
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[Julien Escario]

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, fr...@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, 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/
>>
> ___
> Liste de diffusion du FRsAG
> http://www.frsag.org/
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[frsag]

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, 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/


___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[Leo Gaspard]

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

[Jean Théry]

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

[Raphael Mazelier]

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

[frsag]

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

[Lunar]

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

[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.

-- 
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

[Baptiste]

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

[Jonathan Leroy]

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

[Arnaud Launay]

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

[Julien Escario]

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

[JC PAROLA]

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] SSL / SNI sur IMAP/POP/SMTP

[Dominique Rousseau]

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/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[Jean Théry]

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 =)
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[Johan Fleury]

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

signature.asc
Description: This is a digitally signed message part
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[Arnaud Launay]

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.


signature.asc
Description: Digital signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[Bruno Pagani]

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. comme SMTP/IMAP à
tous, avec leur  à 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



signature.asc
Description: OpenPGP digital signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[Raphael Mazelier]

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 diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[Antoine Nivard]

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 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 (et les compétences).
> 
>> Fortinet a un load balancer (FortiADC) qui fait du SSL offload et supporte 
>> SNI.
>> 
>> Ca existe au format virtuel.
> 
> Une boite noire, très peu pour moi. J'aime autant investir du temps pour
> maîtriser HAProxy.
> 
> Julien
> ___
> Liste de diffusion du FRsAG
> http://www.frsag.org/___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[Arnaud Launay]

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."


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.


signature.asc
Description: PGP signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[r...@futomaki.net]

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 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 tendance à dire que la même chose avec 993 et pas en HTTP ça>> devrait fonctionner, mais j’ai jamais testé donc bon…> > Et en fait non : la réponse est effectivement que nginx ne supporte pas> le SNI en mail proxy (la directive /listen/ n’accepte pas d’argument> ). En 2013–2014, certains se sont posé la question, et la> réponse de l’époque c’est que ça n’était pas à l’ordre du jour :> https://forum.nginx.org/read.php?2,237967,237967#msg-237967 (plus> lisible ici cela dit: https://www.ruby-forum.com/topic/4412511)OK, clair net et précis : no-go :-( Le petit espoir que la situation aie changéedepuis vient de s'éteindre dans un râle d'agonie.> Je suppose que les choses n’ont pas évolué depuis. Bonne config de HAProxy !C'est parti ;-)Merci,Julien___Liste de diffusion du FRsAGhttp://www.frsag.org/___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[Julien Escario]

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_certificate_key /path/to/.key;
>>  }
>>
>> J’aurais tendance à dire que la même chose avec 993 et pas en HTTP ça
>> devrait fonctionner, mais j’ai jamais testé donc bon…
> 
> Et en fait non : la réponse est effectivement que nginx ne supporte pas
> le SNI en mail proxy (la directive /listen/ n’accepte pas d’argument
> ). En 2013–2014, certains se sont posé la question, et la
> réponse de l’époque c’est que ça n’était pas à l’ordre du jour :
> https://forum.nginx.org/read.php?2,237967,237967#msg-237967 (plus
> lisible ici cela dit: https://www.ruby-forum.com/topic/4412511)

OK, clair net et précis : no-go :-( Le petit espoir que la situation aie changée
depuis vient de s'éteindre dans un râle d'agonie.

> Je suppose que les choses n’ont pas évolué depuis. Bonne config de HAProxy !

C'est parti ;-)

Merci,
Julien
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[Bruno Pagani]

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 tendance à dire que la même chose avec 993 et pas en HTTP ça
> devrait fonctionner, mais j’ai jamais testé donc bon…

Et en fait non : la réponse est effectivement que nginx ne supporte pas
le SNI en mail proxy (la directive /listen/ n’accepte pas d’argument
). En 2013–2014, certains se sont posé la question, et la
réponse de l’époque c’est que ça n’était pas à l’ordre du jour :
https://forum.nginx.org/read.php?2,237967,237967#msg-237967 (plus
lisible ici cela dit: https://www.ruby-forum.com/topic/4412511)

Je suppose que les choses n’ont pas évolué depuis. Bonne config de HAProxy !

Bruno


signature.asc
Description: OpenPGP digital signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[Julien Escario]

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 (et les compétences).

> Fortinet a un load balancer (FortiADC) qui fait du SSL offload et supporte 
> SNI.
> 
> Ca existe au format virtuel.

Une boite noire, très peu pour moi. J'aime autant investir du temps pour
maîtriser HAProxy.

Julien
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[Guillaume Tournat]

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 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] SSL / SNI sur IMAP/POP/SMTP

[Bruno Pagani]

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/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 ?

Ah et pour Dovecot, la conf SNI c’est aussi simple que ça:
https://wiki.dovecot.org/SSL/DovecotConfiguration#With_client_TLS_SNI_.28Server_Name_Indication.29_support



signature.asc
Description: OpenPGP digital signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/

Re: [FRsAG] SSL / SNI sur IMAP/POP/SMTP

[Bruno Pagani]

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
> 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.

Ça marche sur le port 443 mais pas sur le 993, c’est ça que tu nous dis ?

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 tendance à dire que la même chose avec 993 et pas en HTTP ça
devrait fonctionner, mais j’ai jamais testé donc bon…

Vous voulez forcément mettre un reverse proxy devant ? Ça va pas si le
serveur SMTP/IMAP le gère directement ?

Parce que…

> 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 ?

… heureusement que ça fonctionne, oui ! Je fais du SNI avec Dovecot pour
l’IMAP en effet, et avec OpenSMTPd pour le SMTP. Ça roule tout seul. :)
Mes utilisateurs (dont moi) ont des clients principalement K-9 Mail et
Thunderbird, mais il y a aussi du « Client Android par défaut » et du
Apple Mail.

Bruno



signature.asc
Description: OpenPGP digital signature
___
Liste de diffusion du FRsAG
http://www.frsag.org/

[FRsAG] SSL / SNI sur IMAP/POP/SMTP

[Julien Escario]

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/