Partager via

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

Ce document présente les dernières instructions sur l’identification et la suppression rapides des dépendances de protocole TLS (Transport Layer Security) version 1.0 dans les logiciels basés sur les systèmes d’exploitation Microsoft, en suivant les détails sur les modifications de produits et les nouvelles fonctionnalités fournies par Microsoft pour protéger vos propres clients et services en ligne. Il est destiné à être utilisé comme point de départ pour la création d’un plan de migration vers un environnement réseau TLS 1.2+. Bien que les solutions présentées ici puissent porter et aider à supprimer l’utilisation de TLS 1.0 dans les systèmes d’exploitation ou les bibliothèques de chiffrement non-Microsoft, elles ne sont pas l’objet de ce document.

TLS 1.0 est un protocole de sécurité défini en 1999 pour établir des canaux de chiffrement sur des réseaux informatiques. Microsoft a pris en charge ce protocole depuis Windows XP/Server 2003. Bien que le protocole de sécurité par défaut utilisé par les systèmes d’exploitation modernes ne soit plus utilisé, TLS 1.0 est toujours pris en charge pour la compatibilité descendante. L’évolution des exigences réglementaires ainsi que les nouvelles vulnérabilités de sécurité dans TLS 1.0 permettent aux entreprises de désactiver entièrement TLS 1.0.

Microsoft recommande aux clients d’anticiper ce problème en supprimant les dépendances TLS 1.0 dans leurs environnements et en désactivant TLS 1.0 au niveau du système d’exploitation, le cas échéant. Étant donné la durée pendant laquelle TLS 1.0 a été pris en charge par le secteur logiciel, il est vivement recommandé que tout plan de dépréciation TLS 1.0 inclut les éléments suivants :

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

  • Analyse du point de terminaison réseau et analyse du trafic pour identifier les systèmes d’exploitation à l’aide de PROTOCOLES TLS 1.0 ou plus anciens.

  • Test de régression complet via l’ensemble de votre pile d’applications avec TLS 1.0 désactivé.

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

  • Tests de compatibilité entre les systèmes d’exploitation utilisés par votre entreprise pour identifier les problèmes de prise en charge de TLS 1.2.

  • La coordination avec vos propres partenaires commerciaux et clients pour les informer de votre décision de retirer progressivement TLS 1.0.

  • Comprendre quels clients peuvent ne plus être en mesure de se connecter à vos serveurs une fois tls 1.0 désactivé.

L’objectif de ce document est de fournir des recommandations qui peuvent aider à supprimer des bloqueurs techniques pour désactiver TLS 1.0 tout en augmentant la visibilité sur l’impact de ce changement sur vos propres clients. La réalisation de ces enquêtes peut contribuer à réduire l’impact métier de la prochaine vulnérabilité de sécurité dans TLS 1.0. Dans le cadre de 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 sécurisées et agiles (autrement appelées agilité de chiffrement) pour traiter les futures compromissions du protocole de sécurité. Bien que ce document propose des solutions agiles pour l’élimination du codage en dur TLS, les solutions d’agilité de chiffrement plus larges dépassent le cadre de ce document.

État actuel de l’implémentation tls 1.0 de Microsoft

L’implémentation TLS 1.0 de Microsoft est exempte de vulnérabilités de sécurité connues. En raison du potentiel de futures attaques de rétrogradation de protocole et d’autres vulnérabilités TLS 1.0 non spécifiques à l’implémentation de Microsoft, il est recommandé de supprimer les dépendances de tous les protocoles de sécurité antérieurs à TLS 1.2 (TLS 1.1/1.0/ SSLv3/SSLv2).

Lors de la planification de cette migration vers TLS 1.2+, les développeurs et les administrateurs système doivent connaître le potentiel de codage en dur de version de protocole dans les applications développées par leurs employés et partenaires. Le codage en dur ici signifie que la version TLS est fixe à une version obsolète et moins sécurisée que les versions plus récentes. Les versions TLS plus récentes que la version codée en dur ne peuvent pas être utilisées sans modifier le programme en question. Cette classe de problème ne peut pas être traitée sans modifications de code source et déploiement de mises à jour logicielles. Le codage en dur de version de protocole était courant dans le passé pour les tests et la prise en charge, car de nombreux navigateurs et systèmes d’exploitation différents avaient différents niveaux de prise en charge TLS.

