Vous avez probablement déjà entendu parler du protocole HTTPS et de la sécurité qu'il offre grâce au cadenas vert dans votre navigateur. Cependant, dans le domaine du développement d'applications, se fier aveuglément à la validité du certificat n'est pas toujours suffisant. Il existe un risque latent : même avec une connexion chiffrée, quelqu'un pourrait intercepter secrètement les échanges entre votre appareil et le serveur.
Pour pallier cette faille de sécurité, une technique appelée « épinglage de certificat » a été mise au point . Concrètement, elle indique à notre application : « Ne faites pas confiance à n’importe quelle autorité de certification ; n’acceptez la connexion que si le serveur présente exactement ce certificat ou cette clé publique. » C’est comme placer un gardien très strict à l’entrée de nos communications.
Qu’est-ce que le SSL Pinning exactement et pourquoi en avons-nous besoin ?
Pour bien comprendre cela, il faut d'abord rappeler que le protocole HTTPS standard repose sur une chaîne de confiance . Lorsque vous vous connectez à un serveur, celui-ci vous envoie son certificat numérique. Votre appareil mobile vérifie que ce document a été signé par une autorité de certification (AC) approuvée par le système d'exploitation. Si la signature est valide et que le certificat n'a pas expiré, la connexion est établie.
Le problème survient lorsqu'un attaquant parvient à infiltrer la connexion en cours de transmission, une attaque de type « homme du milieu » (MITM) . Si le pirate obtient d'une autorité de certification (AC) un certificat frauduleux mais valide, ou s'il parvient à installer un certificat racine malveillant sur l'appareil de la victime, le système d'exploitation autorisera la connexion. L'attaquant peut alors intercepter et modifier des données sensibles, telles que des informations bancaires ou des mots de passe, sans que l'utilisateur ne s'aperçoive de rien.
C'est là qu'intervient le pinning. Au lieu de faire confiance à une autorité de certification reconnue, l'application stocke une copie du certificat ou du hachage de la clé publique du serveur. Lors de l'établissement de la connexion, l'application compare le certificat reçu avec celui qu'elle a stocké. S'ils ne correspondent pas bit à bit, la connexion est immédiatement interrompue, empêchant ainsi l'usurpation d'identité du serveur.
Types d'ancrage : certificats versus clés publiques
L'épinglage de certificats ne se fait pas toujours de la même manière. Selon ce que l'on choisit d'épingler, deux approches principales sont possibles. La première consiste à épingler le certificat complet (fichier .pem ou .der). C'est l'option la plus simple à mettre en œuvre, mais aussi la plus fastidieuse à maintenir. En effet, à chaque expiration et renouvellement du certificat serveur, il faut mettre à jour l'application dans le magasin de certificats, sous peine d'interruption de service pour les utilisateurs.
La seconde option est l'épinglage de clé publique . Dans ce cas, seul le hachage (généralement SHA-256) de la clé publique du certificat est stocké. L'avantage principal est que la clé publique reste intacte même en cas de renouvellement du certificat, ce qui améliore la flexibilité du certificat et réduit la fréquence des mises à jour forcées de l'application. De plus, le stockage du seul hachage rend le code plus propre et plus difficile à extraire par rétro-ingénierie.
Mise en œuvre technique sur différentes plateformes
Si nous travaillons avec AndroidLa méthode la plus moderne consiste à utiliser le fichier network_security_config.xmlDans ce fichier XML, nous définissons les domaines et les hachages des certificats (codes PIN) que nous souhaitons autoriser, ce qui nous permet de Activer les paramètres de sécurité essentiels sur Android nativement. Ensuite, nous lions simplement ce fichier dans le AndroidManifest.xmlAuparavant, les opérations plus complexes étaient réalisées en écrasant la classe. DefaultHttpClient et la gestion des magasins de certificats Java via keytoolCependant, la configuration basée sur XML est beaucoup plus efficace.
Dans l'écosystème de iOSLes choses changent un peu. Nous pouvons tirer parti d'App Transport Security (ATS) en configurant le fichier Info.plist pour définir les domaines ancrés. Cependant, pour un contrôle complet, il est courant d'implémenter une validation à l'exécution à l'aide de URLSessionDelegateDans la méthode d'authentification par défi, nous extrayons le certificat du serveur et le comparons avec le certificat stocké localement dans le paquet d'application.
Pour ceux qui utilisent Cadres de condensateurs ou hybridesIl existe des plugins comme @capgo/capacitor-ssl-pinning qui unifient le processus. Dans ces cas, la configuration est généralement effectuée dans le fichier de configuration de l'application, en spécifiant la liste des certificats et en activant la validation. Il est essentiel de tester ces implémentations avec des outils tels que Proxy Charles, en simulant une attaque MITM pour confirmer que l'application rejette effectivement la connexion lorsque le certificat n'est pas celui attendu.
Risques, limitations et maintenance
L'utilisation d'un code PIN n'est pas sans inconvénients. Le principal danger réside dans le blocage lié à l'expiration du certificat . Si le certificat du serveur expire et que l'application n'a pas été mise à jour avec le nouveau code PIN, tous les utilisateurs rencontreront des erreurs de connexion. Pour éviter ce problème, il est recommandé d'utiliser des codes PIN de secours . Nous stockons le hachage d'une clé publique secondaire que nous n'utiliserons qu'en cas d'urgence ou de renouvellement imprévu du certificat.
En revanche, l'épinglage peut s'avérer complexe pour les développeurs qui doivent déboguer leurs communications. Pour que les outils de surveillance fonctionnent correctement, il est parfois nécessaire de désactiver l'épinglage dans les environnements de développement ou de créer des versions de débogage spécifiques, en veillant toujours à ce que cette fonctionnalité soit activée dans la version de production destinée à l'utilisateur final.
Concernant le web, Chrome a été un pionnier dans la mise en œuvre de concepts similaires. Il utilise HSTS (HTTP Strict Transport Security) pour imposer l'utilisation du protocole HTTPS et maintient une liste de sites « préchargés » afin de prévenir les vulnérabilités liées au premier contact. Bien que la norme HPKP ait existé pour le web, elle a fini par tomber en désuétude car elle était trop risquée et pouvait rendre des sites web inaccessibles en cas d'erreur de configuration.
La mise en œuvre de l'épinglage de certificats est une décision stratégique qui concilie sécurité maximale et continuité de service. En limitant la confiance à des entités spécifiques, nous protégeons les communications contre les attaques sophistiquées, à condition de maintenir un contrôle rigoureux du cycle de vie de nos clés et certificats afin d'éviter toute interruption d'accès pour nos clients.
