Blocage des certificats par Google : interview de Patrick Pailloux (ANSSI)

Blocage des certificats par Google : interview de Patrick Pailloux (ANSSI)

Certificats locaux vs IGC/A

Avatar de l'auteur
Marc Rees

Publié dans

Logiciel

10/12/2013 6 minutes
69

Blocage des certificats par Google : interview de Patrick Pailloux (ANSSI)

Google a dénoncé sur son blog dédié à la sécurité un problème de certificat ce 3 décembre. L’entreprise américaine a bloqué plusieurs certificats non autorisés visant ses domaines, émis par une autorité de certification en relation avec l’ANSSI. Pour faire le point, Patrick Pailloux, directeur général de l’Agence nationale des systèmes d'information, a bien voulu répondre à plusieurs de nos questions.

Google a indiqué ce week-end avoir bloqué une liste de plusieurs certificats corrompus dans Chrome, dénonçant « une violation grave » du dispositif et mettant en cause une autorité en liaison avec l'ANSSI. De son côté, celle-ci a expliqué sur son site ce problème, évoquant une « erreur humaine lors d’une action de renforcement de la sécurité au ministère des Finances ».

 

pailloux anssi

Pouvez-vous nous résumer le mécanisme de certification ?

Sur internet, il y a des systèmes qui visent à authentifier les sites de confiance. Les certificats permettent aux différents navigateurs de reconnaître qu’on est en face d’un partenaire de confiance via du trafic par HTTPS. Toute l’astuce est que les trois principaux navigateurs, Internet Explorer, Firefox et Chrome, reconnaissent un certain nombre d’autorités de certification comme de confiance et donc pouvant délivrer des certificats qu’eux-mêmes vont reconnaître.

 

Dans ces autorités de certification, vous avez quantité de gens, des entreprises privées, quelques États. La plus grosse entreprise c’est Verisign. L’État français le fait aussi avec l’ANSSI à la tête d’un dispositif qui se nomme l’IGC/A (infrastructure de gestion de clés cryptographiques, NDLR) Tout repose donc sur la confiance qu’on peut avoir dans les autorités de certifications. Les trois principaux acteurs que sont Microsoft, la Fondation Mozilla et Google ont des politiques d’acceptation. Chaque autorité de certification doit donc démontrer à ces éditeurs qu’ils sont des gens sérieux, via des politiques de certifications et des audits.

 

S’agissant de l’État français, nous avons une IGC centrale pour délivrer des certifications au profit des agents de l’État, mais aussi pour les serveurs des sites d’administrations dont les services fiscaux. Cette mécanique s’appuie sur système de délégation : l’ANSSI a une IGC centrale qu’elle délègue aux ministères lesquels peuvent eux-mêmes déléguer à leurs directions qui sont en capacité de délivrer des certificats.

Que s’est-il passé exactement ce week-end ?

La direction générale du Trésor est particulièrement sensibilisée aux attaques informatiques, compte tenu de ce qu’elle a vécu (voir ce cas de piratage, NDLR). Le service informatique a donc mis en place un WAF, web application firewall, pratique classique pour contrôler le trafic interne et sortant afin de savoir s’il n’y a pas d’attaque. Pour faire cela, vous avez besoin de certificats. La méthode classique est d’utiliser des certificats locaux qui ne sont pas reconnus et qui n’ont de valeur que dans le réseau interne. Or, ils ont utilisé l’IGC/A pour signer ces certificats. C’est là qu’est l’erreur et ce qui s’est passé concrètement.

Et ensuite ?

Google, qui a détecté cela, a informé Microsoft et la Fondation Mozilla. Quand on a été prévenu, on a assez rapidement trouvé l’origine du dispositif qui a été supprimé. Nous avons par ailleurs coupé la branche de l’IGC/A concernée. Maintenant, on est en train de prendre un certain nombre de mesures tout en jouant la transparence : une erreur a été faite, tout le dispositif reposant sur la confiance, il s’agit pour nous d’expliquer ce qui s’est passé. Nous sommes en train par ailleurs de vérifier – nous avons presque fini - qu’il n’y a pas d’autres cas dans l’administration. Nous lançons aussi une campagne d’audit pour savoir si les certifications sont bien appliquées. Enfin, à moyen terme, nous regardons si notre architecture technique est bonne ou s’il faut l’adapter.

Comment Google a-t-il détecté cette manipulation ?

Objectivement, on ne s’est pas concentré sur cela.

Quels sites Google étaient en cause ?

On n’a pas regardé dans le détail la liste des certificats, on a coupé l’ensemble. Il y a eu probablement eu plusieurs, mais ils ne sont pas sortis et sont restés à l’intérieur du réseau. En théorie, il n’y a pas de dégât.

Il a été évoqué un risque d’attaque par Man in the middle…

On parle d’attaque par Man in the Middle car c’est la technique utilisée dans le WAF où on regarde le trafic à l’intérieur. Ce qu’on craint beaucoup dans ce genre d’affaires, c’est surtout une corruption de l’infrastructure de gestion de clefs, c’est-à-dire des attaquants qui se font signer des certificats pour ensuite aller mener des attaques, créer de faux sites reconnus par les navigateurs ou pour faire une attaque par « l’homme du milieu ».

Certains ont aussi tissé un lien entre cet incident et le projet de loi de programmation militaire...

J’ai vu. Franchement, ce qui s’est passé, c’est une erreur informatique. Ils ont mis un serveur de contrôle des flux pour vérifier qu’il n’y avait pas d’attaque et plutôt que de prendre un certificat à valeur locale, ils ont pris un certificat signé par l’IGC/A. C’est l’erreur. C’est tout et cela n’a strictement rien à voir avec tous ces débats.

Il y a tout de même une différence d’appréciation. Vous évoquez une erreur humaine, Google d’un grave problème…