Versions prises en charge de TLS dans Windows

De nombreux systèmes d’exploitation ont des valeurs par défaut obsolètes de la version TLS ou des plafonds de prise en charge qui doivent être pris en 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é Activé Activé Non pris en charge Non pris en charge Non pris en charge
Windows Server 2008 Activé Activé Activé Désactivé* Désactivé* Non pris en charge
Windows 7 (WS2008 R2) Activé Activé Activé Désactivé* Désactivé* Non pris en charge
Windows 8 (WS2012) Désactivé Activé Activé Activé Activé Non pris en charge
Windows 8.1 (WS2012 R2) Désactivé Activé Activé Activé Activé Non pris en charge
Windows 10 Désactivé Activé Activé Activé Activé Non pris en charge
Windows 11 Désactivé Activé Activé Activé Activé Activé
Windows Server 2016 Non pris en charge Désactivé Activé Activé Activé Non pris en charge
Windows Server 2016 Non pris en charge Désactivé Activé Activé Activé Non pris en charge
Windows Server 2019 Non pris en charge Désactivé Activé Activé Activé Non pris en charge
Édition GS de Windows Server 2019 Non pris en charge Désactivé Désactivé Désactivé Activé Non pris en charge
Windows Server 2022 Non pris en charge Désactivé Désactivé Désactivé Activé Activé

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

Windows Server 2022 édition 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 via 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, modifications ayant un impact sur la compatibilité des sites arrivant à Microsoft Edge et la désactivation de TLS/1.0 et TLS/1.1 dans le nouveau navigateur Edge

Un moyen rapide de déterminer la version TLS demandée par différents clients lors de la connexion à vos services en ligne consiste à faire référence à la simulation d’établissement d’une liaison à Qualys SSL Labs. Cette simulation couvre les combinaisons de système d’exploitation/navigateur client entre les fabricants. Consultez l’annexe A à la fin de ce document pour obtenir un exemple détaillé montrant les versions de protocole TLS négociées par diverses combinaisons de système d’exploitation/navigateur client simulées lors de la connexion à www.microsoft.com.

S’il n’est pas déjà terminé, il est vivement recommandé d’effectuer un inventaire des systèmes d’exploitation utilisés par votre entreprise, vos clients et vos partenaires (ces deux derniers via la communication ou au moins la collecte des chaînes de User-Agent HTTP). Cet inventaire peut être complété par l’analyse du trafic à la périphérie de votre réseau d’entreprise. Dans ce cas, l’analyse du trafic génère les versions TLS correctement négociées par les clients/partenaires qui se connectent à vos services, mais le trafic lui-même reste chiffré.

