Google va supprimer le support de Public Key Pinning de Chrome
Le mécanisme de sécurité qui protège les sites Web de l'usurpation d'identité

Le , par Stéphane le calme, Chroniqueur Actualités
Dans un forum de discussion réservé au développement Chromium, Google a annoncé son intention de déprécier puis de supprimer entièrement le support de Public Key Pinning (PKP) de Chrome :

« Cela supprimera d'abord la prise en charge de PKP basé sur HTTP ("dynamic pins"), dans lequel l'agent utilisateur apprend des ensembles de pin pour les hôtes par des en-têtes HTTP. Nous aimerions le faire dans Chrome 67, qui devrait être dans le canal Stable le 29 mai 2018.

« Enfin, supprimer la prise en charge de PKP intégré ("static stakes") à un stade ultérieur lorsque Chrome exige la transparence des certificats pour tous les certificats de confiance publics (pas seulement les certificats de confiance publics nouvellement émis). (Nous ne savons pas encore quand cela sera fait.) »

Pour rappel PKP est un système décrit dans l'IETF RFC-7469 que les webmasters peuvent utiliser avec les sites HTTPS. PKP, également appelé HPKP (Public Key Pinning pour HTTP), est une fonctionnalité de sécurité qui dit au client web d'associer une clé publique cryptographique avec un certain serveur web pour éviter les attaques MITM avec des certificats contrefaits.

Pour s'assurer de l’authenticité de la clé publique du serveur utilisé dans une session TLS, cette clé publique est enveloppée dans un certificat X.509 qui est généralement signé par une autorité de certification. Les clients web tels que les navigateurs font confiance à beaucoup de ces autorités de certification, et chacune d'entre elles peut créer des certificats pour des domaines arbitraires. Si un attaquant est capable de compromettre une seule de ces CA, il peut pratiquer des attaques MITM sur diverses connexions TLS. HPKP peut contourner cette menace pour le protocole HTTPS en disant au client web quelles clés publiques appartiennent à un certain serveur web.

HPKP est une technique qui s'appuie sur la confiance au premier accès (TOFU, Trust on First Use). La première fois un serveur web dit au client en utilisant l'en-tête HTTP HPKP quelles clés publiques lui appartiennent, le client sauvegarde cette information pour une période de temps donnée. Quand le client visite le serveur à nouveau, il s'attend à un certificat contenant une clé publique dont l'empreinte est sauvegardée. Si le serveur présente une clé publique inconnue, le client doit présenter un avertissement à l'utilisateur.

En clair, voici le fonctionnement : à la première connexion réussie, le site présente une liste représentant les clés de confiance. Le navigateur mémorise cette liste. Lors des connexions suivantes, si la clé de chiffrement présentée n'est pas présente dans la liste mémorisée, le navigateur refuse la connexion et bloque le site puis s'y reconnecte.

Pourquoi Google a-t-il décidé de supprimer le support de PKP ?

Lors de son lancement, les experts en sécurité ont salué PKP comme étant une couche de sécurité supplémentaire que les opérateurs de sites pourraient déployer pour accompagner HTTPS.

En réalité, PKP était difficile à déployer, et toute erreur dans sa configuration pouvait conduire à des scénarios catastrophiques où les utilisateurs auraient téléchargé des clés incorrectes, ou un certificat différent, empêchant complètement les utilisateurs d'accéder aux URL pendant des heures, des jours ou même des mois. Il est évident que pour les sites qui voulaient s’appuyer sur le trafic publicitaire pour gérer leurs frais de serveurs, il n’était pas question de perdre le moindre pourcentage de trafic. Aussi, PKP est devenu un véritable problème et de nombreux webmasters sont restés à l'écart.

En outre, il existait également un scénario théorique dans lequel un attaquant pouvait utiliser PKP pour détourner les visiteurs d'un site en émettant ses propres clés PKP qui cesseraient de fonctionner dès lors que sa violation serait découverte. Le code pour de telles attaques est disponible sur GitHub.

C'était l'une des principales raisons pour lesquelles PKP n'a pas été adopté. Une étude Neustar datant de mars 2016 a montré que le déploiement de PKP ne concernait que 0,09 % de tous les sites HTTPS. En août 2017, le baromètre a à peine atteint les 0,4 % de tous les sites du Alexa Top 1 million.


Dans son billet, l’entreprise reconnaît que PKP offre un bon moyen de se défendre contre la mauvaise utilisation des certificats, en fournissant un mécanisme Web (HPKP) pour les sites afin de limiter l'ensemble des autorités de certification (CA) pouvant émettre pour leur domaine. Toutefois, Google estime qu’en vertu de l'Open Web Platforms, cela expose à des considérations externes : « En particulier, le choix et la sélection des autorités de certification est une décision de sécurité au niveau du produit, prise par les navigateurs ou par les fournisseurs de systèmes d'exploitation, la signature croisée et d'autres aspects de la hiérarchie PKI sont réalisés indépendamment par les autorités de certification. »

Par conséquent, les opérateurs de site rencontrent des difficultés pour sélectionner un ensemble fiable de clés à associer, et l'adoption de PKP est restée faible.

Concrètement :
  • il est difficile de créer un ensemble de broches dont le fonctionnement est garanti, en raison de la variance entre les magasins de confiance d'agent utilisateur et les opérations de CA ;
  • il y a un risque de rendre un site inutilisable ;
  • il y a un risque d'épinglage hostile, si un attaquant obtient un certificat mal délivré. Bien qu'il n'y ait pas eu de cas confirmé ou de rumeur à ce sujet, le risque est présent même pour les sites qui n'utilisent pas PKP.

Source : annonce de Google, PKP, IETF RFC-7469, scénario théorique, PoC sur GitHub, enquête Neustar, analyse du top 1 million d'Alexa


Vous avez aimé cette actualité ? Alors partagez-la avec vos amis en cliquant sur les boutons ci-dessous :
Contacter le responsable de la rubrique Accueil