Comment désactiver les anciennes versions du protocole TLS dans une configuration HTTPS conforme ?

Pour configurer HTTPS conformément aux exigences, une pratique courante consiste à désactiver TLS 1.0, TLS 1.1 et les versions antérieures du protocole SSL, à conserver TLS 1.2 et à activer TLS 1.3 si le serveur le prend en charge. Toutefois, la conformité dépend également du référentiel de sécurité applicable, des suites de chiffrement, des certificats et du périmètre réellement couvert. Elle ne peut pas être déterminée sur la seule base de la version du protocole.

Avant toute intervention, vérifiez d’abord où se termine la connexion TLS du navigateur. Si le site utilise un CDN, un WAF ou un répartiteur de charge, la modification de la seule configuration du serveur d’origine peut laisser l’ancien protocole accessible depuis le point d’entrée public.

Recenser tous les points d’entrée HTTPS à modifier

Les sites Web destinés au commerce international, les boutiques en ligne transfrontalières et les pages de destination publicitaires suivent souvent le parcours « visiteur—CDN/WAF—répartiteur de charge—serveur d’origine ». Chaque connexion TLS établie indépendamment possède ses propres paramètres de protocole. Si un équipement intermédiaire ne fait que transmettre le trafic, les paramètres sont contrôlés par le composant en aval qui termine effectivement la connexion TLS.

Il est conseillé de recenser les points d’entrée par nom de domaine et par port d’écoute, et non uniquement par serveur :

• Points d’entrée publics : domaine principal, sous-domaine www, sites multilingues, boutique en ligne, API et pages de destination publicitaires.
• Liaisons vers l’origine : connexions HTTPS entre le CDN et le répartiteur de charge, ainsi qu’entre le proxy inverse et le service applicatif.
• Points d’entrée secondaires : adresses du serveur d’origine accessibles directement, domaines de secours, interfaces d’administration et autres ports HTTPS.

Le « niveau TLS minimal » d’un CDN contrôle généralement la connexion des visiteurs ; le protocole utilisé pour la connexion vers l’origine doit être configuré séparément. Si cette connexion utilise toujours HTTP, la réussite d’un test public ne permet pas de conclure que l’ensemble du parcours est chiffré.

Définir explicitement les protocoles autorisés dans la configuration

Plutôt que d’exclure les anciennes versions une par une, il est plus clair de spécifier explicitement les protocoles autorisés. Avant de configurer le service, vérifiez que le serveur Web et la bibliothèque TLS à laquelle il est lié prennent en charge les versions visées. La simple inscription de TLS 1.3 dans un fichier de configuration ne signifie pas que l’environnement actuel peut le fournir.

Exemple de configuration Nginx

Définissez le paramètre dans le contexte de configuration approprié :

ssl_protocols TLSv1.2 TLSv1.3;

Si la même stratégie s’applique à tous les sites, vous pouvez la gérer de façon centralisée au niveau http et vérifier si certaines directives des différents blocs server remplacent cette configuration. Lorsque plusieurs hôtes virtuels HTTPS partagent une même adresse et un même port, vérifiez également l’hôte virtuel par défaut : la négociation du protocole peut être affectée par sa configuration. Il ne suffit donc pas de modifier le bloc de configuration du domaine concerné.

Après l’enregistrement, vérifiez d’abord la syntaxe, puis rechargez le service :

nginx -t
nginx -s reload

Ne rechargez le service qu’après la réussite de la vérification de syntaxe. Dans un environnement conteneurisé, en cluster ou hébergé, appliquez la mise à jour au moyen du mécanisme de déploiement correspondant et vérifiez que toutes les instances utilisent la même configuration, afin d’éviter que certaines requêtes soient encore dirigées vers d’anciens nœuds.

Configuration d’Apache et des plateformes hébergées

Dans Apache, la directive SSLProtocol permet de limiter les protocoles. Par exemple, dans un environnement prenant en charge les versions correspondantes :

SSLProtocol -all +TLSv1.2 +TLSv1.3

Vérifiez également les paramètres globaux, ceux des hôtes virtuels et leurs relations d’héritage. Si vous utilisez un CDN, un répartiteur de charge cloud ou une plateforme SaaS de création de sites Web, définissez la version minimale dans la console qui gère effectivement TLS, puis vérifiez séparément les connexions des visiteurs et celles vers l’origine.