Améliorations de l’ingénierie de 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 pour prendre en charge la dépréciation de TLS 1.0. Voici quelques-uns des éléments suivants :

  • Journalisation personnalisée IIS pour mettre en corrélation l'adresse IP du client, la chaîne d’agent utilisateur, l’URI du service, la version du protocole TLS et la suite de chiffrement.

    • Avec cette journalisation, les administrateurs peuvent enfin quantifier l’exposition de leurs clients au protocole TLS faible.

  • SecureScore - Pour aider les administrateurs clients Office 365 à identifier leur propre utilisation faible du protocole TLS, le portail SecureScore a été conçu pour partager ces informations en tant que support TLS 1.0 quitté dans Office 365 en octobre 2018.

    • Ce portail fournit aux administrateurs clients Office 365 les informations précieuses dont ils ont besoin pour contacter leurs propres clients qui peuvent ne pas connaître leurs propres dépendances TLS 1.0.

    • Visitez https://securescore.microsoft.com/ pour plus d’informations.

  • Mises à jour de .Net Framework pour éliminer le codage en dur au niveau de l’application et empêcher les dépendances TLS 1.0 héritées du framework.

  • Les conseils pour les développeurs et les mises à jour logicielles ont été publiés pour aider les clients à identifier et à éliminer les dépendances .NET sur TLS faible : Meilleures pratiques de TLS (Transport Layer Security) avec le .NET Framework

    • FYI : Toutes les applications ciblant .NET 4.5 ou ci-dessous doivent probablement être modifiées pour prendre en charge TLS 1.2.

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

  • D’autres annonces seront faites au début de 2019 et 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 fournies par le système d’exploitation Windows et les protocoles de sécurité, les étapes suivantes doivent vous aider à identifier toute utilisation tls 1.0 codée en dur dans vos applications :

  1. Identifiez toutes les instances d’AcquireCredentialsHandle(). Cela permet aux réviseurs de se rapprocher des blocs de code où TLS peut être codé en dur.

  2. Passez en revue les instances des structures de SecPkgContext_SupportedProtocols et de SecPkgContext_ConnectionInfo pour le protocole TLS codé en dur.

  3. Dans le code natif, définissez toutes les affectations non nulles de grbitEnabledProtocols sur zéro. Cela permet au système d’exploitation d’utiliser sa version TLS par défaut.

  4. Désactivez le mode FIPS s’il est activé en raison du risque de conflit avec les paramètres requis 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 à l’aide de WinHTTP hébergées sur Server 2012 ou version antérieure.

    1. Applications managées : regénérer et recibler sur la dernière version du .NET Framework

    2. Les applications doivent ajouter du code pour prendre en charge TLS 1.2 via WinHttpSetOption

  6. Pour couvrir toutes les bases, analysez le code source et les fichiers de configuration de service en ligne pour les modèles ci-dessous correspondant aux valeurs de type énumérées couramment utilisées dans le codage en dur TLS :

    1. SecurityProtocolType

    2. SSLv2, SSLv23, SSLv3, TLS1, TLS 10, TLS11

    3. WINHTTP_FLAG_SECURE_PROTOCOL_

    4. SP_PROT_

    5. NSStreamSocketSecurityLevel

    6. PROTOCOL_SSL ou PROTOCOL_TLS

La solution recommandée dans tous les cas ci-dessus consiste à supprimer la sélection de version du protocole codé en dur et à différer 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 .NET Framework 4.5, qui n’inclut pas TLS 1.2 comme protocole disponible. Pour contourner ce problème, deux solutions sont disponibles :

  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’échelle du système (par exemple, via une stratégie de groupe) à n’importe quel ordinateur qui doit établir des connexions TLS 1.2 à partir d’une application .NET. Ainsi, .NET utilise les versions TLS « Par défaut du système » qui ajoute TLS 1.2 en tant que protocole disponible ET permet aux scripts d’utiliser les futures versions TLS lorsque le système d’exploitation les prend 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) sont mutuellement exclusives, ce qui signifie qu’elles ne doivent pas être implémentées ensemble.

Reconstruire ou recibler des applications managées en utilisant la dernière version du .NET Framework

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

Reconstruire des applications managées

SystemDefaultTLSVersion a priorité sur le ciblage des versions TLS au niveau de l'application. La meilleure pratique recommandée consiste à toujours différer vers la version TLS par défaut du système d’exploitation. Il s’agit également de la seule solution crypto-agile qui permet à vos applications de tirer parti de la prise en charge future de TLS 1.3.

