Re: [FRnOG] [ALERT] IGC/A et google
Bonjour la liste, D'un point de vue juridique, l'intercept SSL n'est pas illégal si c'est pour protéger le réseau et ne rentre pas sous le coup du 226-15 du code pénal qui énonce que Le fait, commis de mauvaise foi, d'ouvrir, de supprimer, de retarder ou de détourner des correspondances arrivées ou non à destination et adressées à des tiers, ou d'en prendre frauduleusement connaissance, est puni d'un an d'emprisonnement et de 45000 euros d'amende. Est puni des mêmes peines le fait, commis de mauvaise foi, d'intercepter, de détourner, d'utiliser ou de divulguer des correspondances émises, transmises ou reçues par la voie des télécommunications ou de procéder à l'installation d'appareils conçus pour réaliser de telles interceptions. En effet, la jurisprudence précise que : Ne constituent pas une interception la lecture et la retranscription de messages dès lors que celles-ci ne nécessitent ni dérivation ou branchement et sont effectuées sans artifice ni stratagème; il est dans la fonction des administrateurs de réseaux d'assurer le fonctionnement normal de ceux-ci ainsi que leur sécurité, ce qui entraîne, entre autre, qu'ils aient accès aux messageries et à leur contenu, ne serait-ce que pour les débloquer ou éviter des démarches hostiles; il apparaît des éléments du dossier que les prévenus (le directeur du laboratoire de recherche et l'administrateur du réseau) ont mis en place une surveillance afin de connaître le contenu des correspondances émises ou reçues par un étudiant en relation avec des incidents survenus entre celui-ci et un autre étudiant ainsi que pour vérifier l'usage du réseau; il s'agissait bien d'utiliser le contenu même des correspondances pour confondre l'étudiant; la préoccupation de la sécurité du réseau justifie que les administrateurs de systèmes et de réseaux fassent usage de leurs positions et des possibilités techniques dont ils disposent pour mener les investigations et prendre les mesures que cette sécurité impose (de la même façon que la Poste doit réagir à un colis ou une lettre suspecte); par contre la divulgation du contenu de messages d'un étudiant ne relève pas de ces objectifs. ● Paris, 17 déc. 2001: D. 2002. IR 941. L'arrêt parle de courriels, mais ça s'appliquerait à tout ce qui passe par les tuyaux. Autrement dit : vérifier pour protéger le réseau est autorisé si c'est fait sans artifice ni stratagème. Par contre, se prendre pour un enquêteur est interdit. A+ smime.p7s Description: Signature cryptographique S/MIME
Re: [FRnOG] [ALERT] IGC/A et google
Pour ceux qui l'aurait pas lu : http://www.pcinpact.com/news/84830-blocage-certificats-par-google-interview-patrick-pailloux-anssi.htm?utm_source=PCi_RSS_Feedutm_medium=newsutm_campaign=pcinpact David Le 10 décembre 2013 15:58, Raphaël Stehli experti...@raphael.stehli.fr a écrit : Bonjour la liste, D'un point de vue juridique, l'intercept SSL n'est pas illégal si c'est pour protéger le réseau et ne rentre pas sous le coup du 226-15 du code pénal qui énonce que Le fait, commis de mauvaise foi, d'ouvrir, de supprimer, de retarder ou de détourner des correspondances arrivées ou non à destination et adressées à des tiers, ou d'en prendre frauduleusement connaissance, est puni d'un an d'emprisonnement et de 45000 euros d'amende. Est puni des mêmes peines le fait, commis de mauvaise foi, d'intercepter, de détourner, d'utiliser ou de divulguer des correspondances émises, transmises ou reçues par la voie des télécommunications ou de procéder à l'installation d'appareils conçus pour réaliser de telles interceptions. En effet, la jurisprudence précise que : Ne constituent pas une interception la lecture et la retranscription de messages dès lors que celles-ci ne nécessitent ni dérivation ou branchement et sont effectuées sans artifice ni stratagème; il est dans la fonction des administrateurs de réseaux d'assurer le fonctionnement normal de ceux-ci ainsi que leur sécurité, ce qui entraîne, entre autre, qu'ils aient accès aux messageries et à leur contenu, ne serait-ce que pour les débloquer ou éviter des démarches hostiles; il apparaît des éléments du dossier que les prévenus (le directeur du laboratoire de recherche et l'administrateur du réseau) ont mis en place une surveillance afin de connaître le contenu des correspondances émises ou reçues par un étudiant en relation avec des incidents survenus entre celui-ci et un autre étudiant ainsi que pour vérifier l'usage du réseau; il s'agissait bien d'utiliser le contenu même des correspondances pour confondre l'étudiant; la préoccupation de la sécurité du réseau justifie que les administrateurs de systèmes et de réseaux fassent usage de leurs positions et des possibilités techniques dont ils disposent pour mener les investigations et prendre les mesures que cette sécurité impose (de la même façon que la Poste doit réagir à un colis ou une lettre suspecte); par contre la divulgation du contenu de messages d'un étudiant ne relève pas de ces objectifs. ● Paris, 17 déc. 2001: D. 2002. IR 941. L'arrêt parle de courriels, mais ça s'appliquerait à tout ce qui passe par les tuyaux. Autrement dit : vérifier pour protéger le réseau est autorisé si c'est fait sans artifice ni stratagème. Par contre, se prendre pour un enquêteur est interdit. A+ -- David --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
Bonjour, Maintenant, dans le cas ou les employes sont prévenus et que le contenu des messages n’est pas loggué, je ne vois pas ce qu’il y a de choquant !!! N’oublions pas que lorsque nous faisons des stats sur les IP destinations dans des grands groupes Facebook arrive en tete a 10h le matin !!! Trop de contrôle c’est la dictature mas pas de contrôle c’est le borde……. Pourquoi décortiquer des paquets à l’aide de MITM dans ce cas précis ? Il suffit de bloquer si il n’y a pas d’utilisation pro, tout simplement … Décortiquer le SSL pour s’assurer qu’il n’est pas utilisé à des fins de VPN, ou pour protéger les échanges de virus vers des centres de contrôle (par exemple) - oui, mais Facebook je ne vois pas le rapport. Mathieu --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
Le 08/12/2013 23:44, Raphaël Stehli a écrit : 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. Après quelques recherches google, j'ai trouvé les informations suivantes, pistes pour les articles de loi http://open.arkoon.net/aoc/l-ere-de-l-analyse-protocolaire-quid-des-flux-cryptes-ssl http://www.legalis.net/?page=jurisprudence-decisionid_article=1182 Le problème de l'interception SSL que tous les acteurs offrent dorenavant dans leurs produits ne semble pas être un problème juridique simple. Florent Nolot Université de Reims Champagne-Ardenne --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
On 09.12.2013 10:05, MM wrote: Décortiquer le SSL pour s’assurer qu’il n’est pas utilisé à des fins de VPN, ou pour protéger les échanges de virus vers des centres de contrôle (par exemple) - oui, mais Facebook je ne vois pas le rapport. dans la catégorie course a l'échalotte a empecher le montage de vpn, on peut jouer hein... un peu de steganographie par ci, de l'encapsulation a la con par la... --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
On 12/08/2013 11:53 PM, Bruno Tréguier wrote: Bonsoir, Le 08/12/2013 à 21:06, Raphaël Stehli a écrit : Il faudrait également savoir comment les responsables de l'AC intermédiaire ont pu signer un certificat de pour google ou gmail. Techniquement parlant, une AC intermédiaire peut signer ce qu'elle veut, tout comme une AC racine... Après, du point de vue des procédures, il y a un hic, c'est sûr. Techniquement parlant que je pense que l'attribut NameConstraint de la RFC5280 est la pour ça. Maintenant, ma compréhension est que son non support dans les ancien navigateurs l'a fait marquer non-critique ce qui rends son intérêt bien moindre. Cordialement, -- Christophe Renard Hervé Schauer Consultants (HSC) signature.asc Description: OpenPGP digital signature
Re: [FRnOG] [ALERT] IGC/A et google
On Sun, Dec 8, 2013, at 19:48, Surya ARBY wrote: 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). Le fait que c'est techniquement possible ne veut pas dire qu'il faut faire ca. Autre les aspects juridiques que Kave a deja evoque plus haut, il y a l'aspect confiance dans la chaine de certification qui est attaque par des tels procedures. Bref si on a des problemes avec l'utilisation du SSL: - on a la clef prive de la destination et on fait ce qu'on veut avec le traffic (generalement valable uniquement pour les sites internes) - on regarder ce qu'on peut pour prendre une decision (accept ou block). Generallement ca se limite aux donnees presentes dans le certif (CN, signed by, O/OU, date d'expiration) parfois un peu plus (HTTP_Host si SNI), mais ca ne concerne jamais traffic crypte. - on prend la decision de bloquer ou non uniquement sur des criteres non-lies au payload (IP dest, port TCP, ) La MITM SSL , il faut eviter de l'utiliser, meme s'il y a de plus en plus de constructeurs qui la proposent. Imagine juste ce que ca peut donner si pour le bien du client les FAI se mettent a faire ca. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
Bonjour, 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) La solution a déployer serait plutôt un DANE vraiment intégré dans les navigateurs, seul bémol, ça dépends de DNSSEC et DNSSEC c'est bien mais c'est pas effortless a intégrer... Hélas :( Xavier -- Xavier Beaudouin --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
On Sun, Dec 8, 2013, at 21:06, Raphaël Stehli wrote: 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, Faut voir le probleme sous un autre angle. Supposons le scenario suivant, qui n'est pas tout a fait a cote de la realite: - 1 PME a 250 personnes chaque (en moyenne) deployent du SSL intercept. - Ca fait ~2 500 000 personnes qui pendant 35-40 heures par semaine ne voyent plus qu'une seule CA qui signe TOUS les certifs SSL du monde - Ils ne voyent pas tous la meme CA, mais le temps d'etre salaries d'une seule societe ils voyent systematiquement la meme CA. - du coup, les certificats EV n'existent plus. - il y a parfois des rates dans les services informatiques de certaines entreprises (globalement, sur les 1 PME, je dirais assez souvent). Pendant ces rates, les gens ont des SSL warning, dont le service IT leur dit pas de probleme. - les 2 500 000 personnes surfent chez eux, avec leurs ordinateurs sur des sites parfois douteux. Parfois ce sites sont en SSL, avec des faux cetifs. - BONUS : rajouter au lot 100 grands groupes a 5000 personens en moyenne (total, encore 500 K personnes, voire plus). - Comment voulez-vous que les 2 500 000 personnes reagissent devant un vrai faux certif (lire frauduleux) quand ils passent pas mal de leur temps devant des certifs re-signes ? Est-ce que par la meme logique on peut dire que pour un service B2B c'est meme pas la peine d'acheter un vrai certificat, car la plupart des utilisateurs risquent de passe par des soi-disant boities de securite qui font du SSL Intercept ? Oui, la technique permet de faire ca, mais il faut avoir quand-meme un peu de discernement dans l'utilisation. La soi-disant securite de nos jours me fait penser a la course a l'armement nucleaire d'il y a pas si longtemps que ca. Si vous ne savez pas ce qu'est, demandez a vos parents/grand-parents. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
On Sun, Dec 8, 2013, at 22:30, Yann Vercucque wrote: 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. Il est tenu juridiquement d'aller jusqu'au ou ? On fait quoi de SSL-VPN ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
On Sun, Dec 8, 2013, at 22:46, Kavé Salamatian wrote: 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. ce qui est largement faisable meme en mode TAP/SPAN . --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
On Mon, Dec 9, 2013, at 10:05, MM wrote: Décortiquer le SSL pour s’assurer qu’il n’est pas utilisé à des fins de VPN, ou pour protéger les échanges de virus vers des centres de contrôle En occurence comment expliques-tu a un de tes partennaires que son flux VPN vers son entreprise, fait avec son identifiant est intercepte ? En clair/decrypte ? --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
On Mon, Dec 9, 2013, at 15:50, Yann Vercucque wrote: Il faut arrêter d'aller dans tout les sens... Une interception SSL peut ce faire sur certain flux, pas sur une page d'authentification VPN, par exemple (techniquement faisable mais sans intérêt) Generalement tu interceptes avant de savoir ce que tu as intercepte. Les autorisations fine-grained vers internet NE MARCHENT PAS !!! Meme si la technologie existe, la gestion c'est un echec a plus de 99% des cas. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
La majorité des équipements rendant possible l'utilisation de l'interception SSL, permettent d'appliquer du deep inspection sur des flux précis (de Hotspot vers internet, par exemple) de même il possible de définir que ce n'est uniquement les flux à destination du port 443 qui seront deep inspecté. Yann, Le 9 déc. 2013 à 16:00, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net a écrit : On Mon, Dec 9, 2013, at 15:50, Yann Vercucque wrote: Il faut arrêter d'aller dans tout les sens... Une interception SSL peut ce faire sur certain flux, pas sur une page d'authentification VPN, par exemple (techniquement faisable mais sans intérêt) Generalement tu interceptes avant de savoir ce que tu as intercepte. Les autorisations fine-grained vers internet NE MARCHENT PAS !!! Meme si la technologie existe, la gestion c'est un echec a plus de 99% des cas. --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
Beacoup de VPN utilisent précisément le port 443 ! (Cisco AnyConnect par exemple) Kavé Salamatian Le 9 déc. 2013 à 16:25, Yann Vercucque yann.vercuc...@gmail.com a écrit : La majorité des équipements rendant possible l'utilisation de l'interception SSL, permettent d'appliquer du deep inspection sur des flux précis (de Hotspot vers internet, par exemple) de même il possible de définir que ce n'est uniquement les flux à destination du port 443 qui seront deep inspecté. Yann, Le 9 déc. 2013 à 16:00, Radu-Adrian Feurdean fr...@radu-adrian.feurdean.net a écrit : On Mon, Dec 9, 2013, at 15:50, Yann Vercucque wrote: Il faut arrêter d'aller dans tout les sens... Une interception SSL peut ce faire sur certain flux, pas sur une page d'authentification VPN, par exemple (techniquement faisable mais sans intérêt) Generalement tu interceptes avant de savoir ce que tu as intercepte. Les autorisations fine-grained vers internet NE MARCHENT PAS !!! Meme si la technologie existe, la gestion c'est un echec a plus de 99% des cas. --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
Bonsoir, Le 09/12/2013 14:56, Xavier Beaudouin écrivit : Le 08/12/2013 20:33, Jean-Yves Faye a écrit : 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) La solution a déployer serait plutôt un DANE vraiment intégré dans les navigateurs, seul bémol, ça dépends de DNSSEC et DNSSEC c'est bien mais c'est pas effortless a intégrer... Hélas :( Je me dis que les gens qui déploient du SSL Intercept vont pas être tentés de déployer des résolveurs validants sur leur réseau si ça casse leur jouet :-) Et souvent en entreprise, l'on est pas administrateur de la machine, donc va changer le résolveur DNS ou installer un unbound local… -- Cyprien --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
Bruno Tréguier Techniquement parlant, une AC intermédiaire peut signer ce qu'elle veut, tout comme une AC racine... Après, du point de vue des procédures, il y a un hic, c'est sûr. J'arrive un peu tard dans la conversation, mais juste pour préciser qu'une AC ne peut pas signer ce qu'elle veut. Quand une AC signe quelque chose, elle définie précisément quels sont les droits de ce quelque chose. ex: une SubCA, un certificat serveur, un certificat client, une signature de code, un certificat mail, une CRL, etc... RFC: http://tools.ietf.org/html/rfc5280#section-4.2.1.9 Alexandre Pierret 2013/12/8 Bruno Tréguier bruno.tregu...@shom.fr: Bonsoir, Le 08/12/2013 à 21:06, Raphaël Stehli a écrit : Il faudrait également savoir comment les responsables de l'AC intermédiaire ont pu signer un certificat de pour google ou gmail. Techniquement parlant, une AC intermédiaire peut signer ce qu'elle veut, tout comme une AC racine... Après, du point de vue des procédures, il y a un hic, c'est sûr. Cordialement, Bruno -- - Service Hydrographique et Oceanographique de la Marine - DMGS/INF - 13, rue du Chatellier - CS 92803 - 29228 Brest Cedex 2, FRANCE - Phone: +33 2 98 22 17 49 - Email: bruno.tregu...@shom.fr --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
Le 09/12/2013 à 22:57, Alexandre PIERRET a écrit : Bruno Tréguier Techniquement parlant, une AC intermédiaire peut signer ce qu'elle veut, tout comme une AC racine... Après, du point de vue des procédures, il y a un hic, c'est sûr. J'arrive un peu tard dans la conversation, mais juste pour préciser qu'une AC ne peut pas signer ce qu'elle veut. Quand une AC signe quelque chose, elle définie précisément quels sont les droits de ce quelque chose. ex: une SubCA, un certificat serveur, un certificat client, une signature de code, un certificat mail, une CRL, etc... Bonsoir, En effet, j'ai peut-être été un peu trop général (ou amiral pour les marins ;-) ). En théorie, il y a aussi le Name Constraints (RFC 5280, section 4.2.1.10), dont a déjà parlé Stéphane Bortzmeyer un peu plus haut dans le fil, mais comme il le dit, cette fonction est très peu mise en oeuvre (la preuve), donc dans les faits, rien n'empêche une AC intermédiaire de signer un certificat avec un Subject Name quelconque. C'est d'ailleurs bien ce qui s'est passé dans le cas présent, et c'est la raison pour laquelle des choses comme le Public Key Pinning ou le protocole DANE présentent un intérêt (protection contre les AC compromises, etc.). Cordialement, Bruno Tréguier -- - Service Hydrographique et Oceanographique de la Marine - DMGS/INF - 13, rue du Chatellier - CS 92803 - 29228 Brest Cedex 2, FRANCE - Phone: +33 2 98 22 17 49 - Email: bruno.tregu...@shom.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
A priori il y’a des outils qui sont vendus afin d’intercepter des connexions SSL sortantes et de vérifier leur contenu. Une administration liée au ministère des finances à voulu « tester » cette solution sur du trafic gmail. Pour ceci il faut forger un certificat de google (tout comme n’importe quel vulgaire voleur d’identité par phishing ou comme des gouvernement dictatoriaux voulant volant les logins de leurs nationaux à des services sécurisé). Le certificat a été forgé par une sous-autorité de certification rattaché à l’ANSSI et Ils se sont fait prendre la main dans le pot de confiture. Montrant l’amateurisme en vigueur ….. Kavé Salamatian Le 8 déc. 2013 à 16:31, Raphaël Stehli experti...@raphael.stehli.fr a écrit : Bonjour la liste, Après plusieurs mois de lecture, il s'agit de ma première intervention. - Le Monde vient de publier un article Google bloque des certificats de sécurité Internet émis par une autorité française http://abonnes.lemonde.fr/technologies/article/2013/12/08/google-bloque-des-certificats-de-securite-internet-emis-par-une-autorite-francaise_3527535_651865.html - l'ANSSI a publié un communiqué de presse Suppression d’une branche de l’IGC/A http://www.ssi.gouv.fr/fr/menu/actualites/suppression-d-une-branche-de-l-igc-a.html où il est fait mention que Suite à une erreur humaine lors d’une action de renforcement de la sécurité au ministère des finances, des certificats numériques correspondant à des domaines extérieurs à l’administration française ont été signés par une autorité de certification de la direction générale du Trésor rattachée à l’IGC/A. - Google indique dans un communiqué http://googleonlinesecurity.blogspot.it/2013/12/further-improving-digital-certificate.html?m=1 que le problème est sérieux. Quelqu'un aurait-il des informations sur ce qui s'est passé ? Bien cordialement, Raphaël Stehli -- Raphaël Stehli, Fonctionnaire détaché en cycle préparatoire de l'ENA, Chargé d'enseignement vacataire à l'Université de Strasbourg, --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
Bonjour 1-pourquoi ils se font fait prendre? Google a detecté le « man in the middle » 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). 3- grosso modo, forger un certificat de google par une autorité de certif relève de la faute grave. L’excuse « Oups, je me suis fait pirater » aurait été plus acceptable que l’excuse « on a fait une erreur de manip ». Car pour faire une erreur de manip il faut en faire beaucoup pour arriver à mettre un certificat google dans la nature. Bref, l’administration en question et l’ANSSI sont méchamment dans le fumier (pour ne pas dire dans le caca :-). Kavé Salamatian Le 8 déc. 2013 à 19:13, Marc Abel fr...@harrydico.net a écrit : Bonjour, Je comprends pas bien pourquoi ils se sont fait prendre : pour intercepter les flux ssl l'employeur annonce à tout le personnel ce qu'il va faire, qu'on est pas à la maison mais au boulot, que le pare-feu va inspecter les messages et donc les certificats seront ceux du boulot (comme on accepte déjà le certificat de la messagerie), pour se faire passer pour google ou autre il faut avoir envie de faire ça en douce, à l'insu des utilisateurs, est-ce concevable ? Marc, (dans l'administration mais pas aux finances) - Original Message - From: Kavé Salamatian kave.salamat...@univ-savoie.fr To: Raphaël Stehli experti...@raphael.stehli.fr Cc: frnog-al...@frnog.org Sent: Sunday, December 08, 2013 4:38 PM Subject: Re: [FRnOG] [ALERT] IGC/A et google A priori il y’a des outils qui sont vendus afin d’intercepter des connexions SSL sortantes et de vérifier leur contenu. Une administration liée au ministère des finances à voulu « tester » cette solution sur du trafic gmail. Pour ceci il faut forger un certificat de google (tout comme n’importe quel vulgaire voleur d’identité par phishing ou comme des gouvernement dictatoriaux voulant volant les logins de leurs nationaux à des services sécurisé). Le certificat a été forgé par une sous-autorité de certification rattaché à l’ANSSI et Ils se sont fait prendre la main dans le pot de confiture. Montrant l’amateurisme en vigueur ….. Kavé Salamatian Le 8 déc. 2013 à 16:31, Raphaël Stehli experti...@raphael.stehli.fr a écrit : Bonjour la liste, Après plusieurs mois de lecture, il s'agit de ma première intervention. - Le Monde vient de publier un article Google bloque des certificats de sécurité Internet émis par une autorité française http://abonnes.lemonde.fr/technologies/article/2013/12/08/google-bloque-des-certificats-de-securite-internet-emis-par-une-autorite-francaise_3527535_651865.html - l'ANSSI a publié un communiqué de presse Suppression d’une branche de l’IGC/A http://www.ssi.gouv.fr/fr/menu/actualites/suppression-d-une-branche-de-l-igc-a.html où il est fait mention que Suite à une erreur humaine lors d’une action de renforcement de la sécurité au ministère des finances, des certificats numériques correspondant à des domaines extérieurs à l’administration française ont été signés par une autorité de certification de la direction générale du Trésor rattachée à l’IGC/A. - Google indique dans un communiqué http://googleonlinesecurity.blogspot.it/2013/12/further-improving-digital-certificate.html?m=1 que le problème est sérieux. Quelqu'un aurait-il des informations sur ce qui s'est passé ? Bien cordialement, Raphaël Stehli -- Raphaël Stehli, Fonctionnaire détaché en cycle préparatoire de l'ENA, Chargé d'enseignement vacataire à l'Université de Strasbourg, --- 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/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
Le problème est le suivant : - l'IGC/A interdit dans sa politique la signature de tiers à l'administration http://www.ssi.gouv.fr/fr/anssi/services-securises/igc-a/ - les certificats IGC/A sont (ou étaient) installés par défaut dans les magasins des principaux clients La signature illégitime d'un certif par une AC dont l'ACR est par défaut dans tous les navigateurs et permettrait d'intercepter toutes les connexions, même hors de l'administration concernée. Quand un employeur veut lire le flux SSL des postes de ses agents ou employés, il se fait un certificat maison et l'intègre au master ou aux postes déjà en service. Google surveille les certificats depuis le problème qui a eu lieu en Tunisie : ils se sont fait prendre comme ça. Cordialement, Raphaël Stehli Le 08/12/2013 19:13, Marc Abel a écrit : Bonjour, Je comprends pas bien pourquoi ils se sont fait prendre : pour intercepter les flux ssl l'employeur annonce à tout le personnel ce qu'il va faire, qu'on est pas à la maison mais au boulot, que le pare-feu va inspecter les messages et donc les certificats seront ceux du boulot (comme on accepte déjà le certificat de la messagerie), pour se faire passer pour google ou autre il faut avoir envie de faire ça en douce, à l'insu des utilisateurs, est-ce concevable ? Marc, (dans l'administration mais pas aux finances) - Original Message - From: Kavé Salamatian kave.salamat...@univ-savoie.fr To: Raphaël Stehli experti...@raphael.stehli.fr Cc: frnog-al...@frnog.org Sent: Sunday, December 08, 2013 4:38 PM Subject: Re: [FRnOG] [ALERT] IGC/A et google A priori il y’a des outils qui sont vendus afin d’intercepter des connexions SSL sortantes et de vérifier leur contenu. Une administration liée au ministère des finances à voulu « tester » cette solution sur du trafic gmail. Pour ceci il faut forger un certificat de google (tout comme n’importe quel vulgaire voleur d’identité par phishing ou comme des gouvernement dictatoriaux voulant volant les logins de leurs nationaux à des services sécurisé). Le certificat a été forgé par une sous-autorité de certification rattaché à l’ANSSI et Ils se sont fait prendre la main dans le pot de confiture. Montrant l’amateurisme en vigueur ….. Kavé Salamatian Le 8 déc. 2013 à 16:31, Raphaël Stehli experti...@raphael.stehli.fr a écrit : Bonjour la liste, Après plusieurs mois de lecture, il s'agit de ma première intervention. - Le Monde vient de publier un article Google bloque des certificats de sécurité Internet émis par une autorité française http://abonnes.lemonde.fr/technologies/article/2013/12/08/google-bloque-des-certificats-de-securite-internet-emis-par-une-autorite-francaise_3527535_651865.html - l'ANSSI a publié un communiqué de presse Suppression d’une branche de l’IGC/A http://www.ssi.gouv.fr/fr/menu/actualites/suppression-d-une-branche-de-l-igc-a.html où il est fait mention que Suite à une erreur humaine lors d’une action de renforcement de la sécurité au ministère des finances, des certificats numériques correspondant à des domaines extérieurs à l’administration française ont été signés par une autorité de certification de la direction générale du Trésor rattachée à l’IGC/A. - Google indique dans un communiqué http://googleonlinesecurity.blogspot.it/2013/12/further-improving-digital-certificate.html?m=1 que le problème est sérieux. Quelqu'un aurait-il des informations sur ce qui s'est passé ? Bien cordialement, Raphaël Stehli -- Raphaël Stehli, Fonctionnaire détaché en cycle préparatoire de l'ENA, Chargé d'enseignement vacataire à l'Université de Strasbourg, --- 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/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
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/
Re: [FRnOG] [ALERT] IGC/A et google
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/
Re: [FRnOG] [ALERT] IGC/A et google
le problème n’est pas le SSL intercept ou un problème technique. Le problème est de « fake »r un certificat d’une entité externe. C’est pas parce que c’es techniquement possible qu’il est acceptable de le faire. Un peu d’éthique est bonne dans toute chose :-) Une petite recherche google donne : L’article L.323-1 du Nouveau code pénal prévoit que « le fait d’accéder ou de se maintenir, frauduleusement, dans tout ou partie d’un système de traitement automatisé de données est puni d’un an d’emprisonnement et de 15 000 euros d’amende ». Ces systèmes comprennent, entre autre, les sites web. La Cour d’appel de Paris a considéré dans un arrêt du 5 avril 1994 que « l’accès frauduleux, au sens de la loi, vise tous les modes de pénétration irréguliers d’un système de traitement automatisé de données, que l’accédant travaille déjà sur la même machine mais à un autre système, qu’il procède à distance ou qu’il se branche sur une ligne de communication Faire un MITM sur un transfert avec une entité externe est bien une pénétration irrégulière d’un système de traitement automatisé en se branchant (par proxy) sur une ligne de communication. Je suis sur qu’un bon juriste trouverait fouletitude d’autres arguments juridiques. En résumé, que vous faisiez un SSL intercept sur une communication encrypté interne ça peut passer ( à vérifier avec les détails) mais que vous le faisiez sur un transfert qui va vers une entité externe (google, Facebook, banque, etc…) c’est du piratage caractérisé. Vous le faites, prenez un parachute et un paratonnerre avec vous :-). A ma connaissance même la NSA ne le fait pas :-) Bon c’est plus facile pour eu ils accèdent directement les données non-cryptées après stockage :-) Kavé Salamatian Le 8 déc. 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/
Re: [FRnOG] [ALERT] IGC/A et google
Bah non. Que ça soit en interne ou en externe faire un MITM sur un transfert externe est problématique. Que ça soit dans l’administration ou pas (sauf exception genre l’armée ou autorisation de l’autorité judiciaire) et dans ce cas l’information recueillie est un scellé. Kavé Salamatian Le 8 déc. 2013 à 20:33, Jean-Yves Faye jy0...@gmail.com 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/
Re: [FRnOG] [ALERT] IGC/A et google
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:
Re: [FRnOG] [ALERT] IGC/A et google
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
Re: [FRnOG] [ALERT] IGC/A et google
Bonjour, Je suis la discussion avec intérêt depuis un moment. Effectivement, la pratique de MITM est connue et simple à réaliser, ce qui est inédit est qu’une autorité de certification génère un certificat … et se fasse choper surtout. Par contre, auriez-vous des précisions sur cette histoire de hotspot invité ? Quels sont les textes - depuis quand datent-t-ils ? J’ai vu des solutions d’hôtel, ils ne loguent rien du traffic (rien de brut, de mémoire il y a les connexions par contre). De même en entreprise, je n’ai jamais rien vu de logué sur les connexion invités (elles étaient simplement isolées du réseau classique / restreint à certaines utilisations). Je doute que le McDo logue grand chose, tout comme le réseau invité sur les freebox (peut être que dans ce cas la connexion n’est pas considérée comme anonyme car requérant un identifiant lié à une connexion) Déjà l’année de log a fait plaisir à tout le mode, j’imagine ce que peut donner cette loi … Merci par avance pour les éclaircissements. Mathieu 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. 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, --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
Le 8 déc. 2013 à 22:53, Alexandre Archambault aarchamba...@corp.free.fr a écrit : 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é Non. Tenus de conserver les données de connexion (en gros à quel était l’utilisateur correspondant à telle IP), oui, quel que soit d’ailleurs le statut de celui qui met à disposition l’accès. Mais en aucun cas l’usage qui est fait de cette connexion n’a à être loggé. Je précise juste que, contrairement à ce qu’on peut lire ici ou là que le log des données de navigation (ou l’intégralité des flux web comme vous dites) est à ce stade prohibé (cf. art. L.34-1 CPCE VI 2nd alinéa), en tout cas pour un réseau ouvert au public. +1 — Alec, --- Liste de diffusion du FRnOG http://www.frnog.org/ --- Liste de diffusion du FRnOG http://www.frnog.org/
Re: [FRnOG] [ALERT] IGC/A et google
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, Oui a condition que rien en dehors de l’adresse IP SRC/DST en mode anonymisé ne soit enregistré. - 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. Les fins internes autorisés ne sont que l’amélioration du service. Mes faibles connaissances juridique m’amène a penser qu’on ne peut justifier après coup la légalité d’un acte de procédure. Ca s’appelle un vice de procédure et aboutit à l’annulation de la pièce. 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 : pas autant que ça. - 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), et elles sont sures de ne pas se faire pirater :-). Aller dire ça à adobe, Sony et d’autres :-). - 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. - 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. Donc, même en cas de vol de la clé, l'entreprise devrait voir sa responsabilité fortement minorée. Ca dépend de la qualité des avocats de la partie adverse. 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. 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. 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 à
Re: [FRnOG] [ALERT] IGC/A et google
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
Re: [FRnOG] [ALERT] IGC/A et google
Bonsoir, Le 08/12/2013 à 21:06, Raphaël Stehli a écrit : Il faudrait également savoir comment les responsables de l'AC intermédiaire ont pu signer un certificat de pour google ou gmail. Techniquement parlant, une AC intermédiaire peut signer ce qu'elle veut, tout comme une AC racine... Après, du point de vue des procédures, il y a un hic, c'est sûr. Cordialement, Bruno -- - Service Hydrographique et Oceanographique de la Marine - DMGS/INF - 13, rue du Chatellier - CS 92803 - 29228 Brest Cedex 2, FRANCE - Phone: +33 2 98 22 17 49 - Email: bruno.tregu...@shom.fr --- Liste de diffusion du FRnOG http://www.frnog.org/
