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