SSL/TLS — définition, protocoles et principe de fonctionnement du chiffrement

Qu'est-ce que SSL/TLS ?

SSL (Secure Sockets Layer) est un protocole développé par Netscape en 1995 pour sécuriser le trafic web. La première version, SSL 1.0, n'a jamais été publiée ; SSL 2.0 (1995) et SSL 3.0 (1996) ont été utilisés jusqu'au début des années 2000, mais contenaient des vulnérabilités critiques. SSL a été remplacé par TLS (Transport Layer Security) — une version améliorée standardisée par l'IETF. TLS 1.0 (1999) était basé sur SSL 3.0, tandis que les versions suivantes TLS 1.1 (2006), TLS 1.2 (2008) et TLS 1.3 (2018) se sont progressivement éloignées de l'architecture d'origine, ajoutant de nouveaux algorithmes de chiffrement et corrigeant des vulnérabilités. Aujourd'hui, SSL est considéré comme obsolète et tous les systèmes modernes utilisent TLS, bien que les deux protocoles soient souvent mentionnés ensemble comme SSL/TLS par inertie.

Histoire du protocole

L'histoire de SSL/TLS a commencé avec le besoin de transmission sécurisée des données sur le web naissant. En 1994, Netscape a développé SSL 1.0 pour son navigateur Navigator, mais le protocole n'a jamais été publié en raison de graves problèmes de sécurité. SSL 2.0 est sorti en 1995 et a été utilisé en pratique, mais contenait de nombreuses vulnérabilités : absence de protection contre les attaques Man-in-the-Middle, algorithmes de chiffrement faibles et sensibilité aux attaques par troncature. SSL 3.0 (1996) a corrigé la plupart des problèmes, mais en 2014, la vulnérabilité POODLE a été découverte, après quoi l'IETF a officiellement déclaré toutes les versions de SSL obsolètes. TLS 1.0–1.3 ont progressivement amélioré la robustesse cryptographique, les performances et la confidentialité, TLS 1.3 réduisant le handshake de deux allers-retours à un seul — un point critique pour les applications mobiles avec des connexions instables.

Comment fonctionne le handshake SSL/TLS

Handshake est le processus d'établissement d'une connexion sécurisée entre un client et un serveur. Il se compose de plusieurs étapes séquentielles au cours desquelles les parties s'accordent sur la version du protocole, sélectionnent les algorithmes de chiffrement, échangent les clés et s'authentifient mutuellement. Dans TLS 1.3, le handshake ne nécessite qu'un seul aller-retour réseau (1-RTT), alors que TLS 1.2 en nécessitait deux (2-RTT).

La première étape est l'envoi par le client d'un ClientHello — un message contenant une liste des versions TLS prises en charge, des suites de chiffrement et un nombre aléatoire. Le serveur répond par un ServerHello contenant la version et le chiffrement choisis, son certificat X.509 et une signature numérique. Le client vérifie le certificat via la chaîne d'autorités de certification (CA), génère une clé de session et l'envoie chiffrée avec la clé publique du serveur extraite du certificat. Après confirmation du serveur, la transmission sécurisée des données commence. L'ensemble du handshake prend 1 à 3 millisecondes sur les appareils modernes, le rendant imperceptible pour l'utilisateur.

Certificats X.509 et chaîne de confiance

La base de l'authentification TLS est l'infrastructure à clé publique (PKI) construite sur des certificats au format X.509. Chaque certificat contient : un nom de domaine (Common Name ou Subject Alternative Name), la clé publique du serveur, le nom de l'émetteur (Autorité de Certification), une date d'expiration et la signature numérique de la CA. Le client vérifie le certificat du serveur le long de la chaîne de confiance : du certificat du serveur jusqu'à la CA racine, dont le certificat est intégré dans le système d'exploitation. Sur les appareils Android, les certificats racine sont stockés dans le magasin de clés système, mis à jour via Google Play Services ; sur iOS — via les mises à jour iOS. Si un maillon de la chaîne est rompu (certificat expiré, non-concordance de domaine, CA inconnue), le client interrompt la connexion. Pour les certificats auto-signés (utilisés en développement), une confiance explicite est requise — sur Android via Network Security Config, sur iOS via NSExceptionDomains dans Info.plist. Le processus de validation de la chaîne de certificats inclut également la vérification du statut de révocation via CRL (Liste de Révocation de Certificats) ou OCSP (Protocole de Statut de Certificat en Ligne), bien que sur les appareils mobiles les requêtes OCSP soient souvent ignorées pour accélérer la connexion — c'est un compromis entre sécurité et performance que les architectes doivent prendre en compte.

val client = OkHttpClient.Builder()
    .connectionSpecs(
        listOf(
            ConnectionSpec.Builder(ConnectionSpec.MODERN_TLS)
                .tlsVersions(TlsVersion.TLS_1_3, TlsVersion.TLS_1_2)
                .cipherSuites(
                    CipherSuite.TLS_AES_128_GCM_SHA256,
                    CipherSuite.TLS_AES_256_GCM_SHA384,
                    CipherSuite.TLS_CHACHA20_POLY1305_SHA256
                )
                .build()
        )
    )
    .hostnameVerifier { hostname, session ->
        SSLSession.DefaultHostnameVerifier.verify(hostname, session)
    }
    .build()