Résolution du problème lié à TLS 1.0, 2e édition

  • Article

Ce document présente les dernières directives pour identifier et supprimer rapidement les dépendances à la version 1.0 du protocole TLS (Transport Layer Security) dans les logiciels reposant sur les systèmes d'exploitation Microsoft. Il fournit également des détails sur les changements et les nouvelles fonctionnalités introduites par Microsoft dans ses produits pour protéger vos clients et services en ligne. Son but est de servir de point de départ à l'élaboration d'un plan de migration vers un environnement réseau TLS 1.2+. Bien qu'il soit envisageable d'appliquer les solutions abordées ici pour supprimer l'utilisation de TLS 1.0 dans des systèmes d'exploitation ou bibliothèques de chiffrement non-Microsoft, ce sujet dépasse le cadre de ce document.

TLS 1.0 est un protocole de sécurité qui a été défini pour la première fois en 1999 pour établir des canaux de chiffrement sur les réseaux informatiques. Microsoft prend en charge ce protocole depuis Windows XP/Server 2003. Même s'il n'est plus le protocole de sécurité par défaut des systèmes d'exploitation modernes, TLS 1.0 est toujours pris en charge à des fins de compatibilité descendante. Face à l'évolution de la réglementation et à l'apparition de nouvelles vulnérabilités de sécurité dans TLS 1.0, les entreprises sont appelées à désactiver complètement TLS 1.0.

Pour devancer les problèmes à venir, Microsoft recommande donc à ses clients de supprimer les dépendances à TLS 1.0 dans leur environnement et de désactiver TLS 1.0 au niveau du système d'exploitation dans la mesure du possible. Compte tenu de la longévité du protocole TLS 1.0 dans le secteur du logiciel, nous vous recommandons vivement d'inclure ce qui suit dans votre plan de dépréciation de TLS 1.0 :

  • Analyse du code pour trouver/corriger les instances codées en dur de TLS 1.0 ou de protocoles de sécurité plus anciens.

  • Analyse des points de terminaison réseau et du trafic pour identifier les systèmes d'exploitation utilisant TLS 1.0 ou des protocoles plus anciens.

  • Tests de régression complets sur l'ensemble de votre pile d'applications une fois TLS 1.0 désactivé.

  • Migration des systèmes d'exploitation et des bibliothèques/frameworks de développement hérités vers des versions capables de négocier TLS 1.2 par défaut.

  • Tests de compatibilité sur tous les systèmes d'exploitation de votre entreprise pour identifier les problèmes de prise en charge de TLS 1.2.

  • Mise en place d'une coordination avec vos partenaires commerciaux et vos clients pour les informer de votre décision de déprécier TLS 1.0.

  • Identification des clients qui ne pourront peut-être plus se connecter à vos serveurs une fois TLS 1.0 désactivé.

Le but de ce document est de vous fournir des recommandations pour éliminer les obstacles techniques à la désactivation de TLS 1.0 tout en vous offrant une visibilité accrue de l'impact de ce changement sur vos clients. En accomplissant les tâches décrites dans ce document, vous pourrez réduire l'impact métier de la prochaine vulnérabilité de sécurité dans TLS 1.0. Dans ce document, les références à la dépréciation de TLS 1.0 incluent également TLS 1.1.

Les développeurs de logiciels d'entreprise ont un besoin stratégique d'adopter des solutions plus évolutives et agiles (ou « agilité de chiffrement ») pour faire face aux futures violations des protocoles de sécurité. Bien que ce document propose des solutions agiles pour éliminer le code en dur de TLS, les solutions prenant plus largement en charge l'agilité de chiffrement n'entrent pas dans le cadre de ce document.

État actuel de l'implémentation de TLS 1.0 par Microsoft

L'implémentation de TLS 1.0 par Microsoft est exempte de failles de sécurité connues. En raison du risque potentiel d'attaques futures visant une version antérieure du protocole et d'autres vulnérabilités propres à TLS 1.0 non spécifiques à l'implémentation de Microsoft, il est recommandé dans la mesure du possible de supprimer les dépendances à tous les protocoles de sécurité antérieurs à TLS 1.2 (TLS 1.1/1.0/SSLv3/SSLv2).

