Durcir TLS et Schannel sous Windows

La plupart des composants Windows qui parlent TLS le font via Schannel, l'implémentation Windows de SSL et TLS. IIS, le Bureau à distance, LDAPS sur les contrôleurs de domaine, WinRM sur HTTPS, AD FS, SQL Server et toute application .NET Framework qui appelle HttpClient héritent de ses choix de protocoles et de chiffrements. Les anciennes valeurs par défaut laissaient disponibles SSL 3.0, TLS 1.0 et TLS 1.1 et autorisaient des chiffrements comme 3DES et RC4, ouvrant la voie à des attaques par rétrogradation et déchiffrement aux noms évocateurs : POODLE, BEAST, SWEET32.

Ce guide fait partie du domaine Protocoles hérités. Le guide pilier traite de la résolution de noms, de SMB et de NTLM ; ici, l'accent est mis sur le chiffrement du transport.

Où en est Windows aujourd'hui

Microsoft désactive TLS 1.0 et 1.1 par défaut dans les versions récentes de Windows, à commencer par les préversions de Windows 11 en 2023. Windows 11 24H2 et 25H2 ainsi que Windows Server 2025 sont bien plus proches d'une configuration durcie par défaut que Windows Server 2016 ou 2019, mais les valeurs par défaut varient selon le build et certaines dépendent des mises à jour : consultez la documentation Microsoft actuelle pour vos versions et, surtout, mesurez ce que vos serveurs négocient réellement.

Étape 1 : identifier qui utilise encore TLS 1.0 et 1.1

Couper les anciens protocoles à l'aveugle casse des choses dont vous aviez oublié l'existence : un scanner qui envoie des e-mails en SMTP avec STARTTLS, une vieille application Java qui parle à LDAPS, un agent de supervision, une bibliothèque cliente SQL de 2012.

• Journalisation des événements Schannel. Augmentez la journalisation sous HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL avec EventLogging (DWORD). La valeur par défaut 1 ne journalise que les erreurs ; 7 journalise les erreurs, avertissements et événements d'information, y compris les négociations réussies (l'événement 36880 du journal Système indique le protocole et la suite de chiffrement). C'est bruyant : activez-le sur un échantillon de serveurs pendant quelques jours, pas de façon permanente.
• Journalisation IIS. IIS 10 peut journaliser le protocole et le chiffrement négociés via des champs de journal personnalisés basés sur des variables serveur comme CRYPT_PROTOCOL et CRYPT_CIPHER_ALG_ID. Ajoutez-les sur les serveurs web et recherchez les valeurs correspondant à TLS 1.0 et 1.1.
• Contrôleurs de domaine. Les clients LDAPS qui utilisent un ancien TLS apparaissent dans les événements Schannel des DC. Testez un DC en laboratoire avant la production : certains équipements réseau ne parlent que TLS 1.0 avec LDAPS.
• Analyse externe. Des outils comme le script ssl-enum-ciphers de Nmap ou testssl.sh, lancés depuis un poste d'administration contre chaque service à l'écoute, donnent une vue avant/après.

Étape 2 : désactiver les anciens protocoles

Les paramètres de protocole se trouvent sous HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\<Protocol>\Server et ...\Client. Deux valeurs DWORD pilotent chacun : Enabled et DisabledByDefault.

$base = "HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols"
foreach ($p in "SSL 2.0","SSL 3.0","TLS 1.0","TLS 1.1") {
  foreach ($side in "Server","Client") {
    $key = "$base\$p\$side"
    New-Item -Path $key -Force | Out-Null
    Set-ItemProperty -Path $key -Name Enabled -Value 0 -Type DWord
    Set-ItemProperty -Path $key -Name DisabledByDefault -Value 1 -Type DWord
  }
}
foreach ($side in "Server","Client") {
  $key = "$base\TLS 1.2\$side"
  New-Item -Path $key -Force | Out-Null
  Set-ItemProperty -Path $key -Name Enabled -Value 1 -Type DWord
  Set-ItemProperty -Path $key -Name DisabledByDefault -Value 0 -Type DWord
}

À grande échelle, déployez les mêmes valeurs avec des éléments de registre des préférences de stratégie de groupe ou une correction Intune, puis redémarrez. Désactivez d'abord le côté Server sur les serveurs que vous avez inventoriés ; désactivez le côté Client une fois que vous savez que la machine ne se connecte pas à des services hérités. Les référentiels de sécurité Microsoft ne gèrent pas ces clés : c'est l'un des paramètres que vous ajoutez vous-même.

Étape 3 : supprimer les chiffrements et échanges de clés faibles

Les commutateurs de chiffrement se trouvent sous ...\SCHANNEL\Ciphers\<Cipher> avec Enabled = 0 :

Pour Diffie-Hellman, définissez ServerMinKeyBitLength = 2048 (DWORD, valeur 0x800) sous ...\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman. La plupart des suites modernes utilisent de toute façon ECDHE, mais cela empêche une rétrogradation vers des groupes DH faibles.

Plusieurs noms de clés contiennent une barre oblique, que le fournisseur de registre de PowerShell gère mal. Créez-les avec un fichier .reg, les préférences de stratégie de groupe ou l'API de registre .NET plutôt qu'avec New-Item.

Étape 4 : définir l'ordre des suites de chiffrement

L'ordre des suites de chiffrement détermine quelles suites Schannel propose et avec quelle priorité. Configurez-le par stratégie de groupe : Computer Configuration > Policies > Administrative Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order. La valeur est une liste unique séparée par des virgules ; la zone de texte de la stratégie est limitée à 1 023 caractères, alors ne listez que ce que vous voulez, de la plus forte à la plus faible. Une liste TLS 1.2 raisonnable pour des serveurs :

