Mit Windows Server 2022 unterstützt Microsoft endlich in den Serversystemen auch TLS 1.3. Wer 2022 einsetzen kann, sollte TLS 1.3 und die zugehörigen Cipher standardmäßig aktivieren, um auf dem aktuellen Stand verschlüsselter Verbindungen zu sein.
Die Aktivierung erfolgt per Registry-Eintrag dort, wo SChannel, die entsprechende Windows-Komponente für diese Funktionalität, auch sonstige Einstellungen erwartet.
HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols
Hier werden passend zu den bisher bekannten Einstellungen für TLS 1.0, 1.1 und 1.2 die selben Parameter „Enabled = 1“ gesetzt, nur halt unter einem „TLS 1.3“ genannten Key.
Idealerweise verteilt man solche Einstellungen per Gruppenrichtlinie an alle passenden Systeme. Da nicht klar ist, welche Auswirkungen die Einstellung auf Systeme hat, die noch kein TLS 1.3 unterstützen, sollte man die Verteilung auf Server 2022 Systeme beschränken.
Und macht man genau das, was logisch und sinnvoll erscheint, rennt man mit Anlauf in die erste Falle!
Schaut man nämlich die Liste der möglichen Betriebssysteme an, auf die man hier filtern kann, fällt einem schnell eines auf…
Da fehlt was. Server 2016 und Server 2019 sind gar nicht genannt. Windows 11 nebenbei auch nicht.
Und was passiert, wenn man jetzt „Windows Server 2022 Family“ für den zu verteilenden Registry-Wert auswählt? Das, was zu befürchten war: der Eintrag landet bei allen Windows Server 2016, 2019 und 2022 Systemen.
Hier kommt jetzt der Punkt, wo man sich das Klatschen der Hand gegen die Stirn vorstellen darf.
Nun, damit hat man die erste Falle kennengelernt und, wenn man nicht aufgepasst hat, die TLS 1.3 Registry-Einstellungen an alle der genannten Server-Systeme verteilt.
Der Windows Server 2019 unterstützt zum aktuellen Zeitpunkt kein TLS 1.3. Dummerweise weiß er das nicht. Und fällt böse auf die Nase, wenn man es aktiviert. Das wäre dann Falle zwei, und die ist noch deutlich unangenehmer als die erste Falle.
SChannel wertet nämlich auf Windows Server 2019 die Registry-Keys für TLS 1.3 bereits ganz brav aus! Und stellt fest, dass da jemand ein Protokoll und entsprechende Cipher nutzten möchte. Offenbar „weiß“ SChannel auch schon, dass dieses Protokoll sicherer ist und damit Verbindungen dann möglichst mit TLS 1.3 abgesichert werden sollen.
Was macht ein Server 2019 also in dem Fall? Nun, er versucht Verbindungen von und nach außen mit TLS 1.3 herzustellen, wenn die Gegenstelle es unterstützt. Obwohl er es nicht kann. Was er dann auch schnell feststellt. Das protokolliert SChannel im Eventlog und die Verbindung wird mangels fehlendem Cipher geschlossen.
Damit sendet und empfängt ein Exchange 2019 auf Server 2019 plötzlich keine Mails mehr und die lokale Exchange Control Panel Webseite ist per Edge Browser nicht mehr erreichbar.
Das Klatschen der Hand auf die Stirn wird spätestens jetzt mit einem deutlich hörbaren Stöhnen untermalt…
Die Lösung ist demnach auch wunderbar einfach: man löscht die entsprechenden Einträge via Gruppenrichtlinie wieder. Ein Neustart und schon kommuniziert der Server 2019 wieder ganz brav mit TLS 1.2 gesichert.
Und wie schränkt man nun die TLS 1.3 Einträge sauber auf Windows Server 2022 (und Windows 11) ein? Nun, vielleicht erklärt Microsoft das irgendwann ja mal.
Vermutlich löst sich das Problem irgendwann aber auch auf ganz andere Weise. Der TLS 1.3 Support soll schließlich angeblich auch für Windows Server 2019 zurück portiert werden.
Ingos Blog 
Hallo Ingo,
man könnte natürlich auch das GPO mit Hilfe einer WMI-Abfrage nur auf die Server 2022 Systeme loslassen. https://docs.microsoft.com/de-de/windows/security/threat-protection/windows-firewall/create-wmi-filters-for-the-gpo
Danke! Stimmt, das hätte ich erwähnen können. Die Version auf 10.0.2* zu begrenzen sollte die Sache dann passend ausfiltern. Mache ich tatsächlich auch an anderen Stellen so.
Bedingt allerdings eine komplett eigene GPO, nur für diese Einstellungen für Server 2022. Und ich halte es da an sich mit den Empfehlungen, so wenig GPOs wie möglich zu bauen. Ich hab hier eine „Security Servers“ GPO, die alle entsprechenden Einstellungen für alle Windows Server umfasst. Da wäre es einfach unschön, nur für TLS 1.3 Einstellungen eine komplett eigene GPO zu bauen. Ich hoffe eher drauf, dass Microsoft so langsam mal TLS 1.3 für Server 2019 (und am besten noch 2016) bringt. Dann hätte sich das halt ganz elegant gelöst.
Es ist ja auch bei W10 besser für die jeweils verwendeten Builds eigene GPOs zu verwenden, weshalb dann für W2022 nicht? Die Build oder W2022 mit in den Namen rein, schon hat man eine Übersicht. Aber ja, schön ist das nicht, schön ist anders. 😉