HPKP : fonctionnement de Public Key Pinning, extension de HTTP

Les canaux de transmission sécurisés sont une condition préalable importante pour travailler normalement avec des données numériques. Surtout si vous envoyez et recevez des paquets de données en voyage ou à distance, il est essentiel que l’ensemble du chemin de transmission soit alors bien sécurisé. Ce n’est donc pas un hasard s’il est courant de transmettre des informations confidentielles exclusivement via des connexions VPN ou SSL/TLS. Avec leurs propres serveurs DNS et des autorités de certifications sélectionnées, les entreprises et les institutions veillent à ce que ces technologies de protocole soient pratiquement inviolables. Cependant, les utilisateurs actifs en dehors de ces structures sont soumis à la hiérarchie publique des DNS et des autorités de certifications, ce qui augmente fortement la probabilité d’une attaque de l’homme du milieu sur les données.

La raison principale de l’augmentation du risque au niveau de la sécurité est la contrefaçon, la falsification de certificats qui sont émis par des autorités de certification douteuses ou frauduleuses. L’utilisateur a donc confiance et espère que la connexion et toutes les données sont sécurisées, alors qu’en réalité, la supposée autorité de certification est responsable du contraire. Avec le HTTP Public Key Pinning (HPKP), Google a introduit en 2011 une solution qui est maintenant spécifiée en standard dans la RFC 7469.

Public Key Pinning est une extension du protocole de transfert HTTP (Hypertext Transfer Protocol) qui vous permet de spécifier la clef publique définie pour les futures connexions SSL/TLS vers un hôte. De cette façon, la première fois qu’un client accédant vous contact, il saura à quelles clefs publiques il peut faire confiance lorsqu’il se connecte à cet hôte. Il s’agit donc aussi d’une procédure de « Trust on First Use » (ToFU), c’est à dire de confiance au premier accès. Chaque entrée d’une clef vérifiée est appelée un « Pin », d’où le mécanisme tire son nom. Tous les Pins créés sont transmis au client dans l’en-tête HTTP et sont ensuite stockés pour la période spécifiée.

Lorsqu’une nouvelle demande de connexion est réalisée, le client vérifie si la chaîne de certification proposée pour la transmission SSL/TLS contient une clef publique qui lui a déjà été transmise via HPKP. Si ce n’est pas le cas, par exemple avec un faux certificat, un message d’erreur s’affiche et la connexion n’est pas établie. Ce processus de vérification est également connu sous le nom de « Pin validation ». Les entrées des Pins dans l’en-tête HTTP ressemblent à ceci :

L’exemple montre les quatre directives qu’une entrée de Pin peut contenir dans l’en-tête HTTP :

• Pin : la directive pin est la partie la plus importante de l‘entrée. En tant que telle, la directive se compose d’un nom et d’une valeur. Le nom fournit des informations sur l’algorithme utilisé pour le cryptage. À ce jour, seul le SHA256 est ici possible. La valeur de hachage à l’intérieur des guillemets est une chaîne de caractères codée Base64, également connue sous le nom de Fingerprint. Une directive Pin séparée doit toujours être définie pour chaque clef (y compris pour les clefs de sauvegarde).
   
• max-age : la directive max-age spécifie la durée de validité d’un Pin en secondes. Il indique au client combien de temps il doit évaluer une clef publique en tant que clé sécurisée. Dans l’exemple utilisé ici, les Pins énumérés sont jetés après 30 jours (2 592 000 secondes).
   
• includeSubDomains : l‘instruction includeSubDomains est facultative et ne nécessite pas de valeur. Il signale au client que les règles de certification définies s’appliquent non seulement au domaine appelé, mais aussi à tous les sous-domaines appartenant à l’hôte.
   
• report-ur i : si la directive report-uri est définie, toutes les tentatives de validation de Pin qui ont échouées sont envoyées à l’URL spécifiée. Cela ne doit pas nécessairement être sur le même domaine Internet que l‘hôte contacté, qui est ainsi informé de l’échec des tentatives d’installation.

Pour utiliser les possibilités du HPKP, vous devez d’abord déterminer quelles clefs publiques vous souhaitez « épingler » (pinning). En principe, vous pouvez sélectionner n’importe quelle clef publique contenue dans la chaîne de certification, qu’il s’agisse d’un certificat de serveur racine, intermédiaire ou personnel. Cependant, si vous choisissez des autorités de certification externes, vous devez toujours garder à l’esprit que tous les certificats de cette autorité sont ensuite considérés comme valides par les clients et conduisent à une validation réussie du Pin.

