Migrer TLS legacy sans casser les clients anciens

Une migration TLS (Transport Layer Security) réussie ne consiste pas à désactiver TLS 1.0 dans une console et à attendre les tickets. Le compromis central est brutal : réduire la surface d’attaque impose de retirer des protocoles et suites faibles, mais maintenir certains clients anciens prolonge précisément cette surface. La recommandation est de séparer les compatibilités héritées, jamais de les conserver sur le point d’entrée principal.

→ Lire l’explication complète de la marmotte

Inventaire TLS et décision de compatibilité

Avant toute modification, inventorier les terminaisons TLS : répartiteurs de charge, proxies inverses, passerelles d’API (Application Programming Interface), serveurs web, serveurs SMTP (Simple Mail Transfer Protocol), appliances et services embarqués. L’inventaire doit associer chaque point d’écoute à son nom DNS (Domain Name System), son certificat, ses versions TLS acceptées, ses suites cryptographiques négociées et ses clients observés.

Les configurations déclarées ne suffisent pas. Un proxy peut annoncer TLS 1.2 tout en laissant un serveur amont négocier TLS 1.0. Une appliance peut présenter un certificat RSA (Rivest, Shamir, Adleman) de 2048 bits tandis que son interface d’administration expose encore RC4 (Rivest Cipher 4). La sécurité d’une chaîne vaut la négociation la plus faible accessible, pas le PDF d’architecture avec des flèches bleues.

Collecter les négociations réelles pendant une période couvrant les cycles métier : version du protocole, suite, indication de nom de serveur SNI (Server Name Indication), protocole applicatif ALPN (Application-Layer Protocol Negotiation), adresse source et nom de service. Les journaux de terminaison TLS sont préférables aux captures réseau : une capture ne dit pas toujours quelle politique a finalement été appliquée derrière plusieurs couches de proxy.

Classer ensuite les clients en trois groupes :

Modernisables : navigateurs et bibliothèques maintenues. Leur compatibilité legacy doit disparaître immédiatement.
Tolérables à court terme : systèmes industriels, équipements mobiles ou progiciels dont la mise à niveau est planifiée et vérifiable.
Non maîtrisés : clients publics inconnus. Ils ne justifient pas le maintien éternel de TLS 1.0 ou de suites RSA avec échange de clé statique.

Un client ancien identifié n’est pas une justification de sécurité, c’est une dette avec un propriétaire, une date de sortie et une preuve de remplacement. Vingt ans de métier rappellent que le client sans propriétaire devient volontiers immortel, surtout lorsqu’il vit dans un tableur baptisé final_v8.xlsx.

La cible générale est TLS 1.3 et TLS 1.2 uniquement. TLS 1.0 et TLS 1.1 doivent être retirés. SSL (Secure Sockets Layer) 2.0 et 3.0 relèvent de l’archéologie, pas de l’exploitation. Pour comprendre les étapes de négociation et leurs conséquences, consulter le fonctionnement de TLS.

Cible cryptographique : TLS 1.3, TLS 1.2 restreint

TLS 1.3 impose des suites avec confidentialité persistante : la compromission ultérieure de la clé privée du serveur ne permet pas de déchiffrer les sessions passées capturées sur le réseau. TLS 1.2 peut fournir la même propriété si, et seulement si, l’échange de clés utilise ECDHE (Elliptic Curve Diffie-Hellman Ephemeral), donc une clé éphémère par négociation.

Conserver en TLS 1.2 uniquement :

ECDHE-RSA-AES128-GCM-SHA256 et ECDHE-RSA-AES256-GCM-SHA384 lorsque le certificat est RSA ;
ECDHE-ECDSA-AES128-GCM-SHA256 et ECDHE-ECDSA-AES256-GCM-SHA384 avec un certificat ECDSA (Elliptic Curve Digital Signature Algorithm) ;
ECDHE-*-CHACHA20-POLY1305 pour les clients sans accélération AES (Advanced Encryption Standard).

AES-GCM (Galois/Counter Mode) et ChaCha20-Poly1305 fournissent chiffrement et intégrité authentifiée. CBC (Cipher Block Chaining) reste à exclure : les contremesures aux attaques Lucky13 et BEAST ont produit une longue collection de configurations ambiguës. Maintenir CBC pour un seul client revient à garder une porte coupe-feu ouverte avec une cale estampillée « exception temporaire ».

Interdire explicitement les échanges de clé RSA statiques, DH (Diffie-Hellman) avec paramètres faibles, DSA (Digital Signature Algorithm), RC4, 3DES (Triple Data Encryption Standard), NULL, EXPORT et MD5 (Message Digest 5). SHA-1 (Secure Hash Algorithm 1) ne doit plus signer de certificats ni intervenir dans une suite négociable. L’ordre des suites côté serveur compte en TLS 1.2 : préférer AES-GCM ou ChaCha20-Poly1305, jamais laisser un client choisir librement le plus vieux meuble du grenier.

