HPKP : fonc­tion­ne­ment de Public Key Pinning, extension de HTTP

Les canaux de trans­mis­sion sécurisés sont une condition préalable im­por­tante pour tra­vail­ler nor­ma­le­ment avec des données nu­mé­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 trans­mis­sion soit alors bien sécurisé. Ce n’est donc pas un hasard s’il est courant de trans­mettre des in­for­ma­tions con­fi­den­tielles ex­clu­si­ve­ment via des con­nexions VPN ou SSL/TLS. Avec leurs propres serveurs DNS et des autorités de cer­ti­fi­ca­tions sé­lec­tion­nées, les en­tre­prises et les ins­ti­tu­tions veillent à ce que ces tech­no­lo­gies de protocole soient pra­ti­que­ment in­vio­lables. Cependant, les uti­li­sa­teurs actifs en dehors de ces struc­tures sont soumis à la hié­rar­chie publique des DNS et des autorités de cer­ti­fi­ca­tions, ce qui augmente fortement la pro­ba­bi­lité d’une attaque de l’homme du milieu sur les données.

La raison prin­ci­pale de l’aug­men­ta­tion du risque au niveau de la sécurité est la con­tre­fa­çon, la fal­si­fi­ca­tion de cer­ti­fi­cats qui sont émis par des autorités de cer­ti­fi­ca­tion douteuses ou frau­du­leuses. L’uti­li­sa­teur a donc confiance et espère que la connexion et toutes les données sont sé­cu­ri­sées, alors qu’en réalité, la supposée autorité de cer­ti­fi­ca­tion est res­pon­sable du contraire. Avec le HTTP Public Key Pinning (HPKP), Google a introduit en 2011 une solution qui est main­te­nant 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 con­nexions 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 cer­ti­fi­ca­tion proposée pour la trans­mis­sion 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 cer­ti­fi­cat, un message d’erreur s’affiche et la connexion n’est pas établie. Ce processus de vé­ri­fi­ca­tion est également connu sous le nom de « Pin va­li­da­tion ». Les entrées des Pins dans l’en-tête HTTP res­semblent à ceci :

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

• Pin : la directive pin est la partie la plus im­por­tante de l‘entrée. En tant que telle, la directive se compose d’un nom et d’une valeur. Le nom fournit des in­for­ma­tions sur l’al­go­rithme utilisé pour le cryptage. À ce jour, seul le SHA256 est ici possible. La valeur de hachage à l’intérieur des guil­le­mets est une chaîne de ca­rac­tères codée Base64, également connue sous le nom de Fin­ger­print. Une directive Pin séparée doit toujours être définie pour chaque clef (y compris pour les clefs de sau­ve­garde).
   
• 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).
   
• in­clu­de­Sub­Do­mains : l‘ins­truc­tion in­clu­de­Sub­Do­mains est fa­cul­ta­tive et ne nécessite pas de valeur. Il signale au client que les règles de cer­ti­fi­ca­tion définies s’ap­pli­quent non seulement au domaine appelé, mais aussi à tous les sous-domaines ap­par­te­nant à l’hôte.
   
• report-ur i : si la directive report-uri est définie, toutes les ten­ta­tives de va­li­da­tion de Pin qui ont échouées sont envoyées à l’URL spécifiée. Cela ne doit pas né­ces­sai­re­ment être sur le même domaine Internet que l‘hôte contacté, qui est ainsi informé de l’échec des ten­ta­tives d’ins­tal­la­tion.

Pour utiliser les pos­si­bi­li­tés du HPKP, vous devez d’abord dé­ter­mi­ner quelles clefs publiques vous souhaitez « épingler » (pinning). En principe, vous pouvez sé­lec­tion­ner n’importe quelle clef publique contenue dans la chaîne de cer­ti­fi­ca­tion, qu’il s’agisse d’un cer­ti­fi­cat de serveur racine, in­ter­mé­diaire ou personnel. Cependant, si vous choi­sis­sez des autorités de cer­ti­fi­ca­tion externes, vous devez toujours garder à l’esprit que tous les cer­ti­fi­cats de cette autorité sont ensuite con­si­dé­rés comme valides par les clients et con­dui­sent à une va­li­da­tion réussie du Pin.

