Le 8 déc. 2013 à 22:30, Yann Vercucque <yann.vercuc...@gmail.com> a écrit :
> Je rajouterai également qu'un employeur est tenu (Juridiquement parlant, loi > anti-terroriste) de loguer l'intégralité des flux web lorsqu'il dispose d'un > hotspot invité. De ce faite, il est nécessaire de faire de l'interception > SSL, afin loguer les flux HTTPS. Pas nécessaire de casser SSL pour cela. Il suffit de garder l’entête http de la négociation SSL. Il faut pas loggue le contenu de l’échange. > > Comme cela a déjà été dit, le problème n'est pas l'interception SSL. Mais > l'interception SSL par un certificat signé par une autorité connu. > > Au passage les équipements comme Fortigate, permettent de choisir de ne pas > intercepter les banques, les sites médicaux et les réseaux sociaux. > > Yann, > > Le 8 déc. 2013 à 21:06, Raphaël Stehli <experti...@raphael.stehli.fr> a écrit > : > >> Juridiquement parlant, rien n'empêche à un employeur (public ou privé) : >> - de déchiffrer le contenu des flux chiffrés pour les analyser de manière >> automatique, >> - de déchiffrer le contenu des flux chiffrés pour interception manuelle, à >> la demande d'une autorité administration ou juridictionnelle, voir même à >> des fins internes, sous réserve de ne pas consulter les informations ayant >> un caractère personnel sans que le salarié ait été appelé. Le juge >> prudhommal vérifiera. >> >> Il existerait un risque théorique de réutiliser le résultats de >> l'interception pour pirater une banque. Néanmoins, le risque est faible : >> - les banques sérieuses utilise du forward secrecy, qui devrait limiter les >> problèmes de l'interception SSL, >> - les entreprises ne laisse pas trainer leurs clés privées n'importent où >> (ou elles se retourneront à leur tour contre le responsable informatique), >> - les salariés ou agents doivent être au courant de l'interception SSL via >> la charte informatique et la déclaration CNIL donc en utilisant le système >> informatique de l'entreprise / administration, ils étaient au courant et ils >> ont fait le choix de se connecter à leur banque avec le système, >> - les banques sérieuses utilisent un autre système complémentaire (SMS, code >> à usage unique, etc.) >> >> Donc, même en cas de vol de la clé, l'entreprise devrait voir sa >> responsabilité fortement minorée. >> >> Le problème ici est que ce problème, lié a du gmail a fait bondir Google : >> son modèle économique est uniquement basé sur la confiance des utilisateurs. >> Le modèle des ACR est basé sur la confiance des acteurs du secteurs. >> La réaction de Google était donc prévisible. >> >> Pour la restriction à *.gouv.fr, ce n'est pas forcément possible : il existe >> des administrations qui n'utilisent pas le .gouv.fr : je pense aux >> assemblées, aux juridictions et aux autres agences administratives >> indépendantes. >> >> Je ne sais pas si quelqu'un peut maintenant prévoir la suite des évènements, >> mais il faut espérer que les modifications de protocoles de l'ANSSI >> arriveront à convaincre Google, Microsoft et Mozilla de ne pas bloquer les >> certificats racine de l'IGC/A. >> >> Il faudrait également savoir comment les responsables de l'AC intermédiaire >> ont pu signer un certificat de pour google ou gmail. >> >> >> Cordialement, >> Raphaël >> >> >> Le 08/12/2013 20:33, Jean-Yves Faye a écrit : >>> Bonsoir, >>> >>> NetASQ a cette fonctionnalité, et de plus est un produit bien Français. >>> Purement techniquement parlant, cette technique peut être pratique pour >>> garder l'aspect SSL des communications, tout en soumettant à l'analyse >>> antivirus/IDS les flux entrants, chose courante avec les appliances type >>> NetASQ justement. >>> >>> Comme déjà dit, le danger vient plutôt de le faire avec une AC certifiée et >>> publique (par transitivité). Normalement on fait ça avec une AC interne et >>> les certificats spécifiques sont déployés sur les postes. >>> >>> Après cela remet encore une fois sur le tapis la question de la liste à >>> rallonge des autorités "de confiance" qui peuvent donner des certificats >>> pour n'importe quoi, qui ne veut plus dire grand chose. Dans ce cas précis, >>> une fonctionnalité de type restriction à *.gouv.fr sur l'IGC de >>> l'administration aurait été pertinente. >>> >>> Un nettoyage des magasins de certificats des navigateurs est la seule >>> solution à court terme, ça ou alors les éditeurs de navigateurs se mettent >>> à implémenter les protocoles déjà proposés pour réduire la voilure niveau >>> portes d'entrée dans le système des IGC (moins problable) >>> >>> Cordialement, >>> >>> Jean-Yves Faye >>> >>> >>> Le 8 décembre 2013 20:08, Fabien Delmotte <fdelmot...@mac.com> a écrit : >>> Bonsoir, >>> >>> Pareil pour A10 networks et le SSL intercept .. Cela me parait plus un >>> problème de configuration qu’autre chose. >>> >>> Je ne connais pas les lois pour la France (il doit y en avoir beaucoup sur >>> le sujet avec le comment faire et son contraire), mais cela fonctionne sans >>> problème Technique dans les autres pays. >>> J’ai personnellement installé plusieurs configuration en dehors de la >>> France sans problèmes techniques. >>> >>> Cordialement >>> >>> Fabien >>> >>> Le 8 déc. 2013 à 19:48, Surya ARBY <arbysu...@yahoo.fr> a écrit : >>> >>> > C'est pourtant le principe de fonctionnement des firewalls palo alto qui >>> > font du MITM SSL avec des certificats signés par la PKI interne. >>> > >>> > Le 08/12/2013 19:26, Kavé Salamatian a écrit : >>> >> 2-l’employeur n’a pas a inspecter le trafic SSL qui va de son réseau >>> >> vers une destination en dehors de son réseau. Il peut décider de bloquer >>> >> ce traffic, mais le décrypter avec un certificat « fake » c’est du >>> >> piratage caractérisé et je suis sur qu’une ribambelle de lois de >>> >> s’appliquent (pas le temps de les chercher). >>> > >>> > >>> > --------------------------- >>> > Liste de diffusion du FRnOG >>> > http://www.frnog.org/ >>> >>> >>> --------------------------- >>> Liste de diffusion du FRnOG >>> http://www.frnog.org/ >>> >> --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
