Le 08/12/2013 23:19, Kavé Salamatian a écrit : >> - 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, > pas suffisant. L’interception ne peut se faire qu’à avec objectif > d’amélioration du service. L’information de justifie pas l’action illégale de > l’entreprise ou de l’administration. Il y’a de la jurisprudence la dessus.
Je veux bien la jurisprudence. > >> - les banques sérieuses utilisent un autre système complémentaire (SMS, code >> à usage unique, etc.) > Le fait que la banque n’est pas sérieuse ou le système est mal protégé ne > réduit pas la responsabilité juridique de l’attaquant. Effectivement, mais un système avec une vérification par un autre canal limite la casse pour la boite, pas pour l'attaquant. > >> 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. > On que non. J’espère que l’épisode permettra de montrer qu’on ne peut pas > faire n’importe quoi par qu’il est techniquement possible de le faire. Ce > genre d’épisode met complètement à terre l’édifice de la sécurité > informatique par certificat. Oui : et également la confiance en l'économie numérique. On sait tous que ça tient sur un château de carte. Je ne suis pas convaincu qu'il faille tout faire planter. > >> Il faudrait également savoir comment les responsables de l'AC intermédiaire >> ont pu signer un certificat de pour google ou gmail. > C’est une partie du n’importe quoi dont je parle. J’ose pas espérer, mais une > petite plainte contre X des personnels de l'administration ou de son syndicat > ferait avancer les choses pour réduire la surveillance et le sentiment de > liberté totale des administrations et des entreprises sur les informations > privées des personnes. Je ne suis pas convaincu que ce soit une infraction pénale. > > Kavé Salamatian >> >> 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/
smime.p7s
Description: Signature cryptographique S/MIME