Si vous ciblez des versions antérieures de .NET Framework telles que 4.5.2 ou 3.5, votre application utilise par défaut les protocoles plus anciens et non recommandés tels que SSL 3.0 ou TLS 1.0. Il est vivement recommandé de mettre à niveau vers des versions plus récentes de .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 les correctifs recommandés dans la section ci-dessus, les produits doivent être testés par régression pour les erreurs de négociation de protocole et la compatibilité avec d’autres systèmes d’exploitation de votre entreprise.

  • Le problème le plus courant dans ce test de régression est un échec de négociation TLS en raison d’une tentative de connexion cliente à partir d’un système d’exploitation ou d’un navigateur qui ne prend pas en charge TLS 1.2.

    • Par exemple, un client Vista ne parvient pas à négocier TLS avec un serveur configuré pour TLS 1.2+ car la version TLS maximale prise en charge de Vista est 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 un certificat peuvent nécessiter des tests de régression supplémentaires, car le code de sélection de certificat associé à TLS 1.0 était moins expressif que celui pour TLS 1.2.

    • Si un produit négocie MTLS avec un certificat à partir d’un emplacement non standard (en dehors des magasins de certificats nommés standard dans Windows), ce code peut avoir besoin de mettre à jour pour s’assurer que le certificat est acquis correctement.

  • Les interdépendances de service doivent être examinées pour les points de problèmes.

    • Tous les services qui interagissent avec des services tiers doivent effectuer des tests d’interopérabilité supplémentaires avec ces tiers.

    • Toutes les applications ou systèmes d’exploitation serveur non-Windows en cours d’utilisation nécessitent une investigation/confirmation qu’elles peuvent prendre en charge TLS 1.2. L’analyse est le moyen le plus simple de déterminer cela.

Un blueprint simple pour tester ces modifications dans un service en ligne se compose des éléments suivants :

  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. Analyser le code source et les fichiers de configuration de service en ligne pour le protocole TLS codé en dur, comme décrit dans « Recherche et résolution des dépendances TLS 1.0 dans le code »

  3. Mettre à jour/recompiler les applications selon les besoins :

    1. Applications gérées

      1. Régénérer par rapport à la dernière version du .NET Framework.

      2. Vérifiez que l’utilisation de l’énumération SSLProtocols est définie sur SSLProtocols.None pour utiliser les paramètres par défaut du système d’exploitation.

    2. Applications WinHTTP : reconstruire avec WinHttpSetOption pour prendre en charge TLS 1.2

  4. Commencez à tester dans un environnement de préproduction ou de préproduction avec tous les protocoles de sécurité antérieurs à TLS 1.2 désactivés via le Registre.

  5. Corrigez les instances restantes du codage en dur TLS à mesure qu’elles sont rencontrées lors du test. Redéployez le logiciel et effectuez une nouvelle exécution de test de régression.

Informer les partenaires au sujet de vos plans d'abandon de TLS 1.0

Une fois le codage en dur TLS résolu et que les mises à jour du framework de développement/système d’exploitation sont terminées, si vous choisissez de déprécier TLS 1.0, il sera nécessaire de coordonner avec les clients et les partenaires :

  • Une communication précoce avec les partenaires et les clients est essentielle pour la mise hors service réussie de TLS 1.0. Au minimum, il doit s’agir de publications de blog, de livres blancs ou d’autres contenus web.

  • Les partenaires doivent chacun évaluer leur propre préparation TLS 1.2 par le biais des initiatives d’analyse du système d’exploitation/de code/de test de régression décrites dans les sections ci-dessus.

Conclusion

La suppression des dépendances TLS 1.0 est un problème compliqué à gérer de bout en bout. Microsoft et les partenaires du secteur prennent des mesures pour s’assurer que l’ensemble de notre pile de produits est plus sécurisée par défaut, de nos composants de système d’exploitation et de nos infrastructures de développement jusqu’aux applications/services basés sur eux. Les recommandations faites dans ce document aideront votre entreprise à suivre le bon cours et à connaître les défis à attendre. Il aidera également vos propres clients à se préparer davantage à la transition.

Annexe A : Simulation de négociation pour différents clients se connectant à www.microsoft.com, grâce à SSLLabs.com

Résultats de la simulation de poignée de main

Annexe B : Dépréciation du protocole 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 TLS via le Registre, en définissant « Activé » sur zéro pour les versions TLS indésirables.

  2. Désactivez la courbe 25519 (Server 2016 uniquement) via la stratégie de groupe.

  3. Désactivez les suites de chiffrement à l’aide d’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 en vigueur), cela signifie désactiver les chiffrements RC4, PSK et NULL.

Contributeurs/Merci

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

  • Last updated on