Teilen über

Beheben des Problems mit TLS 1.0, zweite Ausgabe

  • Artikel

Dieses Dokument enthält die neuesten Informationen zur schnellen Identifizierung und Entfernung von Abhängigkeiten im Zusammenhang mit der TLS-Protokollversion 1.0 (Transport Layer Security) in auf Microsoft-Betriebssystemen basierender Software, gefolgt von Details zu Produktänderungen und neuen Features, die von Microsoft zum Schutz Ihrer Kunden und Onlinedienste bereitgestellt werden. Es ermöglicht die Entwicklung eines Plans für die Migration zu einer Netzwerkumgebung mit TLS 1.2 und höheren Versionen. Die hier erläuterten Lösungen können ggf. auch verwendet werden, um TLS 1.0 aus Microsoft-fremden Betriebssystemen oder Kryptografiebibliotheken zu entfernen, dies ist jedoch kein zentraler Aspekt des Dokuments.

TLS 1.0 ist ein Sicherheitsprotokoll, das erstmal 1999 definiert wurde, um Verschlüsselungskanäle über Computernetzwerke einzurichten. Von Microsoft wurde dieses Protokoll seit Windows XP/Server 2003 unterstützt. TLS 1.0 wird in modernen Betriebssystemen zwar nicht mehr als Standardsicherheitsprotokoll verwendet, aus Gründen der Abwärtskompatibilität aber weiterhin unterstützt. Aufgrund von veränderten gesetzlichen Anforderungen sowie neuen Sicherheitsrisiken in TLS 1.0 ist es für Unternehmen sinnvoll, TLS 1.0 vollständig zu deaktivieren.

Microsoft empfiehlt Kunden, dieses Problem proaktiv anzugehen, indem sie TLS 1.0-Abhängigkeiten aus ihren Umgebungen entfernen und TLS 1.0 auf der Betriebssystemebene deaktivieren, sofern möglich. Angesichts der langjährigen Unterstützung von TLS 1.0 durch die Softwarebranche sollte jeder Plan zur Einstellung von TLS 1.0 unbedingt Folgendes umfassen:

  • Codeanalyse zur Ermittlung/Behandlung hartcodierter Vorkommen von TLS 1.0 oder älterer Sicherheitsprotokolle

  • Überprüfung von Netzwerkendpunkten sowie Datenverkehrsanalyse zur Erkennung von Betriebssystemen mit TLS 1.0 oder älteren Protokollen

  • Umfassende Regressionstests für Ihren gesamten Anwendungsstapel mit deaktiviertem TLS 1.0

  • Migration älterer Betriebssysteme und Entwicklungsbibliotheken/-frameworks zu Versionen mit standardmäßiger TLS 1.2-Aushandlung

  • Übergreifende Kompatibilitätstests für Betriebssysteme, die von Ihrem Unternehmen verwendet werden, um Probleme im Zusammenhang mit der TLS 1.2-Unterstützung zu identifizieren

  • Abstimmung mit Ihren Geschäftspartnern und Kunden, um sie über die Einstellung von TLS 1.0 zu informieren

  • Ermittlung der Clients, die nach der Deaktivierung von TLS 1.0 möglicherweise keine Verbindung mit Ihren Servern mehr herstellen können

Dieses Dokument enthält Empfehlungen, die Ihnen dabei helfen, technische Hürden im Zusammenhang mit der Deaktivierung von TLS 1.0 zu beseitigen und gleichzeitig die Auswirkungen dieser Änderung auf Ihre eigenen Kunden besser zu verstehen. Die entsprechenden Untersuchungen tragen dazu bei, die geschäftlichen Auswirkungen des nächsten Sicherheitsrisikos in TLS 1.0 zu verringern. Im Kontext dieses Dokuments schließt die Einstellung von TLS 1.0 auch die Einstellung von TLS 1.1 mit ein.

