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.
Commentaires (69)
#1
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.
#2
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 !
#3
Merci pour la mise au point.
#4
#5
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 ?
#6
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 … " />
#7
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 " />)
#8
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… " />
#9
#10
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.
#11
#12
#13
#14
#15
#16
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 ?
#17
J’adore le point de vue agence publique (erreur humaine) vs. entreprise privée (grave problème).
#18
#19
#20
#21
#22
#23
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, …)
#24
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 ?
#25
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…
#26
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).
#27
#28
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.
#29
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.)
#30
#31
#32
#33
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…
#34
#35
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.
#36
#37
#38
#39
#40
#41
#42
#43
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.
#44
#45
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." />
#46
#47
#48
#49
“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. " />
#50
#51
#52
À 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.
#53
#54
#55
#56
#57
#58
#59
* déduis, pas dédis.
#60
#61
#62
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é ?
#63
#64
#65
#66
#67
#68
#69
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…