TLS und Schannel unter Windows härten

Die meisten Windows-Komponenten, die TLS sprechen, tun dies über Schannel, die Windows-Implementierung von SSL und TLS. IIS, Remotedesktop, LDAPS auf Domänencontrollern, WinRM über HTTPS, AD FS, SQL Server und jede .NET-Framework-Anwendung, die HttpClient aufruft, erben dessen Protokoll- und Verschlüsselungsauswahl. Alte Standardwerte hielten SSL 3.0, TLS 1.0 und TLS 1.1 verfügbar und ließen Verfahren wie 3DES und RC4 zu, die Downgrade- und Entschlüsselungsangriffe mit Namen wie POODLE, BEAST und SWEET32 ermöglichen.

Dieser Leitfaden gehört zum Bereich Legacy-Protokolle. Der Grundlagenleitfaden behandelt Namensauflösung, SMB und NTLM; hier geht es um die Transportverschlüsselung.

Wo Windows heute steht

Microsoft deaktiviert TLS 1.0 und 1.1 in neueren Windows-Versionen standardmäßig, beginnend mit Windows-11-Previews im Jahr 2023. Windows 11 24H2 und 25H2 sowie Windows Server 2025 liegen deutlich näher an einem gehärteten Standard als Windows Server 2016 oder 2019. Die Standardwerte variieren jedoch je nach Build, und einige werden über Updates gesteuert. Prüfen Sie daher die aktuelle Microsoft-Dokumentation für Ihre Versionen und, noch wichtiger, messen Sie, was Ihre Server tatsächlich aushandeln.

Schritt 1: herausfinden, wer noch TLS 1.0 und 1.1 nutzt

Wer alte Protokolle blind abschaltet, legt Dinge lahm, deren Existenz er vergessen hat: einen Scanner, der Mails per SMTP mit STARTTLS versendet, eine alte Java-Anwendung, die mit LDAPS spricht, einen Monitoring-Agent, eine SQL-Clientbibliothek aus dem Jahr 2012.

• Schannel-Ereignisprotokollierung. Erhöhen Sie die Protokollierung unter HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL mit EventLogging (DWORD). Der Standardwert 1 protokolliert nur Fehler; 7 protokolliert Fehler, Warnungen und Informationsereignisse, einschließlich erfolgreicher Handshakes (Ereignis 36880 im Systemprotokoll zeigt Protokoll und Cipher Suite). Das erzeugt viel Rauschen; aktivieren Sie es für einige Tage auf einer Stichprobe von Servern, nicht dauerhaft.
• IIS-Protokollierung. IIS 10 kann das ausgehandelte Protokoll und die Verschlüsselung über benutzerdefinierte Protokollfelder auf Basis von Servervariablen wie CRYPT_PROTOCOL und CRYPT_CIPHER_ALG_ID protokollieren. Fügen Sie sie auf Webservern hinzu und suchen Sie nach den Protokollwerten für TLS 1.0 und 1.1.
• Domänencontroller. LDAPS-Clients mit altem TLS tauchen in den Schannel-Ereignissen auf DCs auf. Testen Sie einen DC im Labor, bevor Sie in die Produktion gehen: Manche Netzwerk-Appliances sprechen mit LDAPS nur TLS 1.0.
• Externer Scan. Werkzeuge wie das Nmap-Skript ssl-enum-ciphers oder testssl.sh, von einem Admin-Arbeitsplatz aus gegen jeden lauschenden Dienst ausgeführt, liefern ein Vorher-nachher-Bild.

Schritt 2: alte Protokolle deaktivieren

Die Protokolleinstellungen liegen unter HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\<Protocol>\Server und ...\Client. Jedes Protokoll wird über zwei DWORD-Werte gesteuert: Enabled und 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
}

Verteilen Sie in größerem Umfang dieselben Werte mit Registrierungselementen der Gruppenrichtlinieneinstellungen (Group Policy Preferences) oder einer Intune-Wartung und starten Sie neu. Deaktivieren Sie zuerst die Server-Seite auf Servern, die Sie inventarisiert haben; deaktivieren Sie die Client-Seite, sobald Sie wissen, dass der Rechner keine ausgehenden Verbindungen zu Altdiensten aufbaut. Die Microsoft-Sicherheitsbaselines verwalten diese Schlüssel nicht; es ist also eine der Einstellungen, die Sie selbst ergänzen.

Schritt 3: schwache Verschlüsselungen und Schlüsselaustauschverfahren entfernen

Die Schalter für Verschlüsselungsverfahren liegen unter ...\SCHANNEL\Ciphers\<Cipher> mit Enabled = 0:

Setzen Sie für Diffie-Hellman ServerMinKeyBitLength = 2048 (DWORD, Wert 0x800) unter ...\SCHANNEL\KeyExchangeAlgorithms\Diffie-Hellman. Die meisten modernen Suites verwenden ohnehin ECDHE, aber so verhindern Sie ein Downgrade auf schwache DH-Gruppen.

Mehrere Schlüsselnamen enthalten einen Schrägstrich, mit dem der Registrierungsanbieter von PowerShell schlecht umgeht. Erstellen Sie sie mit einer .reg-Datei, über Gruppenrichtlinieneinstellungen oder mit der .NET-Registrierungs-API statt mit New-Item.

Schritt 4: die Cipher-Suite-Reihenfolge festlegen

Die Cipher-Suite-Reihenfolge bestimmt, welche Suites Schannel anbietet und mit welcher Priorität. Konfigurieren Sie sie per Gruppenrichtlinie: Computer Configuration > Policies > Administrative Templates > Network > SSL Configuration Settings > SSL Cipher Suite Order. Der Wert ist eine einzige, durch Kommas getrennte Liste; das Textfeld der Richtlinie ist auf 1.023 Zeichen begrenzt. Führen Sie also nur auf, was Sie wollen, die stärksten zuerst. Eine sinnvolle TLS-1.2-Liste für Server:

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