Si votre propre clef de serveur est épinglée et si la clef devient inutilisable ou se perd en raison d’un défaut matériel c’est d’autant plus grave. Puisque les clients ont sauvegardé le Pin pour la période de validité spécifiée lorsqu’ils y ont accédé pour la première fois, ils ne peuvent accepter un nouveau Pin avant l’expiration de ce délai. Par conséquent, les utilisateurs ne pourraient plus accéder à votre serveur. Pour éviter ce scénario, la norme HPKP (RFC 7569) prévoit l’utilisation supplémentaire d’un Pin de sauvegarde ou de secours (Back up Pin). Celui.ci est également fourni via l’en-tête HTTP et peut être utilisé pour émettre un nouveau certificat pour le domaine correspondant en cas de problème. Ce processus se nomme Certificate Signing Request (CSR) ou demande de signature de certificat.

Si HTTP Public Key Pinning doit fonctionner sur votre serveur, il est nécessaire que HTTPS soit alors déjà configuré. Comme au moins deux clefs publiques doivent être épinglées, la première étape consiste donc à générer ces Pins. La solution la plus simple pour calculer les valeurs de hachage des clés publiques existantes est l’application open source openssl, que vous pouvez utiliser depuis la ligne de commande de votre système. La commande par défaut pour les certificats x.509 est RFC 7469 :

De cette façon, vous créez la séquence Base64 pour la clef public.key pour le certificat en exemple certificate.pem. Celle-ci est éditée sur la sortie standard et se termine toujours par le signe („=“).

Dans l‘étape suivante, configurez la Certificate Signing Request (ici : backup.csr) pour votre clef de sauvegarde ou Back up Key (ici : backup.key) :

Utilisez ensuite openssl pour calculer la valeur de hachage de cette clef :

Étant donné que la clef de sauvegarde (Back up Key) HPKP doit remplacer la clef standard en cas de problème, il est logique de la conserver séparément. Dans le meilleur des cas, choisissez une plateforme de stockage externe à laquelle vous pouvez accéder à tout moment et de n’importe où. De plus, l’utilisation d’un gestionnaire de mots de passe est recommandée : si vous sécurisez en outre la Certificate Signing Request et la clef correspondante dans votre propre base de données à l’aide d’un tel logiciel, vous êtes sécurisé, et la ou les clés de secours (Back up Key) sont prêtes à être utilisées au moment décisif.

Grâce à l‘approche « Trust on First Use »,  HPKP prend effet dès le premier contact avec le client. Cependant, la première visite au cours de laquelle le serveur transmet les clefs épinglées n’est pas protégée par la procédure elle-même. Mais, ce petit écart n’entraine des problèmes que dans de rares cas isolés, alors qu’un nombre plus important d’attaques non détectées sur les connexions SSL/TLS de votre projet Internet est presque impossible. La principale critique contre le Public Key Pinning concerne le scénario d’attaque suivant, qui ne devient possible que grâce à l’utilisation de la technique de Pinning :

1. Un hacker accède à votre serveur
2. Il installe un nouveau certificat SSL/TLS et créé sa propre paire de clefs.
3. Pour la clef publique, il génère aussi la valeur de hachage appropriée et la saisit dans la zone correspondante de l’en-tête Certificate Pinning au lieu de vos Pins.
4. Les utilisateurs ou clients qui appellent votre projet Web pour la première fois recevront maintenant le mauvais Pin et ne seront pas en mesure d’établir une connexion sécurisée à votre serveur.
5. Si l’attaquant supprime le certificat de votre serveur, ces utilisateurs se verront alors refuser l’accès à votre site jusqu’à la date d’expiration du mauvais code Pin.
6. En plus de vous infliger des dommages par la perte de trafic, le hacker a aussi théoriquement la possibilité de vous facturer pour la libération du mauvais certificat et de vous faire ainsi du chantage.

Bien que ce scénario soit théoriquement possible, il est loin d’être un argument contre l’utilisation du HTTP Public Key Pinning. C’est parce que le hacker pourrait aussi bien mettre en place l’extension du protocole HTTP lui-même dès qu’il a accès au serveur. Le problème prouve à quel point il est important de protéger votre projet contre les attaques des pirates informatiques. Si vous utilisez des Pins, vous devez aussi sensibiliser votre logiciel de surveillance afin d’être immédiatement informé des changements dans les en-têtes HPKP pour que vous puissiez agir à temps. Une solution possible du côté client serait des mécanismes de réinitialisation des Pins qui suppriment régulièrement les Pins « malveillants » connus.

D’autres point négatifs qui sont critiqués sont généralement la faible distribution et la complexité associée à la configuration du Public Key Pinnings . La raison principale est probablement que la norme est souvent mal connue ou pas du tout connue.