Google monte au créneau contre un certificat de sécurité généré en son nom
Vite, un sparadrap
Le 24 mars 2015 à 17h18
4 min
Internet
Internet
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.
@hanno @taviso We understand that the MITM proxy was owned and operated by MCS Holdings and it only saw traffic from their clients.
— Adam Langley (@agl__) 23 Mars 2015
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.
Google monte au créneau contre un certificat de sécurité généré en son nom
-
Les maillons parfois faibles de la chaine de confiance
-
Une épée de Damoclès
Commentaires (30)
Vous devez être abonné pour pouvoir commenter.
Déjà abonné ? Se connecter
Abonnez-vousLe 25/03/2015 à 09h46
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…
Le 25/03/2015 à 10h18
Et le mot de passe est censé disparaitre au profit de méthodes alternatives ?
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).
Le 25/03/2015 à 12h48
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 ^^
Le 24/03/2015 à 19h48
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.
Le 24/03/2015 à 20h06
600 autorités ?! Il ne devrait y n avoir qu’une !
Le 24/03/2015 à 20h18
Ouais mais mauvais pour le bizness des autres :p
Le 24/03/2015 à 21h34
C’est déjà le cas: Google
Le 24/03/2015 à 22h40
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.
Le 24/03/2015 à 23h19
la chaîne de “confiance”
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
Le 24/03/2015 à 23h33
Le 24/03/2015 à 23h54
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 février 2015 et le 18 mars 2015…
Le 25/03/2015 à 06h53
Sur le principe, je trouve quand même l’interception SSL à vomir " />
Non ?
Le 25/03/2015 à 07h33
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.
Le 25/03/2015 à 07h55
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 25/03/2015 à 08h25
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.
Le 25/03/2015 à 08h34
Alors qu’il suffirait que le proxy interdise l’accès à gmail …
Le 25/03/2015 à 08h58
Le 25/03/2015 à 09h14
par contre, palo alto le fait depuis des années en usurpant des certif divers et variés et personne ne dit rien……
Le 25/03/2015 à 09h34
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).
Le 24/03/2015 à 17h25
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. " />
Le 24/03/2015 à 17h28
Mardi, journée des actus sur la sécurité. " />
(ça tombe bien je m’ennuyais)
Le 24/03/2015 à 17h43
Le 24/03/2015 à 17h45
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=======> 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======> google avec son “vrai” certificat.
Comme ça votre patron lit vos mails tranquillement ;)
Le 24/03/2015 à 17h51
Vivement que Google deviennent une autorité de certification. On pourra enfin dormir sur nos 3* oreilles.
*merci les smartphones " />
Le 24/03/2015 à 18h07
Ceux qui se sont fait avoir sont des pigeons.
Déjà, “sécurité” et “Google” dans la même phrase c’est louche… " />
« 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…
Le 24/03/2015 à 18h11
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.
Le 24/03/2015 à 18h12
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.
Le 24/03/2015 à 18h26
Le 24/03/2015 à 18h43
ce qui est très souvent le cas.
Le 24/03/2015 à 18h43
Sauf erreur de ma part, le problème ne doit pas être trop grave pour les utilisateurs de Firefox … En effet 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 :
 https://wiki.mozilla.org/SecurityEngineering/Public_Key_Pinning#Implementation_s…
/Xavier