Le certificat doit contenir une clé RSA d’au moins 2048 bits ou une clé ECDSA P-256 au minimum. Le choix dépend des clients : RSA reste le certificat de compatibilité, ECDSA réduit la charge et les tailles de handshake, mais certains anciens clients ne le valident pas. La coexistence de deux certificats sur le même nom est acceptable si la terminaison choisit selon les algorithmes de signature annoncés.

La PKI (Public Key Infrastructure) reste un maillon distinct. Un certificat techniquement moderne signé par une autorité mal contrôlée ne protège rien contre une émission frauduleuse. La séparation des rôles, la protection des clés et les chaînes de confiance sont détaillées dans l’explication de la PKI.

Isolation des clients legacy par point d’entrée

La bonne architecture ne négocie pas des suites faibles sur le même nom et la même adresse que le trafic moderne. Créer un nom DNS dédié, par exemple legacy.example.net, et une terminaison dédiée. Cette séparation fournit des journaux distincts, une politique réseau spécifique, un certificat séparé et, surtout, une date de suppression contrôlable.

Un sous-domaine seul ne suffit pas si le même proxy, la même politique et le même certificat servent les deux chemins. La séparation doit exister dans la configuration effective : écoute distincte, politique TLS distincte, routage explicite et métriques par point d’entrée. Lorsque les contraintes le permettent, isoler également par adresse IP et filtrage réseau.

TLS 1.2 avec ECDHE peut être la limite de compatibilité temporaire acceptable. TLS 1.0 ou TLS 1.1 ne doivent survivre que derrière un contrôle compensatoire documenté : réseau privé, liste d’adresses source strictement limitée, authentification applicative forte et échéance courte. Un service exposé à Internet avec TLS 1.0 n’est pas « compatible », il est exposé avec une étiquette de compatibilité.

Cette isolation ne protège pas contre un client compromis, une authentification faible ou une autorisation applicative erronée. TLS chiffre le transport et authentifie généralement le serveur. Il ne remplace ni une gestion des identités, ni la validation des entrées, ni une segmentation réseau. Pour les échanges machine à machine, le certificat client et la vérification mutuelle sont traités dans la page sur mTLS.

Exemple de politique Nginx avec frontal legacy séparé

L’exemple suivant utilise Nginx avec OpenSSL (Open Secure Sockets Layer) récent. Les suites TLS 1.3 sont définies par la bibliothèque cryptographique et non par ssl_ciphers sur les versions courantes de Nginx.

# Point d'entrée moderne : aucun protocole antérieur à TLS 1.2.
server {
    listen 443 ssl http2;
    server_name api.example.net;

    ssl_protocols TLSv1.2 TLSv1.3;

    # TLS 1.2 uniquement : ECDHE, chiffrement authentifié, aucun CBC ni RSA statique.
    ssl_ciphers 'ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305';
    ssl_prefer_server_ciphers on;

    ssl_certificate     /etc/nginx/tls/api-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/api-key.pem;

    location / {
        proxy_pass http://application_modern;
    }
}

# Compatibilité temporaire : nom distinct et accès limité au niveau réseau.
server {
    listen 443 ssl;
    server_name legacy.example.net;

    ssl_protocols TLSv1.2;
    ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384';

    ssl_certificate     /etc/nginx/tls/legacy-fullchain.pem;
    ssl_certificate_key /etc/nginx/tls/legacy-key.pem;

    location / {
        proxy_pass http://application_legacy;
    }
}

Tester la politique depuis un poste d’administration, puis depuis les segments représentant les clients legacy. openssl s_client -connect api.example.net:443 -tls1 doit échouer. openssl s_client -connect api.example.net:443 -tls1_2 -cipher ECDHE-RSA-AES128-GCM-SHA256 doit réussir si le certificat RSA est proposé. Un résultat positif ne valide pas les chaînes intermédiaires, le nom d’hôte ou le comportement des navigateurs : ces contrôles doivent être ajoutés.

Surface d’attaque, exploitation et retrait définitif

La migration crée une période dangereuse : deux politiques coexistent et l’attaquant cherchera la plus faible. Les attaques connues incluent le downgrade de protocole, les suites sans confidentialité persistante, les certificats expirés, les chaînes incomplètes et l’absence de validation du nom d’hôte côté client. TLS_FALLBACK_SCSV (Transport Layer Security Fallback Signaling Cipher Suite Value) réduit les downgrades liés aux mécanismes de repli des clients, mais ne sauve pas une politique qui accepte volontairement TLS 1.0.