Quelqu’un a fait quelque chose qu’il ne devait pas faire. Comme le dispositif repose sur la confiance – Google, Microsoft, Mozilla ont des politiques de sécurité, ils ont confiance dans un certain nombre de personnes - si quelqu'un ne respecte pas la politique de certification, ils disent que c’est grave. Dans l’absolu, de leur point de vue, je ne peux leur porter complètement tort. Aujourd’hui, cela n’a pas eu de conséquence et ce sont des pratiques qu’il ne faut pas avoir.

 

Merci Patrick Pailloux.

Écrit par Marc Rees

Tiens, en parlant de ça :

Sommaire de l'article

Introduction

Pouvez-vous nous résumer le mécanisme de certification ?

Que s’est-il passé exactement ce week-end ?

Et ensuite ?

Comment Google a-t-il détecté cette manipulation ?

Quels sites Google étaient en cause ?

Il a été évoqué un risque d’attaque par Man in the middle…

Certains ont aussi tissé un lien entre cet incident et le projet de loi de programmation militaire...

Il y a tout de même une différence d’appréciation. Vous évoquez une erreur humaine, Google d’un grave problème…

Fermer

Commentaires (69)




Comment Google a-t-il détecté cette manipulation ?

Objectivement, on ne s’est pas concentré sur cela.



Pourtant ça serait super intéressant de savoir comment ils ont détecté ça.

et bien franchement ça m’étonnerait que l’ANSSI ne s’y intéresse pas. ou en tout ca elle devrait.


Merci Marc pour cette excellente interview. On n’apprend pas grand chose quand on connaît le monde des CA & PKI, mais dans le cas contraire, c’est très bien expliqué et didactique, et réaliste.



On voit à nouveau que le système permettant de faire tenir debout la confiance de HTTPS prend un coup si n’importe qui (ici un sous-fifre d’une administration française) peut produire des certificats pour google.fr, valide sur 100% des navigateurs du monde…)



[publicité] Cela tombe bien, j’ai écrit un article pour le prochain MISC Mag sur le sujet des autorités de certifications ;) il tombe à pic !


Merci pour la mise au point.








hellmut a écrit :



Pourtant ça serait super intéressant de savoir comment ils ont détecté ça.

et bien franchement ça m’étonnerait que l’ANSSI ne s’y intéresse pas. ou en tout ca elle devrait.







l’ANSSI sait pertinemment d’où sort l’info de google :http://blog.cryptographyengineering.com/2013/01/ubiquitous-surveillance-works-le… (en anglais) c’est certaines versions de Chrome qui fayotent (valablement) à Google en cas de certificat signé par la mauvaise autorité, on appelle cela du “certificate pinning”



Très bonne interview ! :-)

La question latente pour moi c’est :



Quelqu’un a fait quelque chose qu’il ne devait pas faire



Est ce qu’il était censé pouvoir le faire ? Ou bien il y as eut une faille de protocole qui lui as permis sans en avoir les droits ?


On en saura donc pas vraiment plus sur l’épineuse question de comment Google a pu détecter l’utilisation d’un certificat signé par une autre Autorité mais utilisé sur un réseau local … <img data-src=" />


Si on voulait savoir si on était surveillé, c’est pas comme ça qu’on s’y serait pris ?

Maintenant on sait ..

