SSL/TLS : concepts clés et protocoles dans le développement

Qu'est-ce que SSL/TLS ?

SSL (Secure Sockets Layer) et TLS (Transport Layer Security) sont des protocoles cryptographiques qui assurent une transmission sécurisée des données sur le réseau. SSL, développé par Netscape dans les années 1990, est considéré comme obsolète après la version 3.0 en raison des vulnérabilités POODLE et BEAST. TLS, son successeur, a connu les versions 1.0, 1.1, 1.2 et 1.3 — seules TLS 1.2 et TLS 1.3 sont considérées comme actuelles. Toutes les plateformes mobiles modernes exigent TLS pour les connexions réseau, et l'App Store ainsi que Google Play le vérifient lors de la révision.

Pourquoi TLS pour les applications mobiles

Sans TLS, le trafic entre l'application et le serveur est transmis en texte clair — n'importe qui sur le même réseau Wi-Fi peut intercepter les identifiants, mots de passe, jetons et données personnelles des utilisateurs à l'aide de Wireshark ou tcpdump. TLS chiffre toutes les données transmises (chiffrement au niveau transport) et vérifie l'authenticité du serveur via une chaîne de certificats X.509. Selon IETF (2018), TLS 1.3 utilise uniquement des chiffrements AEAD modernes (AES-GCM, ChaCha20-Poly1305), excluant les algorithmes obsolètes comme RC4 et 3DES.

HTTPS et TLS

HTTPS (HTTP Secure) est HTTP sur TLS. Lorsqu'une application mobile effectue une requête via https://, elle établit d'abord une connexion TLS avec le serveur, puis transmet les en-têtes HTTP et le corps de la requête via le canal chiffré. Sans HTTPS, aucune API sérieuse ne devrait fonctionner — c'est l'hygiène de sécurité de base. Selon OWASP (2026), les connexions non sécurisées figurent parmi les 3 principales vulnérabilités des applications mobiles.

Comment fonctionne le TLS Handshake

TLS Handshake est le processus d'établissement d'une connexion sécurisée entre un client et un serveur. Les parties négocient la version du protocole, sélectionnent une suite de chiffrement (cipher suite), échangent des clés via cryptographie asymétrique et vérifient les certificats. Dans TLS 1.2, la poignée de main nécessite 2 Round Trip Time (2 RTT) : client → serveur avec ClientHello, serveur → client avec ServerHello et Certificate, puis les messages Finished finaux. TLS 1.3 réduit ce processus à 1 RTT.

Étapes détaillées du handshake TLS 1.2

Première étape : ClientHello — le client envoie les versions TLS prises en charge, une liste de suites de chiffrement et un nombre aléatoire. Le serveur répond avec ServerHello, sélectionnant une version et une suite de chiffrement, envoie son certificat X.509 (Certificate) et le message ServerHelloDone. Le client vérifie le certificat via une chaîne d'autorités de certification (CA) de confiance, génère un secret pré-maître, le chiffre avec la clé publique du certificat et l'envoie au serveur dans ClientKeyExchange. Après cela, les deux parties génèrent des clés de session et échangent les messages ChangeCipherSpec et Finished. À partir de ce moment, toutes les données sont chiffrées de manière symétrique.

import Security

let url = URL(string: "https://api.example.com")!
let session = URLSession(configuration: .default,
                           delegate: self,
                           delegateQueue: nil)

func urlSession(
    _ session: URLSession,
    didReceive challenge: URLAuthenticationChallenge,
    completionHandler: @escaping (URLSession.AuthChallengeDisposition,
                                    URLCredential?) -> Void
) {
    let trust = challenge.protectionSpace.serverTrust
    guard let trust else {
        completionHandler(.cancelAuthenticationChallenge, nil)
        return
    }
    completionHandler(.useCredential, URLCredential(trust: trust))
}

Exemple de traitement de URLAuthenticationChallenge sur iOS via URLSessionDelegate. Cette méthode est appelée lors de chaque TLS Handshake, permettant à l'application d'effectuer une vérification personnalisée du certificat du serveur. Pour une utilisation en production, ajoutez la vérification du certificat via SecTrustEvaluateWithError et comparez avec une empreinte préenregistrée — seulement ensuite appelez useCredential.

TLS 1.2 vs TLS 1.3

TLS 1.3 (RFC 8446, 2018) est la première mise à jour majeure du protocole en 10 ans. Principales améliorations : handshake réduit à 1 RTT (0 RTT pour les connexions répétées), suppression des suites de chiffrement obsolètes (échange de clés RSA, mode CBC), Perfect Forward Secrecy (PFS) obligatoire et protection contre les attaques de downgrade via signed transcript. Selon Qualys SSL Labs (2026), TLS 1.3 offre une protection même en cas de compromission de la clé serveur à long terme grâce au PFS.

0-RTT (Zero Round Trip Time) est une fonctionnalité de TLS 1.3 qui permet au client d'envoyer des données immédiatement avec ClientHello lors d'une connexion répétée via PSK (Pre-Shared Key). Cela accélère le chargement des écrans suivants dans les applications mobiles, en particulier avec des requêtes fréquentes au même serveur. Cependant, les données 0-RTT ne sont pas protégées contre les attaques par rejeu — elles peuvent être interceptées et renvoyées. Utilisez 0-RTT uniquement pour les requêtes idempotentes (GET, PUT) sans effets secondaires.

