[English]Kurzer Hinweis für Administratoren in Unternehmensumgebung. Microsoft plant im Schannel-Protokoll die bisher standardmäßig noch verwendeten TLS 1.0 und 1.1 bald abzuschalten (beginnt im September 2023 mit Windows 11 Insider Builds). In einer Mitteilung empfiehlt das Unternehmen Administratoren zu klären, ob eine Abhängigkeit von TLS 1.0 und 1.1 besteht. Man sollte sich über bevorstehende Änderungen der Schannel-Protokollvorgaben und darüber, wie Abhängigkeiten von älteren TLS-Versionen beseitigt (oder aus Kompatibilitätsgründen aktiviert belassen) werden kann, informieren.
Anzeige
Das Ganze wird im Techcommunity-Beitrag TLS 1.0 and TLS 1.1 soon to be disabled in Windows aufgegriffen – ich bin über nachfolgenden Tweet auf das Thema gestoßen.
Transport Layer Security (TLS)
Transport Layer Security (TLS) ist das gängigste Internetprotokoll für die Einrichtung eines verschlüsselten Kommunikationskanals zwischen einem Client und einem Server. Allerdings gibt es aus historischen Gründen verschiedene Varianten. Das alte Protokoll TLS 1.0 stammt aus dem Jahr 1999, und ist nicht mehr als sicher einzustufen, da im Laufe der Zeit mehrere Sicherheitslücken in dieser Protokollversion gefunden wurden. Das neuere TLS 1.1 wurde 2006 veröffentlicht und brachte einige Sicherheitsverbesserungen mit sich. Allerdings wurde nie eine breite Akzeptanz für TLS 1.1 erreicht. Inzwischen wurden TLS 1.2 und TLS 1.3 eingeführt und sind breit im Einsatz. TLS-Implementierungen versuchen die Verbindungen mit der höchsten verfügbaren Protokollversion auszuhandeln.
In den letzten Jahren haben Internet-Standards und Regulierungsbehörden die TLS-Versionen 1.0 und 1.1 aufgrund einer Reihe von Sicherheitsproblemen als veraltet eingestuft oder nicht mehr zugelassen. Nun wird es an der Zeit, die alten Protokolle aus dem Verkehr zu ziehen.
Microsoft plant die Abschaltung
Microsoft ist der Meinung, dass die Nutzungsdaten von TLS 1.0 und 1.1 inzwischen niedrig genug sind, um zu handeln und die TLS-Versionen 1.0 und 1.1 in Kürze standardmäßig im Betriebssystem zu deaktivieren. Das beginnt im September 2023 mit den Windows 11 Insider Preview-Builds und soll dann in zukünftigen Windows-Betriebssystemversionen berücksichtigt werden. Ziel ist die Sicherheitslage von Windows-Systemen zu verbessern und die Verwendung moderner Protokolle zu fördern.
Die Auswirkungen dieser Änderung hängen weitgehend von den Windows-Anwendungen ab, die die alten TLS-Protokolle noch verwenden. TLS 1.0 und TLS 1.1 wurden bereits in den Microsoft 365-Produkten sowie in den WinHTTP- und WinINet-API-Oberflächen deaktiviert. Die meisten neueren Versionen von Anwendungen unterstützen TLS 1.2 oder höhere Protokollversionen. Anwendungen, die bei der Deaktivierung von TLS 1.0 und TLS 1.1 fehlschlagen, können durch Ereignis 36871 im Windows-Ereignisprotokoll identifiziert werden. Dort sollten dann Einträge der Art:
Beim Erstellen einer TLS <Client/Server>-Anmeldeinformation ist ein schwerwiegender Fehler aufgetreten. Der interne Fehlerstatus ist 10013. Der SSPI-Client-Prozess ist <Prozess-ID>
zu finden sein. Dann sollte geprüft werden, ob neue Versionen der Anwendung verfügbar sind, die kein TLS 1.0/1.1 mehr benötigen.
Anmerkung: Die Kollegen hier haben einige Anwendungen aufgelistet, die gesamte MS SQL-Produktpalette bis 2016 scheint betroffen. Weil es diskutiert wird, verweise ich auf diesen Supportbeitrag zum TLS 1.2 Enablement per KB3135244.
TLS 1.0/1.1 wieder zulassen
Gibt es keine entsprechende Version der Anwendung, haben Administratoren, die die Kompatibilität aufrechterhalten müssen, die Möglichkeit, TLS 1.0 oder TLS 1.1 wieder zu aktivieren. Um die Systemvorgabe außer Kraft zu setzen und eine (D)TLS- oder SSL-Protokollversion auf den Status "Aktiviert" zu setzen, erstellen Sie einen DWORD-Registrierungswert namens "Enabled" (Aktiviert) mit dem Eintragswert "1" unter dem entsprechenden versionsspezifischen Unterschlüssel. Beispiele für TLS 1.0-Unterschlüssel lauten wie folgt
Anzeige
HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Client HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.0\Server
Von Microsoft wird empfohlen, die Standardeinstellungen des Systems zu verwenden, um ein optimales Verhältnis zwischen Sicherheit und Leistung zu erreichen (der obige Registrierungseingriff ist die letzte Option). Wenn Unternehmen TLS-Cipher-Suites mithilfe von Gruppenrichtlinien oder PowerShell-Cmdlets einschränken, sollten sie auch überprüfen, ob die für TLS 1.3 und TLS 1.2 erforderlichen Cipher-Suites aktiviert sind.
Ähnliche Artikel:
WTF von Ryan Ries: Edge verwendet eigene TLS-Zertifikatsprüfungen
Übersicht: TLS-Support in Windows
Änderungen im Edge: Änderung bei TLS-Zertifikaten, kein Uninstall mehr, Server 2012/R2-Support
Windows 10: Achtung vor einem möglichen TLS-Desaster zum Oktober 2022-Patchday
Fix des SSL-/TLS-Verbindungsproblems: Stand der Sonderupdates und betroffene Anwendungen (21.10.2022)
Citrix-Verbindungen nach Windows-Update KB5018410 (Oktober 2022) gestört (TLS-Problem)
Sonderupdates für Windows fixen SSL-/TLS-Verbindungsproblem (auch bei Citrix) – 17. Oktober 2022
2015
Wird auch Zeit, das das deaktiviert wird.
TLS 1.2 wird seit Windows 7 unterstützt, selbst Office 2010 unterstützt es schon.
Aber einige Hersteller bekommen es auch 2023 noch nicht hin, das ihre Software TLS 1.2 unterstützt.
TLS 1.0 und 1.1 sind hier schon seit langer Zeit deaktiviert.
Und dann gibt es so Firmen, die Mailserver bzw. Mailgateways haben, die nur SSLv3 und TLS1.0 sprechen. Und dann meinen, wenn wir denen keine Mails schicken können (da wir nur TLS1.2 zulassen und wir denen mitgeteilt haben, was das Problem verursacht) das Problem müsse bei uns liegen. Ja ne, is klar.
Wenn es im Jahr 2023 tatsächlich noch Abhängigkeiten zu TLS 1.0 und 1.1 irgendwo gibt, sollte der verantwortliche Administrator parallel zur Auflösung solcher Abhängigkeiten ausgetauscht werden.
Drüben bei Deskmodder haben sie eine (nicht vollständige) Liste von Programmen geposted, die anscheinend noch von TLS1.0 oder 1.1 abhängig sind.
Hier mal der Auszug:
Safari – 5.1.7
SQL – 2012, 2014, 2016
SQL-Server – 2014, 2016
Turbo Tax – 2017, 2014, 2011, 2012, 2016, 2015, 2018
BlueStacks 3 – 5.10.0.6513
BlueStacks X – 0.21.0.1063
Xbox One SmartGlass – 2.2.1702.2004
K7 Enterprise Security and 4.1.0.116
Project Plan 365 – 23.8.1204.14137
Microsoft Office 2008 Professional – Accounting Express
Adguard – 6.4.1814.4903, 7.12.41.70.0
ACDSee Photo Studio – 2018, 2023
Spannend wird das ggfl. für Leute die SQL 2016 einsetzen. Der ist zwar aus dem Mainstreamsupport raus, aber eigentlich noch bis 2026 im Extended Support. Und das ACDSee ist auch interessant, da braucht ja sogar die 2023er noch die alten Protokolle, wobei ich nicht weiß wofür, da ich es nicht verwende. Gibt also anscheinend doch noch so ein paar Baustellen zu beheben, sogar bei MS selbst.
Naja, das mit dem SQL Server glaube ich so nicht.
Denn von Microsoft gibt es schon lange Anweisungen, wie man den SQL-Server fit für TLS 1.2 macht.
Selbst der uralte SQL Server 2008 ab SP4 kann schon TLS 1.2, allerdings erst nach einem Update.
Siehe:
https://support.microsoft.com/de-de/topic/kb3135244-tls-1-2-unterst%C3%BCtzung-f%C3%BCr-microsoft-sql-server-e4472ef8-90a9-13c1-e4d8-44aad198cdbe
Und was den Safari angeht:
Die Version 5 kam schon 2010 raus und 2012 dann die Version 6.
Die Version 6 gabs aber nicht mehr für Windows.
Wer nutzt denn heute noch einen 13 Jahre alten Browser?
Im Übrigen:
Schon Windows 7 und Office 2010 unterstützen TLS 1.2.
Das mit dem Browser haben sie bei Deskmodder in den Kommentaren auch angemerkt. Ansonsten habe ich die Liste nicht geprüft (ich benutze nichts von der genannten Software), sondern nur von da per Copy&Paste hier eingefügt.
Hier auch gerne der Link zu dem Artikel: TLS 1.0 und TLS 1.1 werden bald deaktiviert – Einige Programme sind noch abhängig
Das stimmt so aber vermutlich nicht:
Zitat:
erstellen Sie einen DWORD-Registrierungswert namens "Aktiviert" mit dem Eintragswert "1"
—
Tatsächlich muss dieses Registry-DWORD32 den Namen "Enabled" haben (nicht "Aktiviert"). Falls man es aktivieren möchte, was man normalerweise nicht machen sollte.
Im Normalfall sollte dort "DisabledByDefault" mit dem Wert 1 und oder "Enabled" mit dem Wert 0 stehen.
So steht es jedenfalls auf dieser Seite:
learn[.]microsoft[.]com/en-us/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs#enable-and-disable-tls-10
Auf der folgenden eingedeutschten Seite steht allerdings dreimal "Aktiviert" und einmal "Enabled" in den Tabellen an den selben Stellen, wo vorher in allen vier Fällen nur "Enabled" stand:
learn[.]microsoft[.]com/de-de/windows-server/identity/ad-fs/operations/manage-ssl-protocols-in-ad-fs#enable-and-disable-tls-10
In den Screenshots der Registry steht ebenfalls "Enabled":
learn[.]microsoft[.]com/de-de/windows-server/security/tls/tls-registry-settings?tabs=diffie-hellman#tls-dtls-and-ssl-protocol-version-settings
Ich glaube aber nicht, dass die Registry-Schlüssel eingedeutscht werden, sondern einheitlich auf englisch bleiben, unabhhängig von der jeweiligen Sprachversion des Betriebssystems.
Wurde die deutsche Hilfeseite jetzt teilweise falsch übersetzt oder kann man da tatsächlich "Aktiviert" in die Registry reinschreiben und das wird dann genauso ausgewertet, als wenn dort "Enabled" stehen würde?
Kann ich mir irgendwie nicht vorstellen, denn dann wäre es konsequent, wenn es auch für jede andere Sprache passende Übersetzungen für "Enabled" geben würde, die dann die Registry ebenso korrekt auswerten würde.
Dieser Aufwand wäre aber viel zu groß für die Programmierer der Registry bei Microsoft.
Ich bin auf jeden Fall dafür, dort "Enabled" zu benutzen, anstatt von "Aktiviert" und zusätzlich noch "DisabledByDefault".
Aus diesem Grund versuche ich eigentlich immer, Microsoft Artikel auf Englisch zu lesen. Teilweise werden die Artikel Maschinenübersetzt (steht normalerweise dabei, aber leider nicht immer), da geht mir persönlich zu viel bei verloren. Die englischen Originalartikel sind in der Regel zutreffend. Und ich bin mir relativ sicher, dass die Registry bzw. deren Schlüssel nicht länderspezifisch umbenannt sind. "Aktiviert" klingt für mich auch eher nach was, was ich in GPO suchen würde, da gibt's ja tatsächlich Übersetzungen in verschiedene Sprachen. Und bei Powershell u.ä. muss man aufpassen, wenn man irgendwas konfiguriert das Userberechtigungen abfragt oder beeinflusst. Das ist auf deutschen Systemen definitiv nicht mit englischen identisch.
Noch besser ist es, dann außerdem noch ausschließlich Server in Englich zu betreiben, zumindestens die, auf denen man die Gruppenrichtlinien bearbeitet…
Bei den Gruppenrichtlinien ist das meiner Erfahrung nach eher unspannend, da sind zwar an Manchen Ecken die Formulierungen etwas seltsam, aber das passt in der Regel. Problematischer sehe ich das eher bei Systemen, wo per Powershell oder mit Skripten gearbeitet wird. Weil am meisten weichen tatsächlich so Sachen wie Benutzernamen oder Gruppennamen (also die in-builts, die das AD bzw. Exchange von Hause aus mitbringen), da muss man halt aufpassen bzw. anpassen und kann die Vorlage von MS nicht immer 1:1 übernehmen.
Wer auf einem deutschen Windows Server die englischen Bezeichnungen in der GPO haben will, muß einfach die deutschen Sprachdateien löschen oder an einen anderen Ort verschieben.
Im Gruppenrichtlinenordner (standardmäßig C:\Windows\PolicyDefinitions) befindet sich für jede Sprache ein Unterordner und in diesem Unterordner die Sprachdateien (.adml).
Deutsch = de-DE
Englisch = en-US
Wem die Formulierungen nicht gefallen, kann die Texte auch ändern. Das sind normale .xml-Dateien.
Zu "DWORD-Registrierungswert": Du hast Recht – gerade in meinem englischen Blog-Pendant nachgeschaut – da war der Wert mit "Enabled" richtig. Asche auf mein Haupt, ist korrigiert.
Siehe auch https://skanthak.homepage.t-online.de/schannel.html — erstellt vor über 12 Jahren — mit HyperLinks zu allen relevanten MSKB-Artikeln wie https://support.microsoft.com/en-us/help/245030 "Restrict the use of certain cryptographic algorithms and protocols in Schannel.dll" und IETF RFCs wie https://www.rfc-editor.org/rfc/rfc8996.html "Deprecating TLS 1.0 and TLS 1.1"
Hat jemand von euch, der diesen Kommi ließt, zufällig als DWH auch DVS bzw. DVS Core im Einsatz? Wir hängen daran, da dort täglich neue Daten rein kommen. Ein neues, eigenes DWH wird gerade programmiert aber das dauert noch seine Zeit ..
DVS Core, ursprünglich glaube ich von State Street rausgegeben, ist auf der letzten verfügbaren Version, die allerdings aus 2009 oder so ist. Da man im Netz sowieso kaum überhaupt etwas dazu findet, gehe ich mal davon aus, das dies wohl bei TLS 1.0 stehen bleiben wird ..
Falls wer mehr weiß, gerne her damit.
Das ich das noch erleben darf…
Ich werf hier mal iiscrypto in den Raum, wer die Registrywerte nicht von Hand einstellen möchte. https://www.nartac.com/Products/IISCrypto/ .