Ou j’ai rien compris ( ce qui est très possible <img data-src=" />)


Cette langue de bois…





Comment Google a-t-il détecté cette manipulation ?



Objectivement, on ne s’est pas concentré sur cela.





Et la marmotte… <img data-src=" />








BenjaminSonntag a écrit :



l’ANSSI sait pertinemment d’où sort l’info de google :http://blog.cryptographyengineering.com/2013/01/ubiquitous-surveillance-works-le… (en anglais) c’est certaines versions de Chrome qui fayotent (valablement) à Google en cas de certificat signé par la mauvaise autorité, on appelle cela du “certificate pinning”





Merci.

C’est aussi intéressant de savoir que les gars utilisent Chrome à la Direction Générale du Trésor, après les grosses fuites dont ils ont été victimes (au bénéfice d’on ne sait qui, officiellement les bons vieux hackers Chinois).



Si j’ai bien compris ils ont pris des libertés avec le(s) certificats publiquement reconnu de leur AC. Du point de vue de Google il me semble normal qu’ils trouvent moyen de faire confiance à cette AC.








BenjaminSonntag a écrit :



l’ANSSI sait pertinemment d’où sort l’info de google :http://blog.cryptographyengineering.com/2013/01/ubiquitous-surveillance-works-le… (en anglais) c’est certaines versions de Chrome qui fayotent (valablement) à Google en cas de certificat signé par la mauvaise autorité, on appelle cela du “certificate pinning”







Sauf qu’ils ne sont pas sensés utiliser Chrome, donc oui Chrome dispose de ce mécanisme, mais il semblerait que ce ne soit pas par là que ce soi arrivé chez Google.









BenjaminSonntag a écrit :



l’ANSSI sait pertinemment d’où sort l’info de google :http://blog.cryptographyengineering.com/2013/01/ubiquitous-surveillance-works-le… (en anglais) c’est certaines versions de Chrome qui fayotent (valablement) à Google en cas de certificat signé par la mauvaise autorité, on appelle cela du “certificate pinning”







Peut-être qu’il pensait que leur systèmes de protection empêcherait des fuites d’infos, donc ils ne savent pas comment c’est sorti. <img data-src=" />



Merci pour le lien. <img data-src=" />



Il me semble un peu discutable d’avoir un navigateur qui favorise certains site, même si ce sont ceux de l’éditeur du navigateur en question.









BenjaminSonntag a écrit :



l’ANSSI sait pertinemment d’où sort l’info de google :http://blog.cryptographyengineering.com/2013/01/ubiquitous-surveillance-works-le… (en anglais) c’est certaines versions de Chrome qui fayotent (valablement) à Google en cas de certificat signé par la mauvaise autorité, on appelle cela du “certificate pinning”





En tout cas, ça soulève un problème: seul chrome a un mécanisme de détection des certificats non-attendus sur un nom de domaine. Firefox, IE et Safari font quoi pour ce genre de problème ?









BenjaminSonntag a écrit :



l’ANSSI sait pertinemment d’où sort l’info de google :http://blog.cryptographyengineering.com/2013/01/ubiquitous-surveillance-works-le… (en anglais) c’est certaines versions de Chrome qui fayotent (valablement) à Google en cas de certificat signé par la mauvaise autorité, on appelle cela du “certificate pinning”





Rien ne prouve que celà viennent de là, car même si ils avaient des Chrome chez eux (ce qui craint) j’ose espérer qu’ils crontrôlaient ce qui en sortait (et donc interceptait les rapports sur les certificats entre-autres).



Clairement, ou l’ANSII ment où ils sont incompétents, mais il est ahurissant de dire qu’ils ne se penchent pas sur la question. C’est LA question la plus importante : comment une entreprise américaine totalement sous contrôle de la NSA peut avoir des rapports sur le réseau interne du Trésor ?!



Des têtes doivent tomber.





unCaillou a écrit :



En tout cas, ça soulève un problème: seul chrome a un mécanisme de détection des certificats non-attendus sur un nom de domaine. Firefox, IE et Safari font quoi pour ce genre de problème ?





Ils demandent l’avis de l’utilisateurs avant de fayoter. En tout cas pour IE; pour FF je ne suis plus certain qu’un tel mécanisme soit en place depuis la version 4…









hellmut a écrit :



Pourtant ça serait super intéressant de savoir comment ils ont détecté ça.

et bien franchement ça m’étonnerait que l’ANSSI ne s’y intéresse pas. ou en tout ca elle devrait.





+1 surtout que je la lierai à ça :





Il y a tout de même une différence d’appréciation. Vous évoquez une erreur humaine, Google d’un grave problème…



Quelqu’un a fait quelque chose qu’il ne devait pas faire. Comme le dispositif repose sur la confiance – Google, Microsoft, Mozilla ont des politiques de sécurité, ils ont confiance dans un certain nombre de personnes - si quelqu’un ne respecte pas la politique de certification, ils disent que c’est grave. Dans l’absolu, de leur point de vue, je ne peux leur porter complètement tort. Aujourd’hui, cela n’a pas eu de conséquence et ce sont des pratiques qu’il ne faut pas avoir.



Le grave problème c’est surtout que google ait su. Pas qu’une entreprise publique/privée mette en place un WAF sur un réseau interne, où les utilisateurs/salariés signent normalement une charte informatique leur expliquant cela.





Franchement, ce qui s’est passé, c’est une erreur informatique. Ils ont mis un serveur de contrôle des flux pour vérifier qu’il n’y avait pas d’attaque et plutôt que de prendre un certificat à valeur locale, ils ont pris un certificat signé par l’IGC/A. C’est l’erreur. C’est tout et cela n’a strictement rien à voir avec tous ces débats.



Ce n’est pas une erreur informatique mais une erreur humaine grave.

Les personnes qui ont les autorisations pour générer des certificats dans une autorité de certification de ce type doivent savoir qu’elles n’ont pas le droit de signer des certificats pour des sites de google qui n’a aucune raison d’utiliser une autorité de certification de l’État Français.



Quelle procédure de contrôle est utilisée pour vérifier que celui qui demande un certificat est le possesseur légitime du site concerné ou qu’il a la délégation technique correspondante du propriétaire ?



Enfin, quelle sanction a été appliquée à la personne fautive ?


J’adore le point de vue agence publique (erreur humaine) vs. entreprise privée (grave problème).








unCaillou a écrit :



En tout cas, ça soulève un problème: seul chrome a un mécanisme de détection des certificats non-attendus sur un nom de domaine. Firefox, IE et Safari font quoi pour ce genre de problème ?





Pour firefox il y a une extension (Certificate Patrol) qui vérifie que le certificat reste le même et t’informe si il change. C’est un peu pénible sur certains sites (gros, souvent) qui te balancent un certificat au hasard parmi 42 différents en fonction du serveur sur lequel tu te retrouves finalement.









yoda222 a écrit :



Pour firefox il y a une extension (Certificate Patrol) qui vérifie que le certificat reste le même et t’informe si il change. C’est un peu pénible sur certains sites (gros, souvent) qui te balancent un certificat au hasard parmi 42 différents en fonction du serveur sur lequel tu te retrouves finalement.





Oui je connais cette extension, mais ça reste marginal. Je pensais plus à Microsoft, Mozilla et Apple, quelle protection ont-ils mis en place dans leur navigateurs ?









H4rvester a écrit :



Sauf qu’ils ne sont pas sensés utiliser Chrome, donc oui Chrome dispose de ce mécanisme, mais il semblerait que ce ne soit pas par là que ce soi arrivé chez Google.







J’imagine bien le coup d’un admin, qui se croit au dessus des règles qu’il impose à ses propres utilisateurs, utilisant Chrome sur sa station perso.









hellmut a écrit :



Pourtant ça serait super intéressant de savoir comment ils ont détecté ça.

et bien franchement ça m’étonnerait que l’ANSSI ne s’y intéresse pas. ou en tout ca elle devrait.





+1 c’est bien le point qui m’intéresse le plus <img data-src=" />



BenjaminSonntag a écrit :



l’ANSSI sait pertinemment d’où sort l’info de google :http://blog.cryptographyengineering.com/2013/01/ubiquitous-surveillance-works-le… (en anglais) c’est certaines versions de Chrome qui fayotent (valablement) à Google en cas de certificat signé par la mauvaise autorité, on appelle cela du “certificate pinning”





<img data-src=" /><img data-src=" />









hellmut a écrit :



Pourtant ça serait super intéressant de savoir comment ils ont détecté ça.

et bien franchement ça m’étonnerait que l’ANSSI ne s’y intéresse pas. ou en tout ca elle devrait.





Come toi, j’aimerai savoir comment Google a pu s’apercevoir de ceci précisément.





Come toi, j’aimerai savoir comment Google a pu s’apercevoir de ceci précisément





il suffit qu’une seule personne utilise Chrome pour que google soit avertit que le certificat ne correspond pas à celui qui a été hardcodé dans chrome pour le domaine de google.



il est possible meme que des utilisateurs d’android connectés en wifi aient pu envoyer cette info si les applis google disposent d’un mecanisme similaire à celui de chrome en cas de detection d’un certificat inattendu.



en tout cas je ne serais pas étonné que d’autres certificats aient été générés pour Hotmail, Yahoo mail, Facebook…

je serais même étonné du contraire. Pourquoi ne voudraient ils ne surveiller QUE gmail/google?





le plus pathétique dans l’affaire, c’est qu’il n’y avait nullement besoin de générer de tels certificats. Dans un environnement administré, il est simple de déployer un certificat racine pour une autorité de certification interne à l’entreprise sur toutes les machines , ce qui permet aux connections d’être relayées et examinées par un proxy interne sans causer d’erreurs https.



deux raisons qui expliqueraient la non utilisation de cette méthode:

-incompetence

-volonté de supporter les devices non administrés (iPad, …)


Google a déjà dit comment il avait fait lors de l’usage de faux certificat par l’Iran pour espionner ses citoyens, il y a quelques temps. Il code en dur ses propres certificats dans le code source de Chrome et peux donc détecter les différences avec ce qui est annoncé par le système standard.



Quelqu’un dans l’état a installé un proxy MIM menteur qui fait croire au navigateur d’un ministère qu’il circule sur un lien https sécurisé, sauf que cela n’ai pas le cas, car le proxy en question ment. Pour faire cela, ils ont utilisé un vrai-faux certificat de google (pour gmail et vérifier/interdire les pièces jointes ? ). D’habitude, ce genre de grosse structure utilise un certificat maison, mis à la main dans tous les navigateurs de la structure. J’imagine que faire un vrai-faux était plus facile.



J’ai du mal à comprendre comment un proxy espion sur https, peut aider à contrer des attaques informatiques qui proviennent de l’extérieur.



Qu’est-ce qu’il se passera le jour au ce genre de proxy sera vérolé et qu’un pirate black hat pourra s’emparer d’un paquet de login/mot de passe de banque ou de numero de CB ? Qui sera responsable ?



Que penser d’une boite qui met en place un moyen d’espionner le contenu des boites mails personnelle et les mots de passe de ses employés ?


Surtout que d’après Bluetouff sur Reflets (et la discussion s’est poursuivie sur Twitter), il n’est pas possible d’utiliser Chrome sur le réseau de la DGT.

Sans plus d’infos par contre…


Il y a plus de détails sur le bulletin de sécurité de Microsoft:http://technet.microsoft.com/en-us/security/advisory/2916652



Notamment la liste des domaines signés (Google, Youtube, Android et Urchin).








jmanici a écrit :



il suffit qu’une seule personne utilise Chrome pour que google soit avertit que le certificat ne correspond pas à celui qui a été hardcodé dans chrome pour le domaine de google.



il est possible meme que des utilisateurs d’android connectés en wifi aient pu envoyer cette info si les applis google disposent d’un mecanisme similaire à celui de chrome en cas de detection d’un certificat inattendu.



en tout cas je ne serais pas étonné que d’autres certificats aient été générés pour Hotmail, Yahoo mail, Facebook…

je serais même étonné du contraire. Pourquoi ne voudraient ils ne surveiller QUE gmail/google?





le plus pathétique dans l’affaire, c’est qu’il n’y avait nullement besoin de générer de tels certificats. Dans un environnement administré, il est simple de déployer un certificat racine pour une autorité de certification interne à l’entreprise sur toutes les machines , ce qui permet aux connections d’être relayées et examinées par un proxy interne sans causer d’erreurs https.



deux raisons qui expliqueraient la non utilisation de cette méthode:

-incompetence

-volonté de supporter les devices non administrés (iPad, …)





franchement ça m’étonnerait beaucoup qu’il y ait un wifi interne à la DGT.

je ne demande qu’à me tromper, mais ça me parait “trop gros”. ^^

quant au matos non administré, même chose.

ou alors les gars sont d’énormes tanches à la SSI.





En tout cas, ça soulève un problème: seul chrome a un mécanisme de détection des certificats non-attendus sur un nom de domaine. Firefox, IE et Safari font quoi pour ce genre de problème ?





attention, le certificate pinning se base sur une liste hard codée.



Google chrome protege les différents domaines appartenant à Google, ainsi que d’autres connus comme Twitter.com



mais si quelqu’un généré un certificat pour le site de ta banque, le certificate pinning de chrome n’y verra que du feu.



idem pour EMET qui permet de rajouter le support du certificate pinning dans IE. EMET dans sa config par défaut ne protège que les domaines de Microsoft et Skype.



cela dit, contrairement à chrome, l’utilisateur peut rajouter des domaines dans EMET.



du coup c’est normal que le certificate pinning ne soit pas généralisé.

pour que ce soit efficace, il faudrait une liste mise a jour dynamiquement. Et il faudrait surtout aux webmasters un moyen de signaler un changement légitime de certificat. Sinon les sites se retrouveraient bloqués suite à un changement de certificat.



autrement dit: il faudrait un standard à part entière pour définir le mécanisme de distribution de ces infos.




J’ai du mal à comprendre comment un proxy espion sur https, peut aider à contrer des attaques informatiques qui proviennent de l’extérieur.





C’est pas le but, le but c’est de voir ce qui se fait en interne, pas de protéger ce qui vient de l’extérieur.



Entre autre, vérifier les fichiers qui transitent pour éviter les fuites (un employé du Trésor qui met un truc sur Google Drive, moyen.)








Baldurien a écrit :



Pas qu’une entreprise publique/privée mette en place un WAF sur un réseau interne, où les utilisateurs/salariés signent normalement une charte informatique leur expliquant cela.











jmanici a écrit :



le plus pathétique dans l’affaire, c’est qu’il n’y avait nullement besoin de générer de tels certificats. Dans un environnement administré, il est simple de déployer un certificat racine pour une autorité de certification interne à l’entreprise sur toutes les machines , ce qui permet aux connections d’être relayées et examinées par un proxy interne sans causer d’erreurs https.







Je ne comprends toujours pas comment cela peut être légal de faire cela. Les pauses sont autorisées, les coups de fils perso (raisonnable) aussi. Pourquoi une boite aurait le droit d’espionner complètement ses employés lorsqu’ils vont sur leur mail, ou leur banque par exemple ?












cyrano2 a écrit :



J’ai du mal à comprendre comment un proxy espion sur https, peut aider à contrer des attaques informatiques qui proviennent de l’extérieur.





il s’agit à priori du contraire: détecter les fuites de l’intérieur vers l’extérieur.





Que penser d’une boite qui met en place un moyen d’espionner le contenu des boites mails personnelle et les mots de passe de ses employés ?



ce n’est pas “une boite”. c’est la Direction Générale du Trésor. c’est une administration légèrement sensible et stratégique.<img data-src=" />









cyrano2 a écrit :



Je ne comprends toujours pas comment cela peut être légal de faire cela. Les pauses sont autorisées, les coups de fils perso (raisonnable) aussi. Pourquoi une boite aurait le droit d’espionner complètement ses employés lorsqu’ils vont sur leur mail, ou leur banque par exemple ?





quand tu travailles pour une entreprise/administration stratégique, si t’es pas trop con, tu vas pas sur le site de ta banque. Moi je vais sur Google, mais je me connecterai jamais sur le site de ma banque.

et ça depuis que j’ai vu le joli nom de BlueCoat sur des pages bloquées il y a quelques années (après on pourra aussi discuter de l’utilisation de BlueCoat par une boite FR ^^).





franchement ça m’étonnerait beaucoup qu’il y ait un wifi interne à la DGT.

je ne demande qu’à me tromper, mais ça me parait “trop gros”. ^^

quant au matos non administré, même chose.

ou alors les gars sont d’énormes tanches à la SSI.





à la lumière de cette news, des choses qui paraissaient totalement improbable semblent être plus courantes qu’on ne pourrait le craindre.



qu’il y ait un réseau wifi et une politique autorisant les hauts fonctionnaires à utiliser leur iPad perso me semble tout à fait probable en comparaison…








hellmut a écrit :



ce n’est pas “une boite”. c’est la Direction Générale du Trésor. c’est une administration légèrement sensible et stratégique.<img data-src=" />







Oui, mais c’est loin d’être la seul à faire ça.



Si, c’est si sensible, pourquoi sont-il connecté à internet ?






Je ne comprends toujours pas comment cela peut être légal de faire cela. Les pauses sont autorisées, les coups de fils perso (raisonnable) aussi. Pourquoi une boite aurait le droit d’espionner complètement ses employés lorsqu’ils vont sur leur mail, ou leur banque par exemple ?





du moment que les employés sont au courant, il n’y a pas de problème.



personne ne les force à utiliser leurs comptes perso au travail.



c’est normal que la DSI veuille être capable de surveiller les flux sortants, étant donné que les firewalls entrants ne servent plus à grand chose face à des botnets qui communiquent via des flux sortants en https.








cyrano2 a écrit :



Oui, mais c’est loin d’être la seul à faire ça.





clairement, comme toutes les boites et admin sensibles et stratégiques.





Si, c’est si sensible, pourquoi sont-il connecté à internet ?



l’échange d’infos par pigeons voyageurs, ça a vieilli, quand même.<img data-src=" />









hellmut a écrit :



l’échange d’infos par pigeons voyageurs, ça a vieilli, quand même.<img data-src=" />





bof. Les ministère font par coursier et ça marche pas mal



faut juste pas être pressé <img data-src=" />









hellmut a écrit :



quand tu travailles pour une entreprise/administration stratégique, si t’es pas trop con, tu vas pas sur le site de ta banque. Moi je vais sur Google, mais je me connecterai jamais sur le site de ma banque.

et ça depuis que j’ai vu le joli nom de BlueCoat sur des pages bloquées il y a quelques années (après on pourra aussi discuter de l’utilisation de BlueCoat par une boite FR ^^).





http://surveillance.rsf.org/blue-coat/



ah quand même <img data-src=" />









jmanici a écrit :



à la lumière de cette news, des choses qui paraissaient totalement improbable semblent être plus courantes qu’on ne pourrait le craindre.



qu’il y ait un réseau wifi et une politique autorisant les hauts fonctionnaires à utiliser leur iPad perso me semble tout à fait probable en comparaison…





Disons que j’imagine mal le responsable de la sécurité des services informatiques de la DGT demander l’installation d’un Wifi et (donc, ou presque) le support des Ipads et autres devices non-standards.

j’imagine mal aussi l’ANSSI constater ça et ne rien dire.

il est clair qu’il y a eu une connerie de faite, mais faut pas pousser non plus, c’est pas des neuneus (au contraire, au vu des offres d’emploi de l’ANSSI par exemple).









jb18v a écrit :



http://surveillance.rsf.org/blue-coat/



ah quand même <img data-src=" />





oui <img data-src=" />

les boules hein?



donc visiblement, les commentaires sur PCI, ça passe.<img data-src=" />









jmanici a écrit :



du coup c’est normal que le certificate pinning ne soit pas généralisé.

pour que ce soit efficace, il faudrait une liste mise a jour dynamiquement. Et il faudrait surtout aux webmasters un moyen de signaler un changement légitime de certificat. Sinon les sites se retrouveraient bloqués suite à un changement de certificat.



autrement dit: il faudrait un standard à part entière pour définir le mécanisme de distribution de ces infos.





C’est ce que propose google : le système Certificate Transparency, en gros c’est un annuaire public décentralisé qui répertorie tous les certificats associés aux noms de domaine. Tous les certificats y sont répertoriés. Et à chaque connexion TLS, le serveur doit fournir au navigateur un SCT (secure certificate-transparency timestamp) prouvant que son certificat est bien publié dans l’annuaire, aux yeux de tous.

Ainsi, chaque responsable de nom de domaine sait quels certificats sont utilisés pour son site. Google a commencé à construire un annuaire et cherche à faire adopter ce système.









hellmut a écrit :



l’échange d’infos par pigeons voyageurs, ça a vieilli, quand même.<img data-src=" />







Si c’est sensible, n’importe quelle personne qui s’y connait un peu peut contourner un tel système automatique (compression 7-zip au max de 20 Mo, s’est scanné ?). Par contre, on sait qu’aucun mail n’y échappera.



La sécurité, est donc très relative.





il est clair qu’il y a eu une connerie de faite, mais faut pas pousser non plus, c’est pas des neuneus (au contraire, au vu des offres d’emploi de l’ANSSI par exemple





et pourtant, la connerie dont il est question ici est bien plus grave que la mise en place d’un réseau wifi avec une clef wep.



le plus grave dans l’affaire, c’est que la personne qui a eu cette idée ne l’a pas exécutée seule. Et les autres ont trouvé cette idée acceptable. Ca me parait inimaginable qu’ils aient pu ignorer les conséquences potentielles d’un tel acte. Si ces certificats avaient fuité, ils auraient pu faire des ravages.



au final, le coup du wifi et de l’ipad non administré c’est une des seules choses qui pourrait expliquer pourquoi ils ont fait cela plutôt qu’utiliser une autorité de certif interne. Sinon c’est de l’incompétence pure.








jmanici a écrit :



le plus grave dans l’affaire, c’est que la personne qui a eu cette idée ne l’a pas exécutée seule.





ça, à priori, t’en sais rien. ou alors t’as des infos que personne n’a.



Il n’existe pas à leur actuelle de mécanisme permettant de lier domaine su site et certificat dans l’autre sens ?



C’est à dire en plus de l’étape actuelle du : je vais sur un site, le serveur m’envoie son certif, mon navigateur vérifie la CRL du fournisseur associé.

Une nouvelle étape qui ferait: le navigateur va regarder un enregistrement DNS de type txt sur toto.com qui indique la liste des autorité utilisées par ce site voir même les serials de tout les certifs.



Un peu comme le processus inverse de contrôle d’expéditeur SMTP avec SPF.<img data-src=" />








cyrano2 a écrit :



Si c’est sensible, n’importe quelle personne qui s’y connait un peu peut contourner un tel système automatique (compression 7-zip au max de 20 Mo, s’est scanné ?). Par contre, on sait qu’aucun mail n’y échappera.



La sécurité, est donc très relative.





Sur des réseau sensible comme les postes clients sont aussi surveillés. C’est pas un seul logiciel sur le firewall qui assure la protection, c’est un ensemble de logiciels placés à différents endroits.



Genre dans ma boite on a sur chaque poste client un logiciel qui surveille tous nos téléchargements, téléversements, copier-collers, etc…

Ton fichier 7z ils savent ce qu’il contient avant même qu’il ait fini d’être compressé.









Khalev a écrit :



Sur des réseau sensible comme les postes clients sont aussi surveillés. C’est pas un seul logiciel sur le firewall qui assure la protection, c’est un ensemble de logiciels placés à différents endroits.



Genre dans ma boite on a sur chaque poste client un logiciel qui surveille tous nos téléchargements, téléversements, copier-collers, etc…

Ton fichier 7z ils savent ce qu’il contient avant même qu’il ait fini d’être compressé.







Quelle boite pour information ?









cyrano2 a écrit :



Quelle boite pour information ?





<img data-src=" />



“La société a déclaré que ces appareils n’étaient “pas en mesure d’utiliser le service WebPulse” ou “de faire fonctionner la base de données WebFilter”, composants importants du dispositif de surveillance fonctionnant en “nuage”. ” selonhttp://surveillance.rsf.org/blue-coat/



Donc, on a une boite américaine qui fait du DPI pour de la “sécurité”, qui fonctionne avec un “cloud”. Et les Français l’utilisent pour sécuriser le trésor ?! <img data-src=" />



En gros, ils donnent toutes leur infos à la NSA. <img data-src=" />








Khalev a écrit :



<img data-src=" />







C’est pour être sûr de ne pas postuler.









cyrano2 a écrit :



“La société a déclaré que ces appareils n’étaient “pas en mesure d’utiliser le service WebPulse” ou “de faire fonctionner la base de données WebFilter”, composants importants du dispositif de surveillance fonctionnant en “nuage”. ” selonhttp://surveillance.rsf.org/blue-coat/



Donc, on a une boite américaine qui fait du DPI pour de la “sécurité”, qui fonctionne avec un “cloud”. Et les Français l’utilisent pour sécuriser le trésor ?! <img data-src=" />



En gros, ils donnent toutes leur infos à la NSA. <img data-src=" />







Attention, Helmutt n’a jamais dit qu’il travaillait pour le trésor <img data-src=" />



À mettre en relation avec la news précédente.



Difficile à la fois de s’offusquer de la surveillance d’Internet par les états et d’accuser Google d’espionnage de la DGT (probablement rapportée par Chrome pour mobile sur le wifi de la DGT ou similaire, je n’imagine pas une équipe de hacker chez Google infiltrant les organisations pour vérifier les certificats).



Peu importe la raison de “l’erreur”, le point clef de l’histoire est que le certificat généré pourrait très réellement être utilisé par l’état français pour espionner tout le trafic français vers les services Google.



Le certificate-pinning a été créé justement pour tenter d’éviter ce genre de situation.








Khalev a écrit :



<img data-src=" />





<img data-src=" /> même chose chez moi.







blaétria a écrit :



Attention, Helmutt n’a jamais dit qu’il travaillait pour le trésor <img data-src=" />





heu non je bosse pas pour le Trésor. ^^



mais effectivement, sachant qu’on est des stars en DPI ça m’a fait bizarre à l’époque de voir le nom de Bluecoat (c’était pas pour le cloud, d’ailleurs je savais pas qu’ils en faisaient).



ceci dit l’ANSSI a été créée depuis, et au vu des récentes évolutions sur le sujet de la sécu, et suite à quelques changements en interne, je pense sans risquer de trop me tromper que la solution de surveillance adoptée est “souveraine”, et sans aucun doute défavorablement connue des INpactiens.



je dis pas que c’est bien, mais tant qu’à être surveillé, autant l’être par une techno tricolore.









blaétria a écrit :



Attention, Helmutt n’a jamais dit qu’il travaillait pour le trésor <img data-src=" />







J’aurais dû mettre “truc stratégique français”.







hellmut a écrit :





je dis pas que c’est bien, mais tant qu’à être surveillé, autant l’être par une techno tricolore.







Cela me rappelle un dev chez client pour l’armée qui manipulait un peu de cryptographie. Les conditions de travail étaient tellement chiantes, que personne ne voulait y bosser (local sans fenêtre, pas de second PC sur internet, pas de réseau ni d’usb (top pour manipuler les specs!),… ).









cyrano2 a écrit :



J’aurais dû mettre “truc stratégique français”.







Cela me rappelle un dev chez client pour l’armée qui manipulait un peu de cryptographie. Les conditions de travail étaient tellement chiantes, que personne ne voulait y bosser (local sans fenêtre, pas de second PC sur internet, pas de réseau ni d’usb (top pour manipuler les specs!),… ).







Tant qu’on ne te reproche pas de couper des arbres quand tu veux des specs sur papier <img data-src=" />









cyrano2 a écrit :



J’aurais dû mettre “truc stratégique français”.





<img data-src=" />





Cela me rappelle un dev chez client pour l’armée qui manipulait un peu de cryptographie. Les conditions de travail étaient tellement chiantes, que personne ne voulait y bosser (local sans fenêtre, pas de second PC sur internet, pas de réseau ni d’usb (top pour manipuler les specs!),… ).



ah ouais quand même.



moi quand je suis arrivé y’a quelques années on avait pas internet, et un vieux pentium 2 avec un écran CRT de 15” pour y accéder. Pour une équipe de 15 je te dis pas le bordel. ^^

le pire c’est que n’étant pas connecté au réseau interne, il nous fallait utiliser… des clés USB pour récupérer la doc, les patches etc.



bon, à la limite. sauf que la boite ne fournissait pas les clés. et on utilisait quoi? ben des clés persos.



tout ça pour ça. <img data-src=" />









levhieu a écrit :



Tant qu’on ne te reproche pas de couper des arbres quand tu veux des specs sur papier <img data-src=" />







J’espère que c’était pas des spec comme les TRM des Omap de TI, (en gros, une ligne ou 2 par bit de configuration), qui faisait 3000 pages.









cyrano2 a écrit :



Je ne comprends toujours pas comment cela peut être légal de faire cela. Les pauses sont autorisées, les coups de fils perso (raisonnable) aussi. Pourquoi une boite aurait le droit d’espionner complètement ses employés lorsqu’ils vont sur leur mail, ou leur banque par exemple ?





Tu sais que les employés des centres d’appels sont légalement écoutés (et la conversation archivée) ? Et ça, je ne le dédis que du message que tu as quand tu les appelles.



* déduis, pas dédis.








cyrano2 a écrit :



Cela me rappelle un dev chez client pour l’armée qui manipulait un peu de cryptographie. Les conditions de travail étaient tellement chiantes, que personne ne voulait y bosser (local sans fenêtre, pas de second PC sur internet, pas de réseau ni d’usb (top pour manipuler les specs!),… ).





Bin c’est le cas chez nous <img data-src=" /> Mais moi ça me dérange pas.



Par contre on bosse pas pour l’armée (là j’aurais refusé, même pour un bureau avec fenêtre).









Baldurien a écrit :



Tu sais que les employés des centres d’appels sont légalement écoutés (et la conversation archivée) ? Et ça, je ne le dédis que du message que tu as quand tu les appelles.





Pas encore pour tous il me semble (d’ailleurs tu n’as pas toujours le message), mais effectivement la grosse majorité. Et pour ceux qui ne le sont pas encore, ce sera bientôt changé, du fait de l’obligation d’avoir un enregistrement de tout démarchage téléphonique (et en particulier en cas de souscription d’un service au téléphone - en cas d’absence, si le client affirme qu’il n’a rien souscrit, la souscription et tout ce qui va avec saute).



Il est bien évident qu’ils sont prévenus avant, mais c’est également normal qu’ils le soient ; ils sont également en général régulièrement écoutés “en live” par leurs superviseurs (et c’est encore plus fréquent lors qu’il n’y a pas d’enregistrement, puisqu’il n’est alors pas possible de faire des évaluations “à froid” - ou plutôt tiède, parce qu’une évaluation qui est faite trop longtemps après le traitement de l’appel ne permet pas tellement d’améliorer la qualité de réponse du TC).



Et avant que certains voient ça comme du flicage et un moyen de pouvoir sacquer les TC : l’utilisation principale de ces enregistrements et écoutes “live”, en plus des besoins de traces comme mentionné ci-dessus, c’est d’identifier les points sur lequel le TC n’est pas au point pour ensuite lui donner les moyens de s’améliorer (le TC a tendance à oublier de reformuler la question du client pour s’assurer qu’il l’a bien comprise ? Grâce aux écoutes, le superviseur identifie le problème et peut insister sur ce point particulièrement avec le TC ; dans certains cas il s’agira de lui proposer une formation pour améliorer le point qui fait défaut - élocution, précisions techniques, etc.).





Maintenant, on est en train de prendre un certain nombre de mesures tout en jouant la transparence : une erreur a été faite, tout le dispositif reposant sur la confiance, il s’agit pour nous d’expliquer ce qui s’est passé. Nous sommes en train par ailleurs de vérifier – nous avons presque fini - qu’il n’y a pas d’autres cas dans l’administration. Nous lançons aussi une campagne d’audit pour savoir si les certifications sont bien appliquées. Enfin, à moyen terme, nous regardons si notre architecture technique est bonne ou s’il faut l’adapter.



Je me trompe ou c’est justement le travail qu’ils avaient à faire, de vérifier que leurs certificats sont en sécurité ?








Baldurien a écrit :



Tu sais que les employés des centres d’appels sont légalement écoutés (et la conversation archivée) ? Et ça, je ne le dédis que du message que tu as quand tu les appelles.







C’est même indiqué dans la musique d’attente. Mais il n’aime pas quand toi, tu annonces la même chose de ton coté.



Mais cela n’a rien à voir avec le cas présent, ou l’existence même du job de la personne est de répondre au téléphone.









cyrano2 a écrit :



C’est même indiqué dans la musique d’attente. Mais il n’aime pas quand toi, tu annonces la même chose de ton coté.



Mais cela n’a rien à voir avec le cas présent, ou l’existence même du job de la personne est de répondre au téléphone.





Si justement. Le boulot d’un mec au trésor, c’est pas d’aller sur gmail & consort, surtout en SSL, hein :)









Baldurien a écrit :



Si justement. Le boulot d’un mec au trésor, c’est pas d’aller sur gmail & consort, surtout en SSL, hein :)