Si votre propre clef de serveur est épinglée et si la clef devient inu­ti­li­sable ou se perd en raison d’un défaut matériel c’est d’autant plus grave. Puisque les clients ont sau­ve­gardé 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’ex­pi­ra­tion de ce délai. Par con­sé­quent, les uti­li­sa­teurs ne pour­raient plus accéder à votre serveur. Pour éviter ce scénario, la norme HPKP (RFC 7569) prévoit l’uti­li­sa­tion sup­plé­men­taire d’un Pin de sau­ve­garde 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 cer­ti­fi­cat pour le domaine cor­res­pon­dant en cas de problème. Ce processus se nomme Cer­ti­fi­cate Signing Request (CSR) ou demande de signature de cer­ti­fi­cat.

Si HTTP Public Key Pinning doit fonc­tion­ner sur votre serveur, il est né­ces­saire 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 exis­tantes est l’ap­pli­ca­tion open source openssl, que vous pouvez utiliser depuis la ligne de commande de votre système. La commande par défaut pour les cer­ti­fi­cats x.509 est RFC 7469 :

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

Dans l‘étape suivante, con­fi­gu­rez la Cer­ti­fi­cate Signing Request (ici : backup.csr) pour votre clef de sau­ve­garde 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 sau­ve­garde (Back up Key) HPKP doit remplacer la clef standard en cas de problème, il est logique de la conserver sé­pa­ré­ment. Dans le meilleur des cas, choi­sis­sez une pla­te­forme de stockage externe à laquelle vous pouvez accéder à tout moment et de n’importe où. De plus, l’uti­li­sa­tion d’un ges­tion­naire de mots de passe est re­com­man­dée : si vous sécurisez en outre la Cer­ti­fi­cate Signing Request et la clef cor­res­pon­dante 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 con­nexions SSL/TLS de votre projet Internet est presque im­pos­sible. La prin­ci­pale critique contre le Public Key Pinning concerne le scénario d’attaque suivant, qui ne devient possible que grâce à l’uti­li­sa­tion de la technique de Pinning :

1. Un hacker accède à votre serveur
2. Il installe un nouveau cer­ti­fi­cat SSL/TLS et créé sa propre paire de clefs.
3. Pour la clef publique, il génère aussi la valeur de hachage ap­pro­priée et la saisit dans la zone cor­res­pon­dante de l’en-tête Cer­ti­fi­cate Pinning au lieu de vos Pins.
4. Les uti­li­sa­teurs ou clients qui appellent votre projet Web pour la première fois recevront main­te­nant le mauvais Pin et ne seront pas en mesure d’établir une connexion sécurisée à votre serveur.
5. Si l’attaquant supprime le cer­ti­fi­cat de votre serveur, ces uti­li­sa­teurs se verront alors refuser l’accès à votre site jusqu’à la date d’ex­pi­ra­tion du mauvais code Pin.
6. En plus de vous infliger des dommages par la perte de trafic, le hacker a aussi théo­ri­que­ment la pos­si­bi­lité de vous facturer pour la li­bé­ra­tion du mauvais cer­ti­fi­cat et de vous faire ainsi du chantage.

Bien que ce scénario soit théo­ri­que­ment possible, il est loin d’être un argument contre l’uti­li­sa­tion 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 in­for­ma­tiques. Si vous utilisez des Pins, vous devez aussi sen­si­bi­li­ser votre logiciel de sur­veil­lance afin d’être im­mé­dia­te­ment informé des chan­ge­ments dans les en-têtes HPKP pour que vous puissiez agir à temps. Une solution possible du côté client serait des mé­ca­nismes de réi­ni­tia­li­sa­tion des Pins qui sup­pri­ment ré­gu­liè­re­ment les Pins « mal­veil­lants » connus.

D’autres point négatifs qui sont critiqués sont gé­né­ra­le­ment la faible dis­tri­bu­tion et la com­plexité associée à la con­fi­gu­ra­tion du Public Key Pinnings . La raison prin­ci­pale est pro­ba­ble­ment que la norme est souvent mal connue ou pas du tout connue.