Épinglage de certificats dans les applications mobiles et de bureau

TLS standard fait confiance à n’importe quel certificat signé par l’une des quelque 150 CA racines préinstallées dans le système d’exploitation. Si une CA racine est compromise ou contrainte, un attaquant peut obtenir un certificat pour n’importe quel domaine et intercepter le trafic TLS. L’épinglage des certificats limite la confiance à un certificat ou à une clé publique précis, quelle que soit la CA qui l’a signé. Une application utilisant l’épinglage rejette les connexions à ses serveurs sauf si le serveur présente exactement le certificat ou la clé attendus. Cette protection est particulièrement utile pour les applications mobiles, car les utilisateurs ne peuvent pas inspecter le trafic réseau et les solutions MDM d’entreprise peuvent installer des CA racines d’entreprise.

L’épinglage peut s’effectuer à trois niveaux de granularité : (1) Épinglage du certificat complet : le certificat exact encodé en DER doit correspondre. C’est la méthode la plus fragile : elle cesse de fonctionner lors de tout renouvellement de certificat. (2) Épinglage de la clé publique : seuls les octets SubjectPublicKeyInfo (SPKI) sont comparés. Cette méthode survit au renouvellement du certificat si la même paire de clés est conservée. (3) Hachage de SPKI : stocker SHA-256(SPKI) plutôt que la clé brute. Il s’agit de l’approche HTTP Public Key Pinning (HPKP) et de la configuration de sécurité réseau Android. L’épinglage de la clé publique ou de SPKI est privilégié : il résiste à la rotation de la CA et au renouvellement du certificat tout en détectant un MITM utilisant une autre paire de clés.

Android (API 24 et versions ultérieures) fournit un mécanisme déclaratif d’épinglage via le fichier XML de configuration de sécurité réseau. Le fichier res/xml/network_security_config.xml définit les épinglages par domaine : pin-set avec digest="SHA-256" et le hachage SPKI encodé en base64. L’application référence ce fichier dans AndroidManifest.xml via android:networkSecurityConfig. Android applique les épinglages à toutes les connexions HTTP effectuées au moyen de HttpsURLConnection et d’OkHttp standard (lorsque le gestionnaire de confiance de la plateforme est utilisé). Le pin-set exige au moins un épinglage de secours (une clé ou une CA différente) afin d’éviter le blocage si la clé principale est compromise. L’expiration de l’épinglage (attribut expiration) force les applications à être mises à jour avant que les épinglages ne deviennent obsolètes.

Les applications iOS implémentent l’épinglage dans les délégués de NSURLSession. La méthode déléguée URLSession(_:didReceive:completionHandler:) reçoit l’objet de confiance du serveur. L’application appelle SecTrustEvaluateWithError pour valider la chaîne, puis extrait le certificat feuille avec SecTrustGetCertificateAtIndex(trust, 0), exporte ses octets SPKI, les hache avec SHA-256 et les compare à l’empreinte stockée. TrustKit (bibliothèque libre) encapsule ce modèle avec un épinglage fondé sur la configuration, prenant en charge plusieurs épinglages, la correspondance des sous-domaines et le mode de rapport uniquement. La sécurité du transport des applications (ATS) d’Apple est distincte de l’épinglage : ATS impose des versions TLS minimales, mais n’épingle pas les clés.

HTTP Public Key Pinning (HPKP, RFC 7469) tentait d’ajouter l’épinglage aux navigateurs web au moyen d’en-têtes de réponse HTTP : Public-Key-Pins: pin-sha256="base64=="; max-age=5184000; includeSubDomains. Le navigateur mémorisait l’épinglage pendant la durée max-age et rejetait les connexions vers des clés non correspondantes. HPKP a été déclaré obsolète par Chrome en 2017, puis supprimé en 2019 en raison de défaillances catastrophiques : une seule mauvaise configuration ou la perte d’une clé pouvait bloquer définitivement l’accès des utilisateurs à un site web, sans possibilité de récupération. HPKP est désormais pratiquement abandonné dans les navigateurs web ; l’épinglage au niveau de l’application dans les applications mobiles reste viable, car les mises à jour de l’application peuvent fournir de nouveaux épinglages.

OkHttp (largement utilisé sur Android) prend en charge l’épinglage via CertificatePinner : CertificatePinner.Builder().add("api.example.com", "sha256/AAAA...==", "sha256/BBBB...==").build(). Le second épinglage est celui de secours. OkHttp vérifie qu’au moins un épinglage correspond à un certificat quelconque de la chaîne du serveur : feuille, intermédiaire ou racine. Cela permet d’épingler une CA intermédiaire (en survivant à la rotation du certificat feuille) ou la CA racine (en survivant à la rotation de la CA intermédiaire). OkHttp lève une SSLPeerUnverifiedException avec un message utile qui répertorie les hachages SPKI réels du serveur, ce qui simplifie l’extraction des épinglages pendant le développement.