On parle de pause, de vie privé, les trucs que font les humains pour s’aérer la tête.









cyrano2 a écrit :



On parle de pause, de vie privé, les trucs que font les humains pour s’aérer la tête.





Mais ils ont droit d’y aller. Et ça ne concerne que les sites en SSL, parce que bon, tu vas t’aérer la tête sur un site de jeux à la con qui n’est pas en SSL, c’est pareil…

Et faut pas oublier qu’il s’agit d’un contournement technique pour permettre de détecter des virus qui passent par des sites en HTTPS (ça arrive, hein) et qui pourraient infecter un réseau interne.









Baldurien a écrit :



détecter des virus qui passent par des sites en HTTPS (ça arrive, hein) et qui pourraient infecter un réseau interne.







A quoi sert d’avoir des anti-virus sur les machines dans ce cas ? Est-ce tellement courant des virus qui arrivent encore par ce biais ? Est-ce qu’il faudrait peut être que les boites ne reste pas sur IE8, ou patch enfin les versions de java ou de flash installé sur les PC, non ?









cyrano2 a écrit :



A quoi sert d’avoir des anti-virus sur les machines dans ce cas ? Est-ce tellement courant des virus qui arrivent encore par ce biais ? Est-ce qu’il faudrait peut être que les boites ne reste pas sur IE8, ou patch enfin les versions de java ou de flash installé sur les PC, non ?