Entwickler von Unternehmenssoftware sind aus strategischen Gründen darum bemüht, zukunftssicherere und flexiblere Lösungen (Stichwort: kryptografische Flexibilität) einzuführen, um für zukünftige Kompromittierungen von Sicherheitsprotokollen gewappnet zu sein. In diesem Dokument werden zwar flexible Lösungen für die Beseitigung der TLS-Hartcodierung vorgeschlagen, auf Lösungen mit weitergehender kryptografischer Flexibilität wird jedoch nicht eingegangen.

Der aktuelle Stand der TLS 1.0-Implementierung von Microsoft

Die TLS 1.0-Implementierung von Microsoft weist keine bekannten Sicherheitsrisiken auf. Aufgrund der Gefahr zukünftiger Protokollherabstufungsangriffe und anderer Sicherheitsrisiken von TLS 1.0, die nicht speziell mit der Implementierung von Microsoft zusammenhängen, empfiehlt es sich, Abhängigkeiten von allen Sicherheitsprotokollen vor TLS 1.2 (TLS 1.1/1.0/SSLv3/SSLv2) nach Möglichkeit zu entfernen.

Im Zuge der Planung dieser Migration zu TLS 1.2 und höheren Versionen müssen sich Entwickler und Systemadministratoren bewusst sein, dass die Protokollversion möglicherweise in von Mitarbeitern und Partnern entwickelten Anwendungen hartcodiert wurde. „Hartcodiert“ bedeutet in diesem Zusammenhang, dass die TLS-Version auf eine veraltete und im Vergleich zu neueren Versionen unsicherere Version festgelegt wurde. Neuere TLS-Versionen als die hartcodierte Version können nicht ohne Änderung des betreffenden Programms verwendet werden. Dieses Problem erfordert Quellcodeänderungen und die Bereitstellung von Softwareupdates. Das Hartcodieren der Protokollversion wurde in der Vergangenheit häufig zu Test- und Unterstützungszwecken verwendet, da die TLS in vielen Browsern und Betriebssystemen unterschiedlich unterstützt wurde.

Unterstützte Versionen von TLS in Windows

Viele Betriebssysteme verfügen über veraltete Standardwerte für die TLS-Version oder über Obergrenzen, die berücksichtigt werden müssen.

Abbildung 1: Unterstützung von Sicherheitsprotokollen nach Betriebssystemversion

Windows-Betriebssystem SSLv2 SSLv3 TLS 1.0 TLS 1.1 TLS 1.2 TLS 1.3
Windows Vista Aktiviert Aktiviert Aktiviert Nicht unterstützt Nicht unterstützt Nicht unterstützt
Windows Server 2008 Aktiviert Aktiviert Aktiviert Deaktiviert* Deaktiviert* Nicht unterstützt
Windows 7 (WS2008 R2) Aktiviert Aktiviert Aktiviert Deaktiviert* Deaktiviert* Nicht unterstützt
Windows 8 (WS2012) Disabled Aktiviert Aktiviert Aktiviert Aktiviert Nicht unterstützt
Windows 8.1 (WS2012 R2) Disabled Aktiviert Aktiviert Aktiviert Aktiviert Nicht unterstützt
Windows 10 Disabled Aktiviert Aktiviert Aktiviert Aktiviert Nicht unterstützt
Windows 11 Disabled Aktiviert Aktiviert Aktiviert Aktiviert Aktiviert
Windows Server 2016 Nicht unterstützt Disabled Aktiviert Aktiviert Aktiviert Nicht unterstützt
Windows Server 2016 Nicht unterstützt Disabled Aktiviert Aktiviert Aktiviert Nicht unterstützt
Windows Server 2019 Nicht unterstützt Disabled Aktiviert Aktiviert Aktiviert Nicht unterstützt
Windows Server 2019-GS-Edition Nicht unterstützt Disabled Disabled Disabled Aktiviert Nicht unterstützt
Windows Server 2022 Nicht unterstützt Disabled Disabled Disabled Aktiviert Aktiviert

Windows Server 2019-GS-Edition ist Microsoft-SDL-konform, nur TLS 1.2 mit einer eingeschränkten Anzahl von Sammlungen von Verschlüsselungsverfahren.