Surveiller les métriques suivantes par nom de service : versions négociées, suites négociées, erreurs de handshake, alertes TLS, expirations à 30, 14 et 7 jours, et échecs de validation de certificat. Une hausse d’échecs juste après retrait de TLS 1.0 peut révéler un client oublié ; elle peut aussi révéler un scan hostile dont la nostalgie cryptographique mérite peu d’égards. La distinction vient des adresses sources, des chemins applicatifs et des identités authentifiées.

Les clés privées doivent résider dans un HSM (Hardware Security Module) ou un gestionnaire de clés fournissant contrôle d’accès, journalisation et rotation. Exporter une clé privée dans une image de conteneur annule avec enthousiasme les efforts de durcissement précédents. Prévoir la rotation du certificat et de sa clé, conserver les chaînes intermédiaires, tester le renouvellement automatisé et sauvegarder les configurations de terminaison hors des sauvegardes contenant les clés.

La révocation via OCSP (Online Certificate Status Protocol) ou CRL (Certificate Revocation List) ne ferme pas les sessions déjà établies. Il faut donc limiter la durée des sessions, invalider les jetons applicatifs quand nécessaire et disposer d’une procédure de retrait du certificat compromis. Une sauvegarde de clé privée n’est pas toujours souhaitable : pour une clé non exportable dans un HSM, la reprise repose sur une nouvelle paire de clés, un nouveau certificat et une procédure de bascule testée.

Le retrait final suit des seuils mesurables : absence de négociation legacy sur une période définie, confirmation des propriétaires applicatifs, retrait DNS, suppression des certificats dédiés et suppression des règles réseau. Désactiver seulement la route applicative tout en conservant le listener legacy laisse une cible sans usage. C’est le genre de dette qui survit très bien aux comités de nettoyage.

🐝 Ce qui arrive si on s’en passe

Sans cette migration, une terminaison qui accepte encore l’échange de clé RSA statique répond différemment selon la validité du bourrage PKCS#1 v1.5 reçu. Elle devient un oracle interrogeable à distance, comme le décrit la brèche « la question qui rend le module bavard ». Un attaquant peut alors déchiffrer une session TLS enregistrée, ou produire une signature avec la clé du serveur, sans jamais l’extraire. Le risque dépasse le point d’entrée faible : si la même paire de clés RSA sert aussi un listener moderne, l’oracle exposé côté legacy suffit à usurper le service moderne, même configuré en TLS 1.3. D’où l’intérêt d’une clé et d’un certificat propres au frontal legacy : sans cette séparation, la faiblesse d’un seul listener s’étend à tous les services qui partagent la clé.

🦫 Explication de la marmotte 🍫

Une connexion protégée commence par une discussion entre un appareil et un serveur. Ils choisissent une version du protocole de protection, une méthode de chiffrement et vérifient l’identité du serveur grâce à un certificat. Les anciennes versions et certaines anciennes méthodes contiennent des faiblesses connues : un attaquant peut parfois forcer un retour vers une option moins protégée, ou déchiffrer plus tard des échanges qu’il a enregistrés.

La migration consiste d’abord à mesurer ce qui est réellement utilisé. Il faut identifier les appareils qui demandent encore les options anciennes, car une liste de matériels théorique manque souvent des programmes oubliés. Le service principal accepte ensuite seulement les versions récentes et les méthodes qui chiffrent les échanges avec des clés temporaires.

Quand un ancien appareil ne peut pas encore être mis à jour, il reçoit une adresse de service séparée. Cette adresse accepte une politique moins stricte, mais reste limitée par le réseau et surveillée. Si elle partageait les mêmes règles que le service principal, n’importe quel attaquant pourrait demander l’option faible.

Les certificats et leurs clés doivent être renouvelés avant expiration. Une clé volée impose de remplacer le certificat et de couper les accès concernés, car arrêter un certificat ne coupe pas instantanément les échanges déjà ouverts. La migration se termine seulement quand les anciens appareils ont disparu des journaux et que l’adresse temporaire est supprimée.

Pages voisines

La citent

Migrer TLS legacy sans casser les clients anciens

Elle cite

Migrer TLS legacy sans casser les clients anciens

Migrer TLS legacy sans casser les clients anciens

Inventaire TLS et décision de compatibilité

Cible cryptographique : TLS 1.3, TLS 1.2 restreint

Isolation des clients legacy par point d’entrée

Exemple de politique Nginx avec frontal legacy séparé

Surface d’attaque, exploitation et retrait définitif

🐝 Ce qui arrive si on s’en passe

🦫 Explication de la marmotte 🍫

À lire aussi

Pages voisines