Dans le cas d’une plateforme intégrée de création de sites Web et de services marketing telle qu’易营宝, les pages du site, les domaines marketing, le CDN et le serveur d’origine peuvent être gérés par différentes équipes. Avant la mise en œuvre, définissez qui est responsable de la configuration de chaque point d’entrée et comment elle sera vérifiée. Le fait que la plateforme ait déployé un certificat ne signifie pas que l’ancien protocole est désactivé sur tous les points d’entrée.

La validation doit prouver à la fois le rejet des anciennes versions et le bon fonctionnement des versions récentes

Le fait qu’un navigateur puisse ouvrir le site indique seulement qu’une négociation de protocole a abouti ; cela ne prouve pas que les anciennes versions sont désactivées. Pour un même domaine, lancez séparément une négociation en spécifiant chaque version :

openssl s_client -connect example.com:443 -servername example.com -tls1
openssl s_client -connect example.com:443 -servername example.com -tls1_1
openssl s_client -connect example.com:443 -servername example.com -tls1_2
openssl s_client -connect example.com:443 -servername example.com -tls1_3

Remplacez le domaine d’exemple par le domaine réel. Le résultat attendu est que les négociations TLS 1.0 et TLS 1.1 échouent et que TLS 1.2 fonctionne. Si TLS 1.3 doit être proposé, vérifiez également qu’il fonctionne. L’option -servername transmet le SNI et évite que la requête soit dirigée vers un hôte virtuel incorrect.

Une erreur lors du test d’un ancien protocole ne signifie pas nécessairement que le serveur l’a refusé. L’installation locale d’OpenSSL peut déjà interdire les anciens protocoles ou ne pas disposer d’une suite de chiffrement ancienne utilisable. Si le client échoue avant même d’envoyer la négociation, ce résultat ne prouve pas que le serveur a désactivé le protocole. Examinez les messages d’erreur et recoupez les résultats à l’aide d’un outil d’analyse TLS capable d’effectuer les vérifications correspondantes.

Vérifiez séparément le domaine public et le serveur d’origine. Pour vous connecter directement au serveur d’origine, remplacez l’adresse dans -connect par l’adresse IP du serveur, tout en indiquant le domaine dans -servername. Couvrez également IPv4, IPv6, les points d’entrée de secours et les différents nœuds de déploiement. Conservez la date du test, l’adresse cible et le résultat de la négociation pour faciliter la réception et les recherches ultérieures.

Vérifier la compatibilité sur l’ensemble du parcours métier

Les anciens systèmes d’exploitation, les appareils embarqués ou les clients d’API qui n’ont pas été mis à jour depuis longtemps risquent de ne plus pouvoir se connecter après la modification. Avant le déploiement, identifiez les dépendances à partir des journaux de connexion, de la liste des appelants et des tests métier. Vérifiez en particulier l’envoi des demandes de devis, les redirections de paiement, les rappels de commande, les API de données marketing et les tâches de synchronisation tierces.

En cas de problème de compatibilité, privilégiez la mise à niveau du client, de l’environnement d’exécution ou du composant d’interface. Si une période de transition est réellement nécessaire, envisagez un point d’entrée dédié et isolé, en limitant son périmètre d’accès et en fixant une date de retrait. Ne réactivez pas les anciens protocoles sur l’ensemble du site principal pour un seul appelant obsolète. Pendant le déploiement progressif, surveillez les erreurs de négociation, les échecs de rappel et les résultats des formulaires clés : le fait que la page s’ouvre ne garantit pas le bon fonctionnement des transactions ou du parcours d’acquisition de clients.

La désactivation des anciennes versions de TLS ne couvre pas à elle seule l’ensemble des mesures HTTPS. Sous TLS 1.2, les suites de chiffrement doivent encore être examinées ; la chaîne de certificats, la correspondance des noms de domaine, la gestion des dates d’expiration et le contenu mixte doivent également être traités séparément. La redirection HTTP et HSTS ont chacune leur rôle et ne remplacent pas la restriction des protocoles. À la livraison, consignez la liste des points d’entrée, les configurations effectivement appliquées et les résultats de validation. Vérifiez ensuite tout nouveau domaine marketing ou toute migration de CDN selon le même référentiel.