Windows Server 2022-Edition ist Microsoft-SDL-konform, nur TLS 1.2 und TLS 1.3 mit einer eingeschränkten Anzahl von Sammlungen von Verschlüsselungsverfahren.

TLS 1.1/1.2 kann unter Windows Server 2008 über dieses optionale Windows Update-Paket aktiviert werden.

Weitere Informationen zur Einstellung von TLS 1.0/1.1 in Internet Explorer/Edge finden Sie unter Modernisieren von TLS-Verbindungen in Microsoft Edge und Internet Explorer 11, Anstehende Änderungen mit Auswirkungen auf die Websitekompatibilität für Microsoft Edge und Deaktivieren von TLS 1.0 und TLS 1.1 im neuen Edge-Browser.

Mithilfe der Handshake-Simulation unter Qualys SSL Labs lässt sich schnell ermitteln, welche TLS-Version von verschiedenen Clients beim Herstellen einer Verbindung mit Ihren Onlinedienste angefordert wird. Diese Simulation umfasst herstellerübergreifende Kombinationen aus Clientbetriebssystem und Browser. Ein ausführliches Beispiel zur Veranschaulichung der TLS-Protokollversionen, die bei der Verbindungsherstellung mit www.microsoft.com von verschiedenen simulierten Kombinationen aus Clientbetriebssystem und Browser angefordert werden, finden Sie am Ende dieses Dokuments im Anhang A.

Es wird dringend empfohlen, eine Inventur der Betriebssysteme durchzuführen, die von Ihrem Unternehmen, von Ihren Kunden und von Ihren Partnern verwendet werden. (Bei den Kunden/Partnern kann hierzu eine entsprechende Anfrage/Kommunikation oder zumindest eine HTTP-Benutzer-Agent-Zeichenfolgensammlung verwendet werden.) Diese Inventur kann durch eine Datenverkehrsanalyse am Edge Ihres Unternehmensnetzwerks ergänzt werden. In einem solchen Fall liefert die Datenverkehrsanalyse die TLS-Versionen, die bei der Verbindungsherstellung mit Ihren Diensten erfolgreich von Kunden/Partnern ausgehandelt wurden, der Datenverkehr selbst bleibt jedoch verschlüsselt.

Entwicklungsverbesserungen von Microsoft für die Beseitigung von TLS 1.0-Abhängigkeiten

Seit der ersten Version dieses Dokuments hat Microsoft eine Reihe von Softwareupdates und neuen Features zur Unterstützung der Einstellung von TLS 1.0 bereitgestellt. Dazu gehören:

  • Benutzerdefinierte IIS-Protokollierung zur Korrelierung von Client-IP-Adresse/Benutzer-Agent-Zeichenfolge, Dienst-URI, TLS-Protokollversion und Verschlüsselungssammlung.

    • Mit dieser Protokollierung können Administratoren nun quantifizieren, wie stark ihre Kunden unsicherer TLS ausgesetzt sind.

  • SecureScore: Um Office 365-Mandantenadministratoren bei der Identifizierung der eigenen unsicheren TLS-Nutzung zu unterstützen, wurde das SecureScore-Portal zur Bereitstellung dieser Informationen eingerichtet, nachdem die Unterstützung von TLS 1.0 in Office 365 im Oktober 2018 eingestellt wurde.

    • In diesem Portal erhalten Office 365-Mandantenadministratoren wichtige Informationen, um ihre eigenen Kunden zu informieren, die sich ihrer TLS 1.0-Abhängigkeiten möglicherweise nicht bewusst sind.

    • Weitere Informationen erhalten Sie unter https://securescore.microsoft.com/.

  • .NET Framework-Updates, um Hartcodierungen auf der App-Ebene zu beseitigen und vom Framework geerbte TLS 1.0-Abhängigkeiten zu verhindern.

  • Entwickleranleitungen und Software-Updates wurden veröffentlicht, um Kunden bei der Identifizierung und Beseitigung von .Net-Abhängigkeiten bei schwachen TLS zu unterstützen: Best Practices der Transport Layer Security (TLS) mit dem .NET Framework

    • Zur Information: Alle Anwendungen, die für .NET 4.5 oder niedriger konzipiert sind, müssen wahrscheinlich modifiziert werden, um TLS 1.2 zu unterstützen.

  • TLS 1.2 wurde für Windows Server 2008 SP2 und XP POSReady 2009 zurückportiert, um Kunden mit Legacyverpflichtungen zu unterstützen.

  • Weitere Ankündigungen folgen Anfang 2019 und werden in späteren Aktualisierungen dieses Dokuments kommuniziert.

