Google monte au créneau contre un certificat de sécurité généré en son nom

Google monte au créneau contre un certificat de sécurité généré en son nom

Vite, un sparadrap

30

Google monte au créneau contre un certificat de sécurité généré en son nom

Sale temps pour les certificats. Après le scandale SuperFish chez Lenovo et, plus récemment, le cas d’un utilisateur finlandais qui avait réussi à en obtenir un au nom de Microsoft, Google avertit ses utilisateurs qu'un certificat a été édité en son nom, mais sans la moindre autorisation. Les utilisateurs de Chrome sont protégés et ceux de Firefox le seront bientôt, mais ce nouveau problème ne fait que mettre encore en évidence les failles d’un système peu pérenne.

Les maillons parfois faibles de la chaine de confiance

Comme nous l’indiquions récemment, les certificats de sécurité permettent par exemple à des sites web de prouver qu’ils sont ce qu’ils prétendent être. Si vous vous rendez sur le site d’une banque, c’est le certificat qui permet au navigateur de reconnaitre un site authentique et d’initier une connexion sécurisée le cas échéant. Dans le navigateur, une telle connexion se symbolise le plus souvent par un cadenas affiché avant l’adresse. Mais que faire si un certificat authentique est utilisé avec des intentions malveillantes ou autres ?

C’est de ce problème dont Google avertit justement les utilisateurs. Une autorité intermédiaire de certification égyptienne, MCS Holdings, a généré un certificat au nom de la firme, à la demande du China Internet Network Information Center (CNNIC).  On ne sait pas pourquoi, mais MCS l’a ensuite installé dans un proxy capable de se comporter en « homme du milieu », interceptant les communications sécurisées de ses employés « pour examen ou raisons juridiques ».

Si la pratique n’est pas nouvelle, le fait de munir un proxy d’un certificat Google représente un grave danger. Le seul facteur de limitation du risque est que le proxy n’a vraisemblablement visé que les propres employés de MCS Holdings, comme le note sur Twitter Adam Langley, ingénieur sécurité chez Google. Il n’a donc pu normalement voir que les données circulant entre les employés et les clients.

Une épée de Damoclès

Le fait que le certificat n’ait été généré qu’avec une date de validité fixée au 3 avril ne change rien au problème central, et Google ne cache pas son mécontentement : si n’importe quelle autorité peut générer des certificats à l’envie et pour des raisons autres que celles souhaitées par l’éditeur légitime, c’est tout le système qui risque de se fracasser. L’intégralité de la chaine de confiance autour des certificats est déjà fragile à cause justement des piratages et décisions commerciales qui ne cadrent que rarement avec les nécessités de la sécurité. Comme nous l’indiquait récemment Stéphane Bortzmeyer, ingénieur système et réseaux à l’Afnic (Association française pour le nommage Internet en coopération), Il existe plus de 600 autorités de certification, et un faux pas est très vite arrivé, volontaire ou non.

Même si le certificat Google ne représente pas un danger immédiat, il incarne un risque énorme. Ce type de certificat est en effet forcément accepté par l’ensemble des navigateurs et des systèmes d’exploitation. En outre, il n’existe aucun moyen simple et/ou centralisé de révoquer un certificat : chaque produit concerné doit émettre une mise à jour, certains produits les acceptant de manière automatique, d’autres nécessitant une installation manuelle. Google indique par exemple avoir révoqué le certificat dans Chrome, mais Mozilla a réagi en précisant que la prochaine version 37 de Firefox s’en chargerait.

Le cas illustre une fois de plus les faiblesses d’un système qui présente des caractéristiques lourdes, puisque le moindre problème entraine une débauche d’activité chez tous les éditeurs pour mettre à jour les logiciels et matériels qui seraient concernés. Stéphane Bortzmeyer nous expliquait cependant que la situation serait délicate à changer, même si pas impossible : « Si les clients se fâchent parce qu’ils trouvent les routines de vérification trop exigeantes, ils se tourneront vers d’autres entreprises où on ne les embête pas autant », les autorités étant libres d’appliquer les règles qu’elles souhaitent. Seule solution dès lors, que tous les acteurs concernés se mettent d’accord sur de nouvelles règles de sécurité, même si un tel consensus sera délicat à obtenir.

Commentaires (30)


Principe de la chaine de confiance des certificats: demander à un mec qu’on ne connait pas si une adresse numérique anonyme est bien celle d’un autre mec dont on ne connait que le nom.



Impeccable. <img data-src=" />


Mardi, journée des actus sur la sécurité. <img data-src=" />

(ça tombe bien je m’ennuyais)








127.0.0.1 a écrit :



Principe de la chaine de confiance des certificats: demander à un mec qu’on ne connait pas si une adresse numérique anonyme est bien celle d’un autre mec dont on ne connait que le nom.



Impeccable. <img data-src=" />





Me suis toujours demander comment ce genre de process a bien pu être accepté et validé en tant que tel.



