SSL Pinning : essence, mécanisme et protection contre les attaques MITM

Qu'est-ce que SSL Pinning ?

SSL Pinning est un mécanisme de sécurité où une application mobile ou web mémorise un certificat serveur de confiance ou une clé publique et rejette toute connexion dont le certificat ne correspond pas à celui stocké. Dans le schéma HTTPS standard, le client vérifie le certificat via une chaîne de confiance jusqu'à l'AC racine — n'importe quelle AC peut signer un certificat pour n'importe quel domaine. SSL Pinning élimine cette faiblesse : au lieu de faire confiance à des centaines d'AC, l'application ne fait confiance qu'à un seul certificat spécifique.

Le problème de la vérification standard est que n'importe laquelle des centaines d'AC racines peut émettre un certificat valide pour votre domaine — accidentellement ou sous contrainte. Un attaquant qui obtient l'accès à un proxy d'entreprise avec son propre certificat racine peut effectuer une attaque MITM sans avertissement du navigateur. SSL Pinning ferme cette vulnérabilité : même si une AC émet un certificat frauduleux, l'application le rejettera car l'empreinte ne correspond pas à celle enregistrée.

Dans les applications mobiles, SSL Pinning est particulièrement important car les appareils fonctionnent souvent sur des réseaux non sécurisés — Wi-Fi public, proxys d'entreprise avec inspection du trafic, points d'accès infectés. Selon le Verizon Mobile Security Index (2025), plus de 60 % des fuites de données dans les applications mobiles sont liées à l'interception du trafic au niveau de la couche de transport.

Pourquoi SSL Pinning est nécessaire dans le développement mobile

Les applications mobiles transmettent des données sensibles — jetons d'authentification, informations de paiement, données personnelles des utilisateurs. Sans protection supplémentaire, HTTPS peut être compromis via le remplacement du certificat racine sur l'appareil — par exemple, après l'installation d'un profil d'entreprise ou d'une application malveillante. SSL Pinning garantit que même si une AC racine frauduleuse est installée sur l'appareil, l'application continuera à vérifier le certificat contre sa propre liste blanche.

Comment fonctionne SSL Pinning ?

Le processus SSL Pinning comprend trois étapes : capture de l'empreinte, vérification lors de la connexion et gestion des erreurs. Pendant le développement, l'ingénieur obtient l'empreinte SHA-256 du certificat du serveur (openssl x509 -fingerprint -sha256) et l'intègre dans le code de l'application ou le fichier de configuration. À chaque requête HTTPS, l'application calcule l'empreinte du certificat reçu et la compare à celle stockée — si les valeurs ne correspondent pas, la connexion est interrompue.

La première étape est le pinning au moment de la compilation : le développeur connaît les certificats du serveur à l'avance et intègre leurs hachages. La deuxième étape est le pinning à la première connexion (trust on first use, TOFU) : l'application mémorise le certificat lors de la première requête et l'utilise pour vérifier toutes les suivantes. TOFU est pratique pour les environnements dynamiques mais est vulnérable lors de la première attaque — si la première connexion est déjà interceptée, le certificat frauduleux sera accepté comme de confiance.

Un détail critique est les backup pins. Les certificats ont une date d'expiration et, lorsqu'ils sont remplacés, l'application sans mise à jour perdra la connexion au serveur. Les ingénieurs incluent 2 à 3 empreintes supplémentaires — par exemple, l'empreinte d'un certificat de secours et l'empreinte de l'AC racine. Si le certificat principal change, l'application vérifie par rapport aux backup pins et la connexion continue de fonctionner.

# Obtention de l'empreinte SHA-256 du certificat
openssl s_client -connect example.com:443 </dev/null 2>/dev/null | \
  openssl x509 -pubkey -noout | \
  openssl pkey -pubin -outform der | \
  openssl dgst -sha256 -binary | \
  base64

Types de SSL Pinning

Il existe deux approches principales pour implémenter le pinning : la fixation au certificat complet (certificate pinning) et la fixation à la clé publique (public key pinning). Chaque approche a ses propres forces et limitations qui affectent la sécurité et la maintenabilité.

Certificate Pinning

La fixation de certificat est la méthode la plus stricte. L'application stocke une copie du certificat de confiance ou de son empreinte SHA-256 et la compare au certificat du serveur lors de chaque connexion HTTPS. Cette méthode offre une sécurité maximale mais crée des problèmes lors de la rotation — les certificats durent généralement 1 à 2 ans, après quoi une mise à jour forcée de l'application est nécessaire. Recommandé pour les systèmes critiques avec un cycle de mise à jour contrôlé.

Public Key Pinning

La fixation de clé publique est une approche plus flexible. Au lieu du certificat entier, l'application ne mémorise que la clé publique RSA ou ECDSA du serveur. La clé peut rester inchangée lors de la réémission du certificat, si l'entreprise utilise la même paire de clés. Cela réduit la fréquence des mises à jour de l'application. Cependant, si la clé est compromise, un remplacement en cascade sur tous les clients sera nécessaire.

SSL Pinning sur iOS