L’épinglage complique l’interception du trafic, mais n’est pas inviolable. Techniques courantes de contournement sur mobile : (1) Hooks Frida : injecter du JavaScript dans le processus de l’application pour intercepter la méthode de vérification de l’épinglage et renvoyer true systématiquement. (2) Outils SSLUnpinning : scripts Frida/Objection automatisés ciblant les bibliothèques d’épinglage courantes (TrustKit, OkHttp, SecTrust natif). (3) ROM personnalisée : obtenir l’accès root à l’appareil et modifier la pile TLS. (4) Reconditionnement : décompiler l’APK, modifier la configuration d’épinglage et reconditionner l’application avec un nouveau certificat. (5) Modification de la mémoire : modifier le code-octet de vérification lors de l’exécution. Mesures d’atténuation : détection du root ou du jailbreak, obfuscation du code et contrôles d’intégrité (SafetyNet/App Attest).

Le principal risque opérationnel de l’épinglage des certificats est le blocage de sa propre application : si la clé de production est perdue ou si le certificat expire alors que la clé de secours est indisponible, les utilisateurs sont bloqués jusqu’à la publication d’une mise à jour de l’application (de quelques jours à quelques semaines). Bonnes pratiques : (1) Épinglez toujours au moins deux clés : la clé actuelle et une clé de secours générée à l’avance et conservée hors ligne (dans un HSM ou dans un environnement isolé). (2) Définissez une date d’expiration de l’épinglage et publiez les mises à jour de l’application avant cette date. (3) Surveillez les échecs d’épinglage au moyen du mode de rapport uniquement avant d’appliquer le contrôle. (4) Maintenez un processus de mise à jour d’urgence de l’application (examen accéléré) pour les incidents de rotation des épinglages. (5) Épinglez au niveau de la CA intermédiaire, et non au niveau du certificat feuille, afin d’autoriser la rotation des certificats feuille sans mise à jour de l’application.

Les applications de bureau écrites avec Electron, Qt ou du code natif peuvent implémenter l’épinglage à l’aide des interfaces de leur pile TLS. Les applications Electron utilisent l’événement app.on("certificate-error") et session.setCertificateVerifyProc() pour implémenter une vérification personnalisée. Le code réseau Qt utilise QSslSocket avec un rappel de vérification personnalisé. Les applications .NET utilisent ServicePointManager.ServerCertificateValidationCallback. Les applications natives Windows utilisent WinHTTP avec une inspection manuelle des certificats. Les applications de bureau font face à des difficultés supplémentaires : l’interception TLS au niveau du système d’exploitation par les proxys d’entreprise est courante, et les utilisateurs peuvent s’attendre à ce que la fonctionnalité de proxy fonctionne ; il faut donc décider si l’épinglage s’applique uniquement à certains points de terminaison.

L’épinglage des certificats complique les tests automatisés et les processus d’intégration et de déploiement continus. Les tests d’intégration qui effectuent de véritables appels HTTPS vers des serveurs de préproduction doivent utiliser des certificats de test dont les hachages SPKI sont épinglés dans une configuration de test. Approches possibles : (1) Variantes de compilation : la version de débogage/préproduction inclut les épinglages des serveurs de préproduction ; la version de production épingle ceux de la production. (2) Remplacements de la configuration de sécurité réseau : Android autorise une configuration d’épinglage réservée au débogage. (3) Serveur simulé : intercepter au niveau de la couche du client HTTP, avant TLS, afin de contourner entièrement l’épinglage. (4) CA auto-signée pour l’intégration continue : émettre des certificats de test depuis une CA d’intégration continue dont la racine n’est approuvée que dans les versions de test. Ne publiez jamais en production une version dont l’épinglage est désactivé.

Les épinglages de certificats sont généralement des hachages de clés publiques RSA ou EC. Lorsque la migration post-quantique commencera, les serveurs passeront à ML-DSA (CRYSTALS-Dilithium) ou à des clés hybrides. Les hachages SPKI épinglés changeront, car le type et l’encodage de la clé seront différents. Les applications qui épinglent des certificats feuille ou des clés publiques devront effectuer des mises à jour coordonnées : (1) Publier une nouvelle version de l’application contenant le hachage SPKI post-quantique comme épinglage de secours avant la migration du serveur. (2) Achever la migration du serveur. (3) Publier une mise à jour supprimant l’ancien épinglage classique. La période de transition exige une coordination rigoureuse. Les applications qui épinglent des CA intermédiaires ou racines seront moins affectées : seule la clé de la CA change, et pas nécessairement au même moment que les certificats feuille.

Pourquoi est-il préférable d’épingler le hachage de SubjectPublicKeyInfo (SPKI) plutôt que le certificat complet ?

L’épinglage des certificats restreint la confiance TLS à un certificat ou à une clé publique donné, ce qui protège contre la compromission d’une CA et les attaques MITM. L’épinglage du hachage SPKI (SHA-256 de SubjectPublicKeyInfo) est préféré à l’épinglage du certificat complet, car il résiste mieux aux renouvellements. Android utilise un fichier XML de configuration de la sécurité réseau ; iOS utilise un délégué URLSession avec les API SecTrust ; OkHttp prend en charge CertificatePinner. Incluez toujours une épingle de secours pour éviter de vous verrouiller vous-même hors de l’application. HPKP (en-tête HTTP de navigateur) est obsolète. L’épinglage peut être contourné à l’aide de points d’accroche Frida et de modifications de ROM. La migration vers des clés post-quantiques nécessite des mises à jour coordonnées des applications afin d’actualiser les hachages SPKI.