TLS sur iOS : App Transport Security

App Transport Security (ATS) est le mécanisme d'Apple exigeant des connexions HTTPS avec TLS 1.2 ou supérieur, activé par défaut depuis iOS 9. ATS bloque toutes les connexions HTTP et HTTPS avec TLS inférieur à 1.2. Le développeur peut configurer des exceptions dans Info.plist via NSAppTransportSecurity pour des domaines spécifiques, mais Apple recommande de minimiser les exceptions et d'utiliser HTTPS partout. La violation des exigences ATS est un motif de rejet de l'application lors de la révision de l'App Store.

<!-- Info.plist — App Transport Security -->
<key>NSAppTransportSecurity</key>
<dict>
    <key>NSAllowsArbitraryLoads</key>
    <false/>
    <key>NSExceptionDomains</key>
    <dict>
        <key>cdn.example.com</key>
        <dict>
            <key>NSExceptionAllowsInsecureHTTPLoads</key>
            <false/>
            <key>NSExceptionMinimumTLSVersion</key>
            <string>TLSv1.2</string>
        </dict>
    </dict>
    <key>NSAllowsLocalNetworking</key>
    <true/>
</dict>

Configuration ATS dans Info.plist. NSAllowsArbitraryLoads est défini sur false — toutes les connexions doivent utiliser HTTPS. Pour le domaine cdn.example.com, une version minimale TLS 1.2 est spécifiée, NSAllowsLocalNetworking=true autorise HTTP pour le réseau local (utile pour les serveurs de développement). Apple recommande fortement de ne pas activer NSAllowsArbitraryLoads sans NSExceptionDomains — cela devrait être une exception, pas une règle générale.

TLS sur Android : Network Security Config

Network Security Config est le mécanisme d'Android pour configurer HTTPS et TLS sans modifier le code Java/Kotlin. La configuration est spécifiée dans le fichier network_security_config.xml et connectée dans AndroidManifest via l'attribut android:networkSecurityConfig. Prend en charge la configuration des certificats de confiance (CA utilisateur et système), le Certificate Pinning, la désactivation du HTTP en texte clair, les overrides de débogage et la redirection de trafic.

<!-- res/xml/network_security_config.xml -->
<network-security-config>
    <base-config cleartextTrafficPermitted="false">
        <trust-anchors>
            <certificates src="system" />
        </trust-anchors>
    </base-config>
    <domain-config cleartextTrafficPermitted="false">
        <domain includeSubdomains="true">api.example.com</domain>
        <pin-set expiration="2027-01-01">
            <pin digest="SHA-256">
                47DEQpj8HBSa+/TImW+5JCeuQeRkm5NMpJWZG3hSuFU=
            </pin>
        </pin-set>
    </domain-config>
</network-security-config>

Network Security Config pour Android. Base-config bloque le trafic en texte clair et ne fait confiance qu'aux certificats CA système (pas de certificats utilisateur — protection contre l'installation de certificats MitM par les utilisateurs). Domain-config pour api.example.com contient un pin-set avec une empreinte SHA-256 du certificat. Si le certificat du serveur change avant la date d'expiration spécifiée, la connexion sera rejetée — c'est une forme stricte de Certificate Pinning.

Certificate Pinning et sécurité

Certificate Pinning est une technique de fixation du certificat ou de la clé publique du serveur dans le code de l'application. Lors de chaque TLS Handshake, le client compare le certificat du serveur avec une empreinte préenregistrée (hash SHA-256). Même si un attaquant obtient un certificat CA de confiance ou compromet l'autorité de certification, il ne peut pas effectuer d'attaque MitM — l'application vérifie l'empreinte spécifique, pas la chaîne CA. Ceci est particulièrement important pour les applications financières et celles traitant des données sensibles.

Risques et alternatives au Pinning

Certificate Pinning nécessite de la prudence : lorsque le certificat du serveur change, toutes les anciennes versions de l'application cesseront de se connecter. Il est recommandé de stocker plusieurs empreintes de secours (principale + secours), de spécifier une date d'expiration du pin-set et d'implémenter un mécanisme de repli via la vérification CA standard. Une alternative est le Trust On First Use (TOFU), où l'application mémorise le certificat lors de la première connexion et avertit l'utilisateur en cas de changement. Selon OWASP (2026), l'absence de Certificate Pinning figure parmi les 3 principales vulnérabilités des applications mobiles (M3 : Communication non sécurisée).

Implémentation du Pinning dans Alamofire

Dans Alamofire 5+, le Certificate Pinning se configure via ServerTrustManager avec PinnedCertificatesTrustEvaluator (vérification du certificat complet) ou PublicKeysTrustEvaluator (clé publique uniquement). La clé publique est préférable — elle ne change pas lors du renouvellement du certificat auprès du même CA. Créez un ServerTrustManager avec un dictionnaire [host: evaluator], passez-le à Session et utilisez-le pour toutes les requêtes vers des API sécurisées.