TLS_ECDHE_ECDSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_ECDSA_WITH_AES_128_GCM_SHA256,
TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384,
TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256

Saisissez-la sans retour à la ligne. Sur Windows 11 et Server 2022 et versions ultérieures, ajoutez en tête les suites TLS 1.3 (TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256) si vous gérez l'ordre par stratégie, sinon elles risquent d'être omises. Le paramètre associé ECC Curve Order, dans le même dossier, définit la préférence des courbes.

Le module PowerShell TLS affiche et modifie la liste effective localement :

Get-TlsCipherSuite | Format-Table Name, Protocols
Disable-TlsCipherSuite -Name "TLS_RSA_WITH_3DES_EDE_CBC_SHA"
Get-TlsEccCurve

Lorsque le paramètre de stratégie de groupe est présent, il l'emporte sur les modifications locales faites avec ces cmdlets. Gérez l'ordre à un seul endroit.

Gardez une solution de repli en tête : si vous supprimez toutes les suites non ECDHE, certains clients et équipements anciens qui ne font que TLS_RSA_WITH_AES_* cesseront de fonctionner. Décidez en connaissance de cause, à partir de l'inventaire de l'étape 1.

Étape 5 : forcer .NET Framework à utiliser une cryptographie forte

Les applications .NET Framework compilées pour d'anciennes cibles peuvent se figer sur TLS 1.0 indépendamment de Schannel. Deux valeurs corrigent cela pour les runtimes 64 bits et 32 bits :

$paths = "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319",
         "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319",
         "HKLM:\SOFTWARE\Microsoft\.NETFramework\v2.0.50727",
         "HKLM:\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727"
foreach ($p in $paths) {
  if (Test-Path $p) {
    Set-ItemProperty $p -Name SchUseStrongCrypto -Value 1 -Type DWord
    Set-ItemProperty $p -Name SystemDefaultTlsVersions -Value 1 -Type DWord
  }
}

SystemDefaultTlsVersions laisse le système d'exploitation choisir le protocole, et SchUseStrongCrypto retire les protocoles et chiffrements faibles des valeurs par défaut propres à .NET. Les applications qui codent en dur SecurityProtocolType.Tls nécessitent toujours une modification du code. Le .NET moderne (5 et versions ultérieures) utilise déjà les valeurs par défaut du système.

Étape 6 : déployer par anneaux

Les changements Schannel s'appliquent à toute la machine et exigent un redémarrage : un changement raté fait tomber d'un coup tous les services TLS de l'hôte. Déployez selon le risque, pas selon la commodité :

Pour chaque anneau, relevez le résultat de l'analyse et le nombre d'erreurs Schannel avant et après. Gardez un retour arrière prêt : une GPO ou un script qui remet Enabled à 1 pour le protocole concerné, et non une restauration complète de la clé SCHANNEL.

Les exceptions sont normales. Un vieil équipement qui ne parle que TLS 1.0 se traite mieux en l'isolant sur son propre segment réseau derrière un proxy qui termine un TLS moderne qu'en laissant TLS 1.0 activé sur les serveurs avec lesquels il communique.

Ce qui casse

• Anciens builds de SQL Server et pilotes clients antérieurs à la prise en charge de TLS 1.2. Corrigez SQL Server et mettez à jour les pilotes (ODBC, OLE DB) d'abord.
• Imprimantes, scanners et équipements qui envoient des e-mails ou interrogent LDAPS.
• Anciens clients RDP sur des systèmes non corrigés, quand TLS 1.0 est désactivé sur les hôtes RDP.
• Logiciels tiers embarquant Java ou OpenSSL qui codent TLS 1.0 en dur.
• Outils de gestion qui se connectent à WinRM sur HTTPS ou à WSUS depuis d'anciennes versions du système.

Vérifier

1. Depuis l'extérieur : relancez l'analyse de l'étape 1. Les négociations TLS 1.0 et 1.1 doivent échouer ; seules les suites choisies sont proposées.
2. Sur l'hôte : Get-TlsCipherSuite ne renvoie que les suites attendues ; les clés de registre correspondent au tableau ci-dessus.
3. Journaux : gardez EventLogging de Schannel à 1 en production et alertez sur les pics d'événements d'erreur Schannel après chaque anneau de changement.
4. Applications : exécutez les tests de fumée de votre liste d'inventaire, pas seulement une vérification dans le navigateur ; les navigateurs n'utilisent pas ces paramètres.

Liste de contrôle

• Utilisateurs de TLS 1.0/1.1 inventoriés via les événements Schannel, les journaux IIS et les analyses
• SSL 2.0/3.0 désactivés partout ; TLS 1.0/1.1 désactivés côté serveur, puis côté client
• NULL, DES, RC2, RC4 et 3DES désactivés ; DH minimum 2048 bits
• Ordre des suites de chiffrement défini une seule fois, par GPO, ECDHE avec AES-GCM en tête
• SchUseStrongCrypto et SystemDefaultTlsVersions de .NET définis dans les clés 32 et 64 bits
• Serveurs redémarrés et réanalysés après chaque anneau
• Exceptions documentées avec un responsable et une date de fin

Un TLS robuste protège les canaux dont dépendent d'autres contrôles, comme WinRM sur HTTPS et le Bureau à distance. Revérifiez-le après chaque actualisation de référentiel décrite dans le guide des référentiels de sécurité.