Au cours de la planification de cette migration vers TLS 1.2+, les développeurs et administrateurs système doivent être conscients du potentiel code en dur des versions de protocole dans les applications développées par leurs employés et partenaires. Le code en dur signifie ici que la version du protocole TLS est définie de manière fixe, ce qui la rend obsolète et moins sécurisée que les versions plus récentes. L'utilisation d'une version de TLS plus récente que celle codée en dur nécessite la modification du programme en question. La résolution de ce type de problème passe impérativement par la modification du code source et le déploiement d'une mise à jour de logiciel. Avant, coder en dur les versions de protocole était courant à des fins de test et de prise en charge dans la mesure où de nombreux navigateurs et systèmes d'exploitation offraient différents niveaux de prise en charge de TLS.

Versions prises en charge de TLS dans Windows

De nombreux systèmes d'exploitation utilisent des versions de TLS par défaut obsolètes ou des plafonds de prise en charge dont il faut tenir compte.

Figure 1 : Prise en charge du protocole de sécurité par version du système d'exploitation

Système d'exploitation Windows SSLv2 SSLv3 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3
Windows Vista Activé(e) activé Activé(e) Non pris en charge Non pris en charge Non pris en charge
Windows Server 2008 Activé(e) activé Activé(e) Désactivé* Désactivé* Non pris en charge
Windows 7 (WS2008 R2) Activé(e) activé Activé(e) Désactivé* Désactivé* Non pris en charge
Windows 8 (WS2012) Désactivé activé activé activé Activé(e) Non pris en charge
Windows 8.1 (WS2012 R2) Désactivé activé activé activé Activé(e) Non pris en charge
Windows 10 Désactivé activé activé activé Activé(e) Non pris en charge
Windows 11 Désactivé activé activé activé activé Activé(e)
Windows Server 2016 Non pris en charge Désactivé activé activé Activé(e) Non pris en charge
Windows Server 2016 Non pris en charge Désactivé activé activé Activé(e) Non pris en charge
Windows Server 2019 Non pris en charge Désactivé activé activé Activé(e) Non pris en charge
Édition GS de Microsoft Windows Server 2019 Non pris en charge Disabled Désactivé Disabled Activé(e) Non pris en charge
Windows Server 2022 Non pris en charge Disabled Désactivé Disabled activé Activé(e)

L'édition GS de Windows Server 2019 est conforme à Microsoft SDL, TLS 1.2 uniquement avec un ensemble restreint de suites de chiffrement.

L'édition GS de Windows Server 2019 est conforme à Microsoft SDL, TLS 1.2 et TLS 1.3 uniquement avec un ensemble restreint de suites de chiffrement.

TLS 1.1/1.2 peut être activé sur Windows Server 2008 par le biais de ce package Windows Update facultatif.

Pour plus d'informations sur la dépréciation de TLS 1.0/1.1 dans Internet Explorer/Edge, consultez Modernisation des connexions TLS dans Microsoft Edge et Internet Explorer 11, Changements impactant la compatibilité des sites à venir dans Microsoft Edge et Désactivation de TLS 1.0 et de TLS 1.1 dans le nouveau navigateur Edge.

Pour déterminer rapidement la version de TLS demandée par divers clients au moment de la connexion à vos services en ligne, reportez-vous à la simulation d'établissement de liaison (« Handshake Simulation ») de Qualys SSL Labs. Cette simulation couvre les combinaisons système d'exploitation/navigateur client de plusieurs fabricants. Consultez l'Annexe A à la fin de ce document pour obtenir un exemple détaillé montrant la négociation des versions du protocole TLS par plusieurs combinaisons système d'exploitation/navigateur client simulées lors de la connexion à www.microsoft.com.

Si ce n'est déjà fait, nous vous recommandons vivement de dresser l'inventaire des systèmes d'exploitation utilisés par votre entreprise, vos clients et vos partenaires (pour les deux derniers, prise de contact/communication ou au minimum collecte des chaînes d'agent utilisateur HTTP). Cet inventaire peut être complété par une analyse du trafic à la périphérie de votre réseau d'entreprise. Dans une telle situation, l'analyse du trafic génère les versions de TLS correctement négociées par les clients/partenaires se connectant à vos services, mais le trafic lui-même reste chiffré.

