Blocage des certificats par Google : interview de Patrick Pailloux (ANSSI)
Certificats locaux vs IGC/A
Le 10 décembre 2013 à 11h04
6 min
Logiciel
Logiciel
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 ».
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.
Blocage des certificats par Google : interview de Patrick Pailloux (ANSSI)
-
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…
Commentaires (69)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 10/12/2013 à 11h12
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.
Le 10/12/2013 à 11h12
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 !
Le 10/12/2013 à 11h12
Merci pour la mise au point.
Le 10/12/2013 à 11h13
Le 10/12/2013 à 11h16
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 ?
Le 10/12/2013 à 11h16
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 … " />
Le 10/12/2013 à 11h18
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 " />)
Le 10/12/2013 à 11h19
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… " />
Le 10/12/2013 à 11h19
Le 10/12/2013 à 11h20
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.
Le 10/12/2013 à 11h21
Le 10/12/2013 à 11h25
Le 10/12/2013 à 11h25
Le 10/12/2013 à 11h27
Le 10/12/2013 à 13h31
Le 10/12/2013 à 13h36
Le 10/12/2013 à 13h36
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…
Le 10/12/2013 à 13h40
Le 10/12/2013 à 13h43
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.
Le 10/12/2013 à 13h44
Le 10/12/2013 à 13h48
Le 10/12/2013 à 13h48
Le 10/12/2013 à 13h49
Le 10/12/2013 à 13h50
Le 10/12/2013 à 14h00
Le 10/12/2013 à 14h15
Le 10/12/2013 à 14h15
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.
Le 10/12/2013 à 14h23
Le 10/12/2013 à 14h35
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." />
Le 10/12/2013 à 14h46
Le 11/12/2013 à 08h38
Le 11/12/2013 à 09h17
Le 11/12/2013 à 09h57
Le 11/12/2013 à 16h46
Le 12/12/2013 à 09h13
Le 12/12/2013 à 09h57
Le 12/12/2013 à 10h40
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. " />
“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…
Le 10/12/2013 à 11h28
Le 10/12/2013 à 11h58
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 ?
Le 10/12/2013 à 12h04
J’adore le point de vue agence publique (erreur humaine) vs. entreprise privée (grave problème).
Le 10/12/2013 à 12h05
Le 10/12/2013 à 12h11
Le 10/12/2013 à 12h16
Le 10/12/2013 à 12h27
Le 10/12/2013 à 12h42
Le 10/12/2013 à 13h20
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, …)
Le 10/12/2013 à 13h24
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 ?
Le 10/12/2013 à 13h24
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…
Le 10/12/2013 à 13h26
Il y a plus de détails sur le bulletin de sécurité de Microsoft: MicrosoftNotamment la liste des domaines signés (Google, Youtube, Android et Urchin).
Le 10/12/2013 à 13h27
Le 10/12/2013 à 13h28
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.
Le 10/12/2013 à 13h29
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.)
Le 10/12/2013 à 13h30
Le 10/12/2013 à 14h50
Le 10/12/2013 à 15h08
Le 10/12/2013 à 15h09
“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 ?! " />
En gros, ils donnent toutes leur infos à la NSA. " />
Le 10/12/2013 à 15h10
Le 10/12/2013 à 15h18
Le 10/12/2013 à 15h30
À 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.
Le 10/12/2013 à 15h31
Le 10/12/2013 à 15h50
Le 10/12/2013 à 15h53
Le 10/12/2013 à 15h56
Le 10/12/2013 à 15h57
Le 10/12/2013 à 16h33
Le 10/12/2013 à 16h48
* déduis, pas dédis.
Le 10/12/2013 à 17h12
Le 10/12/2013 à 19h37
Le 10/12/2013 à 20h05
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é ?