Ermitteln und Behandeln von TLS 1.0-Abhängigkeiten im Code

Bei Produkten, die die vom Windows-Betriebssystem bereitgestellten Kryptografiebibliotheken und Sicherheitsprotokolle verwenden, können Hartcodierungen von TLS 1.0 in Ihren Anwendungen wie folgt ermittelt werden:

  1. Ermitteln Sie alle Instanzen von „AcquireCredentialsHandle()“. Dadurch können sich Prüfer den Codeblöcken annähern, in denen die TLS möglicherweise hartcodiert wurde.

  2. Überprüfen Sie alle Instanzen der Strukturen SecPkgContext_SupportedProtocols und SecPkgContext_ConnectionInfo für hartcodiertes TLS.

  3. Legen Sie in nativem Code alle Zuweisungen von grbitEnabledProtocols, die nicht Null sind, auf Null fest. Dadurch kann vom Betriebssystem die jeweilige TLS-Standardversion verwendet werden.

  4. Deaktivieren Sie den FIPS-Modus (sofern aktiviert), um mögliche Konflikte mit Einstellungen aus diesem Dokument zu vermeiden, die zur expliziten Deaktivierung von TLS 1.0/1.1 erforderlich sind. Weitere Informationen finden Sie im Anhang B.

  5. Aktualisieren Sie alle Anwendungen, die WinHTTP (gehostet unter Server 2012 oder einer älteren Version) verwenden, und kompilieren Sie sie erneut.

    1. Erstellen Sie verwaltete Apps neu, und richten Sie sie auf die aktuellen .NET Framework-Version aus.

    2. Anwendungen muss Code zur Unterstützung von TLS 1.2 per WinHttpSetOption hinzugefügt werden.

  6. Überprüfen Sie den Quellcode sowie Online-Dienstkonfigurationsdateien auf die folgenden Muster, um nichts zu übersehen. Hierbei handelt es sich um Aufzählungstypwerte, die in der Regel beim Hartcodieren der TLS verwendet werden:

    1. SecurityProtocolType

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

    3. WINHTTP_FLAG_SECURE_PROTOCOL_

    4. SP_PROT_

    5. NSStreamSocketSecurityLevel

    6. PROTOCOL_SSL or PROTOCOL_TLS

In den oben angegebenen Fällen empfiehlt es sich jeweils, die hartcodierte Protokollversion zu entfernen und die Standardeinstellung des Betriebssystems zu verwenden. Falls Sie DevSkim verwenden, klicken Sie hier, um Regeln für die obigen Überprüfungen anzuzeigen, die Sie mit Ihrem eigenen Code verwenden können.