Améliorations techniques apportées par Microsoft pour éliminer les dépendances à TLS 1.0

Depuis la version v1 de ce document, Microsoft a fourni un certain nombre de mises à jour logicielles et de nouvelles fonctionnalités en vue de soutenir la dépréciation de TLS 1.0, Il s'agit notamment des paramètres suivants :

  • Journalisation personnalisée dans IIS pour corréler la chaîne d'agent utilisateur/IP du client, l'URI de service, la version du protocole TLS et la suite de chiffrement.

    • Avec cette journalisation, les administrateurs peuvent enfin quantifier l'exposition de leurs clients à un protocole TLS faible.

  • SecureScore. Pour aider les administrateurs de locataires Office 365 à identifier leur utilisation d'un protocole TLS faible, le portail SecureScore permet de partager des informations (TLS 1.0 n'étant plus pris en charge dans Office 365 depuis octobre 2018).

    • Ce portail fournit aux administrateurs de locataires Office 365 les informations dont ils ont besoin pour contacter leurs clients qui n'ont peut-être pas conscience de leurs propres dépendances à TLS 1.0.

    • Pour plus d'informations, consultez la page https://securescore.microsoft.com/.

  • Mises à jour du .NET Framework pour éliminer le code en dur au niveau des applications et éviter les dépendances à TLS 1.0 héritées du framework.

  • De l'aide et des mises à jour de logiciels pour les développeurs ont été mises en production pour aider les clients à identifier et à éliminer des dépendances .Net sur un protocole TLS faible : Meilleures pratiques de protocole TLS (Transport Layer Security) avec le .NET Framework

    • Pour information : toutes les applications ciblant .NET 4.5 ou version antérieure devront probablement être modifiées pour prendre en charge le protocole TLS 1.2.

  • TLS 1.2 a été rétroporté sur Windows Server 2008 SP2 et XP POSReady 2009 pour aider les clients avec des obligations héritées.

  • D'autres annonces seront faites début 2019 et seront communiquées dans les mises à jour ultérieures de ce document.

Recherche et résolution des dépendances à TLS 1.0 dans le code

Pour les produits utilisant les bibliothèques de chiffrement et les protocoles de sécurité fournis par le système d'exploitation Windows, effectuez les étapes suivantes pour identifier toute utilisation de TLS 1.0 codée en dur dans vos applications :

  1. Identifiez toutes les instances de AcquireCredentialsHandle(). Les réviseurs peuvent ainsi voir de plus près les blocs de code où le protocole TLS peut être codé en dur.

  2. Passez en revue toutes les instances des structures SecPkgContext_SupportedProtocols et SecPkgContext_ConnectionInfo à la recherche d'éléments TLS codés en dur.

  3. Dans le code natif, définissez toutes les affectations de grbitEnabledProtocols non nulles avec la valeur zéro. Le système d'exploitation peut ainsi utiliser sa version de TLS par défaut.

  4. Désactivez le mode FIPS s'il est activé en raison du risque de conflit avec les paramètres nécessaires pour désactiver explicitement TLS 1.0/1.1 dans ce document. Pour plus d'informations, consultez l'Annexe B.

  5. Mettez à jour et recompilez toutes les applications utilisant WinHTTP hébergé sur Server 2012 ou antérieur.

    1. Régénérez et reciblez les applications managées avec la dernière version du .NET Framework.

    2. Pour prendre en charge TLS 1.2, il est nécessaire d'ajouter du code aux applications par le biais de WinHttpSetOption.

  6. Pour couvrir toutes les bases, analysez le code source et les fichiers de configuration du service en ligne à la recherche des modèles ci-dessous, ceux-ci correspondant aux valeurs de types énumérés couramment utilisées dans le code en dur de TLS :

    1. SecurityProtocolType

    2. SSLv2, SSLv23, SSLv3, TLS1, TLS10, TLS11

    3. WINHTTP_FLAG_SECURE_PROTOCOL_

    4. SP_PROT_

    5. NSStreamSocketSecurityLevel

    6. PROTOCOL_SSL ou PROTOCOL_TLS