J’imagine bien la réunion avec les acteurs de la sécurité internet:

“Hé salut, les gars!! J’ai une idée pour troller tout le&nbsp; monde, vous croyez qu’ils mettront combien de temps avant de s’en apercevoir?”



Et ça fait 20 ans que ça dure la blague. <img data-src=" />



Tous les proxys d’entreprises ou presque fonctionnent comme ça afin de valider, ou non, les données qui transitent, au moins à des fins d’analyse de ces dernières. Les certificats sont alors générés “à la volée” selon les sites visés, je ne vois pas où est le scandale, c’est une pratique très courante.

un dessin ?

client ======https://www.google.fr=======&gt; proxy délivrant un certificat pour www.google.fr signé par sa propre autorité de confiance (celle de l’entreprise dans la plupart du temps) ======https://www.google.fr======&gt; google avec son “vrai” certificat.



Comme ça votre patron lit vos mails tranquillement ;)


Vivement que Google deviennent une autorité de certification. On pourra enfin dormir sur nos 3* oreilles.



*merci les smartphones&nbsp;<img data-src=" />


Ceux qui se sont fait avoir sont des pigeons.

Déjà, “sécurité” et “Google” dans la même phrase c’est louche… <img data-src=" />





« Si les clients se fâchent parce qu’ils trouvent les routines de vérification trop exigeantes, ils se tourneront vers d’autres entreprises où on ne les embête pas autant »



Les mêmes qui pleureront quand ils se feront couillonner…

Mais le client a toujours raison, et le peuple est bon par nature. C’est jamais sa faute, non non…


Tout à fait. Depuis que les sites utilisent de plus en plus https, pour pouvoir filtrer les accès (ou sorties) d’un réseau d’entreprise, les proxy ssl sont devenus courant dans les équipements de sécurité.

Par contre, c’est la deuxième fois que Google se fâche sur le sujet. La première fois étant des certificats provenant de l’administration française il me semble.


Saut que dans le cas proxy le certificat d’autorité est un certificat prévu à cette effet pas un certificat utilisépar tous le monde délivrer par une autorité de certification.








genialmaniac a écrit :



Tous les proxys d’entreprises ou presque fonctionnent comme ça afin de valider, ou non, les données qui transitent, au moins à des fins d’analyse de ces dernières. Les certificats sont alors générés “à la volée” selon les sites visés, je ne vois pas où est le scandale, c’est une pratique très courante.

un dessin ?

client ======https://www.google.fr=======&gt; proxy délivrant un certificat pour www.google.fr signé par sa propre autorité de confiance (celle de l’entreprise dans la plupart du temps) ======https://www.google.fr======&gt; google avec son “vrai” certificat.



Comme ça votre patron lit vos mails tranquillement ;)





La différence est que ce genre de certificat ne doit pas être certifié par une autorité, il doit être “self-signed”.&nbsp;Le navigateur fera alors apparaître un message d’erreur, sauf si la signature du certificat a été ajoutée sur le système client.



ce qui est très souvent le cas.


Sauf erreur de ma part, le problème ne doit pas être trop grave pour les utilisateurs de Firefox … En effet&nbsp; depuis quelques versions Firefox intègre le “Public Key Pinning”. Dispositif qui permet à certains sites de définir quelles sont les CA autorisées à emettre des certificats pour leurs domaines.



Pour ceux que ça interesse :



&nbsphttps://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#Implementation_s…



/Xavier


Cela signifie que l’administrateur du proxy a aussi des droits d’administration sur ton ordinateur pour insérer la nouvelle CA, bref que tu es en toute logique sur un matériel administré en entreprise. Enfin je pense qu’on est tous d’accord pour dire que c’est la bonne pratique pour de l’interception SSL en entreprise.


600 autorités ?! Il ne devrait y n avoir qu’une !


Ouais mais mauvais pour le bizness des autres :p


C’est déjà le cas:https://pki.google.com/




Si les clients se fâchent parce qu’ils trouvent les routines de vérification trop exigeantes, ils se tourneront vers d’autres entreprises où on ne les embête pas autant



Bah, dans ce cas là, les navigateurs codent en dur un avertissement en rouge pour les certificats alloués par les entreprises dont les routines de vérification sont pauvres, et le tour est joué, non ? L’utilisateur est averti qu’il surfe sur un site potentiellement dangereux, tant que toute la concurrence dans le milieu ne durcit pas ses règles.


la chaîne de “confiance”



&nbsp;c’est le mot confiance lui même qui doit être remis en question, on ne peut faire confiance à personne, point final, tant qu’on n’a pas compris ça, on reste une bonne petite brebis








Steelskin Kupo a écrit :



La différence est que ce genre de certificat ne doit pas être certifié par une autorité, il doit être “self-signed”.&nbsp;Le navigateur fera alors apparaître un message d’erreur, sauf si la signature du certificat a été ajoutée sur le système client.