Von Windows PowerShell wird .NET Framework 4.5 verwendet, TLS 1.2 ist in .NET Framework 4.5 aber nicht als verfügbares Protokoll enthalten. Dieses Problem lässt sich auf zwei Arten umgehen:

  1. Fügen Sie dem betreffenden Skript Folgendes hinzu: 

    [System.Net.ServicePointManager]::SecurityProtocol = [System.Net.SecurityProtocolType]::Tls12;

  2. Fügen Sie jedem Computer, auf dem TLS 1.2-Verbindungen über eine .NET-App hergestellt werden müssen, einen systemweiten Registrierungsschlüssel hinzu (beispielsweise per Gruppenrichtlinie). Dies führt dazu, dass von .NET die TLS-Standardversionen des Systems verwendet werden und dass TLS 1.2 als verfügbares Protokoll hinzufügt wird. Außerdem können von den Skripts zukünftige TLS-Versionen verwendet werden, wenn diese vom Betriebssystem unterstützt werden. (beispielsweise 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

Die beiden Lösungen schließen sich gegenseitig aus. Sie müssen also nicht gemeinsam implementiert werden.

Erneutes Erstellen/Ändern der Ausrichtung verwalteter Anwendungen unter Verwendung der aktuellen .NET Framework-Version

Anwendungen, von denen .NET Framework-Versionen vor 4.7 verwendet werden, unterliegen möglicherweise Einschränkungen, die dazu führen, dass unabhängig von den zugrunde liegenden Standardwerten des Betriebssystems maximal TLS 1.0 unterstützt werden kann. Weitere Informationen finden Sie im folgenden Diagramm und in Bewährte Methoden für Transport Layer Security (TLS) mit .NET Framework.

Neuerstellen verwalteter Anwendungen

„SystemDefaultTLSVersion“ hat Vorrang vor der TLS-Versionsausrichtung auf der App-Ebene. Es empfiehlt sich, immer die TLS-Standardversion des Betriebssystems zu verwenden. Hierbei handelt es sich auch um die einzige kryptografisch flexible Lösung, bei der Ihre Apps von einer zukünftigen TLS 1.3-Unterstützung profitieren können.

Wenn Ihre Anwendung auf ältere Versionen von .NET Framework wie 4.5.2 oder 3.5 ausgelegt ist, dann verwendet sie standardmäßig die älteren und nicht empfohlenen Protokolle wie SSL 3.0 oder TLS 1.0. Es wird dringend empfohlen, auf neuere Versionen von .NET Framework wie .NET Framework 4.6 zu aktualisieren oder die entsprechenden Registrierungsschlüssel auf „UseStrongCrypto“ festzulegen.

Testen mit TLS 1.2 und höheren Versionen

Im Anschluss an die empfohlenen Maßnahmen aus dem obigen Abschnitt müssen Regressionstests für die Produkte durchgeführt werden, um sie auf mögliche Protokollaushandlungsfehler zu überprüfen und die Kompatibilität mit anderen Betriebssystemen in Ihrem Unternehmen zu testen.

  • Das häufigste Problem bei diesen Regressionstests ist ein TLS-Aushandlungsfehler aufgrund eines Clientverbindungsversuchs von einem Betriebssystem oder Browser ohne TLS 1.2-Unterstützung.

    • So kann beispielsweise von einem Vista-Client keine TLS mit einem Server ausgehandelt werden, der für TLS 1.2 oder eine höhere Version konfiguriert ist, da von Vista maximal die TLS-Version 1.0 unterstützt wird. Dieser Client muss in einer Umgebung mit TLS 1.2 oder einer höheren Version entweder aktualisiert oder außer Betrieb gesetzt werden.

  • Für Produkte mit zertifikatbasierter gegenseitiger TLS-Authentifizierung sind ggf. zusätzliche Regressionstests erforderlich, da der mit TLS 1.0 verknüpfte Zertifikatauswahlcode weniger ausdrucksstark war als der Code für TLS 1.2.

    • Wenn ein Produkt MTLS mit einem Zertifikat von einem nicht standardmäßigen Speicherort (außerhalb der standardmäßigen benannten Zertifikatspeicher in Windows) aushandelt, muss dieser Code ggf. aktualisiert werden, um sicherzustellen, dass das Zertifikat ordnungsgemäß abgerufen wird.

  • Gegenseitige Dienstabhängigkeiten müssen auf potenzielle Probleme überprüft werden.

    • Für Dienste, die mit Drittanbieterdiensten zusammenarbeiten, muss zusätzlich die Zusammenarbeit mit diesen Drittanbietern getestet werden.

    • Für alle Windows-fremden Anwendungen und Serverbetriebssysteme muss die Unterstützung von TLS 1.2 untersucht/bestätigt werden. Dies lässt sich am einfachsten durch einen Scan ermitteln.

Eine einfache Blaupause zum Testen dieser Änderungen in einem Onlinedienst umfasst Folgendes:

  1. Überprüfen der Systeme der Produktionsumgebung, um Betriebssysteme ohne TLS 1.2-Unterstützung zu ermitteln

  2. Überprüfen des Quellcodes und der Online-Dienstkonfigurationsdateien auf hartcodierte TLS, wie unter Ermitteln und Behandeln von TLS 1.0-Abhängigkeiten im Code beschrieben

  3. Aktualisieren/Neukompilieren von Anwendungen nach Bedarf:

    1. Verwaltete Apps

      1. Neuerstellen für die aktuelle .NET Framework-Version

      2. Vergewissern, dass Vorkommen der Enumeration SSLProtocols auf „SSLProtocols.None“ festgelegt sind, um die Standardeinstellungen des Betriebssystems zu verwenden

    2. Neuerstellen von WinHTTP-Apps mit WinHttpSetOption, um TLS 1.2 zu unterstützen

  4. Starten der Tests in einer Präproduktions- oder Stagingumgebung, in der alle Sicherheitsprotokolle vor TLS 1.2 per Registrierung deaktiviert wurden

  5. Behandeln der restlichen TLS-Hartcodierungen, die beim Testen gefunden werden Erneutes Bereitstellen der Software und Durchführen eines neuen Regressionstestlaufs

Informieren von Partnern über Ihre Einstellungspläne für TLS 1.0

Wenn Sie sich nach der Behandlung der TLS-Hartcodierungen und der Durchführung der Betriebssystem-/Entwicklungsframeworkupdates für die Einstellung von TLS 1.0 entscheiden, müssen Sie sich mit Kunden und Partnern abstimmen:

  • Eine frühzeitige Kontaktaufnahme mit Partnern/Kunden ist für den Erfolg der Einstellung von TLS 1.0 von entscheidender Bedeutung. Diese muss mindestens Blogbeiträge, Whitepaper oder andere Webinhalte umfassen.

  • Partner müssen mithilfe der Initiativen für Betriebssystem/Codeüberprüfung/Regressionstests aus den obigen Abschnitten jeweils ihre eigene Bereitschaft für TLS 1.2 untersuchen.

Zusammenfassung

Die umfassende Entfernung von TLS 1.0-Abhängigkeiten ist ein kompliziertes Unterfangen. Microsoft und Branchenpartner werden schon heute aktiv, um die standardmäßige Sicherheit unseres gesamten Produktstapels zu gewährleisten – von den Betriebssystemkomponenten und Entwicklungsframeworks bis hin zu den darauf basierenden Anwendungen und Diensten. Durch die Umsetzung der Empfehlungen in diesem Dokument können Sie sicherstellen, dass Ihr Unternehmen den richtigen Kurs einschlägt und auf die zu erwartenden Herausforderungen vorbereitet ist. Außerdem können Sie so Ihren Kunden bei der Vorbereitung auf die Umstellung helfen.

Anhang A: Handshake-Simulation für verschiedene Clients, die eine Verbindung zu www.microsoft.com herstellen, SSLLabs.com

Ergebnisse der Handshake-Simulation

Anhang B: Einstellen von TLS 1.0/1.1 unter Beibehaltung des FIPS-Modus

Führen Sie die folgenden Schritte aus, wenn Sie TLS 1.0/1.1 einstellen möchten und Ihr Netzwerk den FIPS-Modus benötigt:

  1. Konfigurieren Sie TLS-Versionen per Registrierung, indem Sie „Aktiviert“ für die unerwünschten TLS-Versionen auf „0“ festlegen.

  2. Deaktivieren Sie Curve 25519 (nur Server 2016) per Gruppenrichtlinie.

  3. Deaktivieren Sie alle Verschlüsselungssammlungen, die Algorithmen verwenden, die für die entsprechende FIPS-Veröffentlichung nicht zulässig sind. Für Server 2016 müssen bei Verwendung der Standardeinstellungen die Verschlüsselungen RC4, PSK und NULL deaktiviert werden.

Mitwirkende/Danksagungen

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