Dans tous les cas ci-dessus, il est recommandé de supprimer la sélection de la version de protocole codée en dur et de s'en remettre à la valeur par défaut du système d'exploitation. Si vous utilisez DevSkim, cliquez ici pour voir les règles couvrant les vérifications ci-dessus que vous pouvez utiliser avec votre propre code.

Windows PowerShell utilise le .NET Framework 4.5 qui n'inclut pas TLS 1.2 dans les protocoles disponibles. Pour contourner ce problème, vous avez deux solutions :

  1. Modifiez le script en question pour inclure les éléments suivants :

    [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;

  2. Ajoutez une clé de Registre à l'ensemble du système (par exemple, par le biais d'une stratégie de groupe) à tout ordinateur devant établir des connexions TLS 1.2 à partir d'une application .NET. Cela oblige .NET à utiliser les versions « système par défaut » de TLS, ce qui ajoute TLS 1.2 comme protocole disponible. Les scripts pourront également utiliser les futures versions de TLS quand le système d'exploitation les prendra en charge. (par exemple, TLS 1.3).

    reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:64

    reg add HKLM\SOFTWARE\Microsoft.NETFramework\v4.0.30319 /v SystemDefaultTlsVersions /t REG_DWORD /d 1 /f /reg:32

Les solutions (1) et (2) s'excluent mutuellement, ce qui signifie qu'elles ne doivent pas être implémentées ensemble.

Régénérer/recibler des applications managées à l'aide de la dernière version du .NET Framework

Les applications utilisant des versions du .NET Framework antérieures à 4.7 peuvent présenter des restrictions qui limitent la prise en charge de TLS 1.0, indépendamment des valeurs par défaut du système d'exploitation sous-jacent. Pour plus d'informations, consultez le diagramme ci-dessous et les Bonnes pratiques du protocole TLS (Transport Layer Security) avec .NET Framework.

Régénérer des applications managées

SystemDefaultTLSVersion a priorité sur le ciblage au niveau de l'application des versions de TLS. La bonne pratique est toujours de s'en remettre à la version de TLS par défaut du système d'exploitation. C'est également la seule solution de chiffrement agile qui permettra à vos applications de tirer parti de la prise en charge de TLS 1.3 à l'avenir.

Si vous ciblez des versions antérieures du .NET Framework comme 4.5.2 ou 3.5, votre application utilise par défaut les protocoles anciens et non recommandés comme SSL 3.0 ou TLS 1.0. Il est vivement recommandé d'effectuer la mise à niveau vers des versions plus récentes du .NET Framework telles que .NET Framework 4.6 ou de définir les clés de Registre appropriées pour « UseStrongCrypto ».

Test avec TLS 1.2+

Après application des correctifs recommandés dans la section ci-dessus, les produits doivent être testés par régression pour détecter d'éventuelles erreurs de négociation de protocole et vérifier la compatibilité avec d'autres systèmes d'exploitation dans votre entreprise.

  • Le problème le plus courant dans ces tests de régression est un échec de la négociation de TLS causé par une tentative de connexion d'un client à partir d'un système d'exploitation ou d'un navigateur ne prenant pas en charge TLS 1.2.

    • Par exemple, un client Vista ne peut pas négocier TLS avec un serveur configuré pour TLS 1.2+ car la version maximale prise en charge par Vista est TLS 1.0. Ce client doit être mis à niveau ou désactivé dans un environnement TLS 1.2+.

  • Les produits utilisant l'authentification TLS mutuelle basée sur des certificats peuvent nécessiter des tests de régression supplémentaires, car le code de sélection de certificat associé à TLS 1.0 est moins expressif que celui associé à TLS 1.2.

    • Si un produit négocie MTLS avec un certificat issu d'un emplacement non standard (en dehors des magasins de certificats nommés standard dans Windows), ce code peut nécessiter une mise à jour pour garantir que le certificat est correctement acquis.

  • Il est conseillé de passer en revue les interdépendances de service à la recherche de problèmes.

    • Tous les services qui interagissent avec des services tiers doivent faire l'objet de tests d'interopérabilité supplémentaires.

    • Vous devez vérifier/confirmer que les applications ou systèmes d'exploitation serveur non-Windows sont capables de prendre en charge TLS 1.2. Pour cela, le moyen le plus simple est d'effectuer une analyse.