Toutes les entreprises disposant d’une PKI auto-signée ont ajouté le certificat de leur propre CA dans les systèmes clients (enfin, ça me paraît évident), du coup, rien n’empêche les entreprises de générer un certificat Google par leur propre PKI.

Reste alors aux salariés de vérifier la chaîne de certification, c’est un peu relou, ou d’utiliser un navigateur qui ne se base pas sur le magasin de certificats de leur machine.



Tiens, c’est marrant, en regardant la CRL émise par la PKI de Google, on s’aperçoit que sur les 7 révocations de leur autorité intermédiaire “Google Internet Authority G2”, 3 révocations ont eu lieu en raison de clé compromise : le 9 juillet 2014, le 12 &nbsp;février 2015 et le 18 mars 2015…


Sur le principe, je trouve quand même l’interception SSL à vomir <img data-src=" />



&nbsp;Non ?


Bah une entreprise est responsable de son accès à Internet et qui plus est c’est un fort vecteur de virus. Du coup, comme interdire l’accès au HTTPS est impensable, il n’y a pas 36 solutions si tu veux pas que ça soit la fête du slip.


J’adore l’article de blog de Google qui pointe vers un incident similaire… Non non, pas dans un pays du tiers mode vu que l’AC concernée était l’ANSSI :



http://googleonlinesecurity.blogspot.com/2013/12/further-improving-digital-certi…



(et où on apprend que par conséquent, Chrome vérifie les TLD des domaines certifiés par l’ANSSI et les limites au .fr et aux TLD des DOM-TOM)



Bon sinon dans un cas pareil, il me semblerait assez judicieux de faire pression sur l’autorité qui signe le certificat de l’AC coupable pour qu’elle révoque ce dernier. Oui, cela veut probablement dire que l’AC coupable va couler (ou en tout cas que son bilan de fin d’année va être sérieusement impacté) et qu’un paquet de sites vont se retrouver dans la merde. Mais bon quand ton boulot c’est d’être un tiers de confiance et que tu prends volontairement des mesures pour tromper tes clients, tu mérites de mettre la clef sous la porte…


Le problème ici n’est pas de savoir si oui ou non le certificat doit être valide coté client mais pourquoi une autorité de certification a délivré un certificat “Google” à un tiers.



Si en interne je me concocte un certificat Google pour l’usage de mon entreprise, test etc. ce n’est absolument pas un problème: il ne sera accepté que par les machines dont je contrôle l’environnement; mais si je vais voir codomo pour avoir un certificat Microsoft et que je l’obtiens c’est beaucoup plus embêtant car il sera accepté par tout le monde.


Alors qu’il suffirait que le proxy interdise l’accès à gmail …








Goldoark a écrit :



600 autorités ?! Il ne devrait y n avoir qu’une !





Non car le problème du monopole se poserait. Et sur quel critère pourrait-on définir qui doit incarner une telle autorité ?

Dès lors qu’il y a monopole quelque part, les dérivent existent. Et elle sont toujours graves.



En revanche un consortium est bien plus efficace et sécurisé car cela fait intervenir plusieurs acteurs différents avec des objectifs différents et des origines différentes. Seulement c’est plus difficile et plus long à mettre en place.



par contre, palo alto le fait depuis des années en usurpant des certif divers et variés et personne ne dit rien……


Bien sûr, je comprends, mais c’est assez “borderline” tout de même. C’est peut-être pour cela qu’ils ne l’ont jamais fait dans les deux écoles où j’ai été (et encore moins dans la boîte où je bosse).


Je pars du principe qu’Internet n’est qu’un outil mis à disposition des employés. Outil qui appartient à l’employeur et donc il peut en faire ce qu’il veut.

Dans une école, je suis d’accord que c’est peut-être plus délicat. Après si c’est clairement annoncée par la charte informatique…


Et le mot de passe est censé disparaitre au profit de méthodes alternatives ?




  • biométrie : tu peux imiter une empreinte de doigt (voire en trancher un), l’empreinte rétinienne n’est pas plus fiable (porteurs de lunettes/lentilles …)

  • le certificat peut être falsifié ou émis par n’importe qui ou presque

  • le code PIN … lol

  • une carte RFID … un bon smartphone pas trop ancien doit pouvoir s’amuser …

  • une carte à puce, même chose (certificat pouvant être faisifié et/ou code PIN …)



    Un (bon) mot de passe ne se suffit pas à lui-même mais se trouve probablement comme étant la moins pire des solutions actuellement (à condition de suivre certaines règles d’établissement du dit mot de passe).


Je conseille d’utiliser le plugin firefox Certificate Patrol pour les plus paranos, on peut y voir les changements de certificats. Car oui votre liste de certificat change au bon vouloir de l’une ou l’autre des CA listées dans votre navigateur comme entité de confiance…

Par contre Google édite tellement ses certificats, pas pratique pour gmail & co, on dirait qu’il les génère à la volée presque ^^


Fermer