Sur la plateforme Apple, SSL Pinning est implémenté via le délégué URLSession. Le développeur crée une classe implémentant le protocole URLSessionDelegate et surcharge la méthode didReceive challenge, où il vérifie manuellement le certificat du serveur par rapport aux empreintes stockées. Une approche alternative est d'utiliser Alamofire avec ServerTrustManager, ce qui simplifie la configuration.

class SSLPinningDelegate: NSObject, URLSessionDelegate {
    let pinnedHash = "sha256/Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg="

    func urlSession(_ session: URLSession,
        didReceive challenge: URLAuthenticationChallenge,
        completionHandler: @escaping (URLSession.AuthChallengeDisposition, URLCredential?) -> Void) {

        guard let serverTrust = challenge.protectionSpace.serverTrust
            else { return completionHandler(.cancelAuthenticationChallenge, nil) }

        if validate(serverTrust, pinnedHash) {
            completionHandler(.useCredential, URLCredential(trust: serverTrust))
        } else {
            completionHandler(.cancelAuthenticationChallenge, nil)
        }
    }
}

Dans l'exemple, le délégué reçoit une demande d'authentification d'URLSession, extrait serverTrust du challenge et compare l'empreinte SHA-256 du certificat avec celle stockée. Si l'empreinte correspond — la connexion continue, sinon le challenge est rejeté. Pour la production, il vaut la peine d'ajouter la vérification de plusieurs backup pins et la journalisation des erreurs pour la surveillance.

Network Security Config sur iOS

À partir d'iOS 14, Apple a ajouté la prise en charge intégrée de Certificate Pinning via Info.plist. Le développeur spécifie les certificats de confiance dans la clé NSAppTransportSecurity avec le sous-dictionnaire NSPinnedDomains. Cette approche ne nécessite pas d'écrire de code mais est moins flexible — il est impossible de modifier dynamiquement les pins ou de journaliser les erreurs de vérification.

SSL Pinning sur Android

Sur Android, il existe trois principales façons d'implémenter SSL Pinning : via le CertificatePinner de la bibliothèque OkHttp, via Network Security Config en XML, et via une vérification personnalisée dans HttpsURLConnection. OkHttp est l'approche la plus populaire et recommandée, utilisée dans Retrofit et d'autres clients HTTP.

val certificatePinner = CertificatePinner.Builder()
    .add("api.example.com",
        "sha256/Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg=")
    .add("api.example.com",
        "sha256/FiPq6ePEsVRqZ1yW0F6wLgWi24BE7j5qLk0iL=")  // backup pin
    .build()

val client = OkHttpClient.Builder()
    .certificatePinner(certificatePinner)
    .build()

Dans la configuration OkHttp, le développeur spécifie le domaine et une ou plusieurs empreintes SHA-256. À la première empreinte, OkHttp compare le certificat du serveur avec les pins spécifiés. S'il n'y a pas de correspondance, le client lance SSLPeerUnverifiedException. Un backup pin est obligatoire — sans lui, lors du changement de certificat, les requêtes API échoueront immédiatement.

Network Security Configuration sur Android

Android prend en charge le Certificate Pinning déclaratif via la configuration XML à partir de l'API 24. Le fichier res/xml/network_security_config.xml contient une liste de domaines et leurs empreintes. Cette méthode est pratique pour les configurations statiques mais ne permet pas d'implémenter TOFU ou une logique de vérification personnalisée avec journalisation des anomalies.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-12-31">
            <pin digest="SHA-256">
                Wi24BE7j5qLk0iLvPq6ePEsVRqZ1yW0F6wLg=</pin>
            <pin digest="SHA-256">
                FiPq6ePEsVRqZ1yW0F6wLgWi24BE7j5qLk0iL=</pin>
        </pin-set>
    </domain-config>
</network-security-config>

Avantages et inconvénients de SSL Pinning

SSL Pinning augmente considérablement la sécurité d'une application mobile mais introduit des complexités opérationnelles. Le principal avantage est la protection contre les attaques MITM même en cas de compromission des AC racines. L'application ne fait confiance qu'aux certificats explicitement spécifiés par le développeur, et non à toute l'infrastructure des autorités de certification publiques. Ceci est particulièrement critique pour les applications financières, les messageries et les applications contenant des données sensibles.

Le principal inconvénient est la complexité de la rotation des certificats. Si un certificat expire ou est révoqué, les utilisateurs sans mise à jour de l'application perdent la connexion. Cela est résolu via des backup pins et un mécanisme de mise à jour progressive : la nouvelle application connaît à la fois les certificats anciens et nouveaux, et après une mise à jour complète des utilisateurs, l'ancien pin est supprimé du code. Il est recommandé d'inclure au moins 2 backup pins — un pour le certificat actuel, un pour le futur.

Un autre compromis est l'impossibilité d'utiliser des proxys publics pour le débogage du trafic (Charles Proxy, Burp Suite) sans désactiver le pinning. Cela complique le débogage des requêtes réseau pendant le développement. La solution est la compilation conditionnelle : le pinning est désactivé dans les versions de débogage et activé dans les versions de release. OWASP recommande d'utiliser le flag BuildConfig.DEBUG pour basculer.