Voici un blueprint simple permettant de tester ces changements dans un service en ligne :

  1. Effectuez une analyse des systèmes d'environnement de production pour identifier les systèmes d'exploitation qui ne prennent pas en charge TLS 1.2.

  2. Analysez le code source et les fichiers de configuration du service en ligne à la recherche d'éléments TLS codés en dur, comme décrit dans la section Recherche et résolution des dépendances à TLS 1.0 dans le code.

  3. Mettez à jour/recompilez les applications au besoin :

    1. Applications gérées

      1. Régénérez-les sur la dernière version du .NET Framework.

      2. Vérifiez que toute énumération SSLProtocols est définie avec SSLProtocols.None de manière à utiliser les paramètres par défaut du système d'exploitation.

    2. Régénérez les applications WinHTTP avec WinHttpSetOption pour prendre en charge TLS 1.2.

  4. Démarrez les tests dans un environnement de préproduction ou intermédiaire en désactivant tous les protocoles de sécurité antérieurs à TLS 1.2 par le biais du Registre.

  5. Corrigez toutes les instances restantes du code en dur de TLS à mesure que vous les rencontrez au cours des tests. Redéployez le logiciel et effectuez une nouvelle série de tests de régression.

Notification des partenaires de vos plans de dépréciation de TLS 1.0

Une fois le code en dur de TLS résolu et les mises à jour du système d'exploitation/framework de développement terminées, vous devez contacter vos clients et partenaires pour coordonner les efforts de dépréciation de TLS 1.0 :

  • Il est essentiel de contacter au plus tôt vos partenaires/clients pour garantir le bon déroulement de la dépréciation de TLS 1.0. Au minimum, vous devez publier des billets de blog, des livres blancs ou d'autres contenus sur le web.

  • Les partenaires doivent évaluer leur propre degré de préparation au protocole TLS 1.2 au moyen des initiatives d'analyse et de test de régression sur le système d'exploitation et le code décrites dans les sections ci-dessus.

Conclusion

La suppression des dépendances au protocole TLS 1.0 est un processus complexe à réaliser de bout en bout. Microsoft et ses partenaires de l'industrie prennent aujourd'hui des mesures visant à renforcer la sécurité par défaut de l'ensemble de leur pile de produits : des applications/services jusqu'aux composants de système d'exploitation et frameworks de développement sur lesquels elles fonctionnent. Les recommandations figurant dans ce document aideront votre d'entreprise à définir une ligne de conduite et à anticiper les problèmes potentiels. Elles permettront également à vos propres clients de mieux se préparer à la transition.

Annexe A : Simulation d'un établissement de liaison (handshake) pour différents clients se connectant à www.microsoft.com, avec la permission de SSLLabs.com

Résultats de la simulation de l’établissement de liaison

Annexe B : Dépréciation de TLS 1.0/1.1 tout en conservant le mode FIPS

Suivez les étapes ci-dessous si votre réseau nécessite le mode FIPS, mais que vous souhaitez également déprécier TLS 1.0/1.1 :

  1. Configurez les versions de TLS par le biais du Registre en définissant « Enabled » avec la valeur zéro pour les versions de TLS indésirables.

  2. Désactivez Curve 25519 (Server 2016 uniquement) par le biais de la stratégie de groupe.

  3. Désactivez les suites de chiffrement utilisant des algorithmes qui ne sont pas autorisés par la publication FIPS appropriée. Pour Server 2016 (en supposant que les paramètres par défaut sont activés), cela signifie désactiver les chiffrements RC4, PSK et NULL.

Contributeurs/Remerciements

Mark Cartwright
Bryan Sullivan
Patrick Jungles
Michael Scovetta
Tony Rice
David LeBlanc
Mortimer Cook
Daniel Sommerfeld
Andrei Popov
Michiko Short
Justin Burke
Gov Maharaj
Brad Turner
Sean Stevenson