Geben Sie sie ohne Zeilenumbrüche ein. Unter Windows 11 und ab Server 2022 fügen Sie die TLS-1.3-Suites (TLS_AES_256_GCM_SHA384, TLS_AES_128_GCM_SHA256) oben ein, wenn Sie die Reihenfolge per Richtlinie verwalten, sonst fehlen sie womöglich. Die zugehörige Einstellung ECC Curve Order im selben Ordner legt die Priorität der Kurven fest.

Das PowerShell-Modul TLS zeigt die effektive Liste lokal an und bearbeitet sie:

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

Ist die Gruppenrichtlinieneinstellung vorhanden, hat sie Vorrang vor lokalen Änderungen mit diesen Cmdlets. Verwalten Sie die Reihenfolge nur an einer Stelle.

Denken Sie an einen Rückfallweg: Entfernen Sie alle Suites ohne ECDHE, funktionieren einige ältere Clients und Appliances nicht mehr, die nur TLS_RSA_WITH_AES_* beherrschen. Entscheiden Sie bewusst, auf Grundlage der Bestandsaufnahme aus Schritt 1.

Schritt 5: .NET Framework auf starke Kryptografie umstellen

.NET-Framework-Anwendungen, die gegen ältere Zielversionen erstellt wurden, legen sich unter Umständen unabhängig von Schannel auf TLS 1.0 fest. Zwei Werte beheben das für die 64-Bit- und die 32-Bit-Laufzeit:

$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 lässt das Betriebssystem das Protokoll wählen, und SchUseStrongCrypto entfernt schwache Protokolle und Verschlüsselungen aus den eigenen Standardwerten von .NET. Anwendungen, die SecurityProtocolType.Tls fest codieren, benötigen trotzdem eine Codeänderung. Modernes .NET (ab Version 5) verwendet bereits die Standardwerte des Betriebssystems.

Schritt 6: in Ringen ausrollen

Schannel-Änderungen gelten für den gesamten Rechner und erfordern einen Neustart; eine fehlgeschlagene Änderung legt also alle TLS-Dienste auf diesem Host gleichzeitig lahm. Rollen Sie nach Risiko aus, nicht nach Bequemlichkeit:

Erfassen Sie für jeden Ring das Scanergebnis und die Anzahl der Schannel-Fehler vorher und nachher. Halten Sie ein Rollback bereit: ein GPO oder Skript, das Enabled für das konkrete Protokoll wieder auf 1 setzt, keine pauschale Wiederherstellung des Schlüssels SCHANNEL.

Ausnahmen sind normal. Eine alte Appliance, die nur TLS 1.0 spricht, isolieren Sie besser in einem eigenen Netzsegment hinter einem Proxy, der modernes TLS terminiert, als TLS 1.0 auf den Servern aktiviert zu lassen, mit denen sie kommuniziert.

Was dabei kaputtgeht

• Alte SQL-Server-Builds und Clienttreiber, die älter sind als die TLS-1.2-Unterstützung. Patchen Sie zuerst SQL Server und aktualisieren Sie die Treiber (ODBC, OLE DB).
• Drucker, Scanner und Appliances, die Mails versenden oder LDAPS abfragen.
• Alte RDP-Clients auf ungepatchten Systemen, wenn TLS 1.0 auf den RDP-Hosts abgeschaltet ist.
• Drittanbietersoftware mit eingebettetem Java oder OpenSSL, die TLS 1.0 fest codiert.
• Managementwerkzeuge, die sich von alten Betriebssystemversionen aus per HTTPS mit WinRM oder mit WSUS verbinden.

Überprüfen

1. Von außen: Wiederholen Sie den Scan aus Schritt 1. TLS-1.0- und TLS-1.1-Handshakes müssen fehlschlagen; nur die von Ihnen gewählten Suites werden angeboten.
2. Auf dem Host: Get-TlsCipherSuite liefert nur die erwarteten Suites; die Registrierungsschlüssel entsprechen der Tabelle oben.
3. Protokolle: Belassen Sie Schannel-EventLogging in der Produktion bei 1 und alarmieren Sie nach jedem Änderungsring bei Spitzen in den Schannel-Fehlerereignissen.
4. Anwendungen: Führen Sie die Smoke-Tests Ihrer Inventarliste aus, nicht nur einen Browsertest; Browser verwenden diese Einstellungen nicht.

Checkliste

• Nutzer von TLS 1.0/1.1 über Schannel-Ereignisse, IIS-Protokolle und Scans inventarisiert
• SSL 2.0/3.0 überall deaktiviert; TLS 1.0/1.1 serverseitig, dann clientseitig deaktiviert
• NULL, DES, RC2, RC4 und 3DES deaktiviert; DH-Minimum 2048 Bit
• Cipher-Suite-Reihenfolge einmalig per GPO festgelegt, ECDHE mit AES-GCM zuerst
• .NET-Werte SchUseStrongCrypto und SystemDefaultTlsVersions in den 32- und 64-Bit-Schlüsseln gesetzt
• Server nach jedem Ring neu gestartet und erneut gescannt
• Ausnahmen mit Verantwortlichem und Enddatum dokumentiert

Starkes TLS schützt die Kanäle, auf die andere Maßnahmen angewiesen sind, etwa WinRM über HTTPS und Remotedesktop. Prüfen Sie es nach jeder Aktualisierung der Baselines erneut, wie im Leitfaden zu Sicherheitsbaselines beschrieben.