Parce que




  1. Des utilisateurs ignorent les mises à jour

  2. Des utilisateurs désactivent l’anti virus car il pourrit les perfs quand tu bosses (ex: les développeurs :))

  3. Que l’anti virus peut ne pas être à jour (ou en cours de mise à jour) pendant l’ouverture de la pièce jointe (ex: quelqu’un qui revient de vacances)

  4. Parce qu’un anti virus n’est pas fiable à 100%, et que c’est pas déconnant d’en avoir un deuxième d’une autre marque. Un peu comme demander un devis à plusieurs réparateurs pour avoir le meilleur prix …



    Et sinon, on parle de boite mail. Y a encore (et y aura toujours) des gens pour télécharger les pièces jointes et les exécuter en local. Et même si gmail filtre certains virus, il n’est pas infaillible.



    Bon et puis y a la fuite de données :) Mais ça, c’est un autre sujet.





Je fais parti des 2). Les anti virus sont un complot des vendeurs de CPU et de SSD, voir de fabricant d’ordinateur. Je ne vois pas d’autres explications. <img data-src=" />



“Et même si gmail filtre certains virus, il n’est pas infaillible. ”



Et quelle est la probabilité qu’il soit moins faillible que votre propre solution ?



“Bon et puis y a la fuite de données :) Mais ça, c’est un autre sujet. ”



En effet, et c’est dans l’autre sens. Et c’est du simple flicage de ses employés, mais bon, ceux qui ne veulent pas faire confiance, ne vont pas aimer la multiplication des appareils 4G…