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/