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 > <http://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 > <mailto: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 > <mailto: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/ > >
smime.p7s
Description: Signature cryptographique S/MIME
