Freigeben über

Lösen des TLS 1.0-Problems, 2. Edition

Dieses Dokument enthält die neuesten Anleitungen zum schnellen Identifizieren und Entfernen von TLS-Protokoll-Version 1.0-Abhängigkeiten in Software, die auf Microsoft-Betriebssystemen basieren, sowie Details zu Produktänderungen und neuen Features, die von Microsoft bereitgestellt werden, um Ihre eigenen Kunden und Onlinedienste zu schützen. Sie soll als Ausgangspunkt für die Erstellung eines Migrationsplans zu einer TLS 1.2+-Netzwerkumgebung verwendet werden. Während die hier beschriebenen Lösungen die Tls 1.0-Verwendung in Nicht-Microsoft-Betriebssystemen oder Kryptobibliotheken entfernen können, sind sie kein Schwerpunkt dieses Dokuments.

TLS 1.0 ist ein Sicherheitsprotokoll, das 1999 zum Einrichten von Verschlüsselungskanälen über Computernetzwerke definiert wurde. Microsoft unterstützt dieses Protokoll seit Windows XP/Server 2003. Obwohl das standardmäßige Sicherheitsprotokoll, das von modernen OSes verwendet wird, nicht mehr verwendet wird, wird TLS 1.0 weiterhin aus Gründen der Abwärtskompatibilität unterstützt. Durch die Entwicklung regulatorischer Anforderungen sowie neuer Sicherheitsrisiken in TLS 1.0 bieten Unternehmen den Anreiz, TLS 1.0 vollständig zu deaktivieren.

Microsoft empfiehlt Kunden, dieses Problem zu umgehen, indem sie TLS 1.0-Abhängigkeiten in ihren Umgebungen entfernen und TLS 1.0 nach Möglichkeit auf Betriebssystemebene deaktivieren. Angesichts der Dauer der Unterstützung von TLS 1.0 durch die Softwareindustrie wird dringend empfohlen, dass alle TLS 1.0-Deprecation-Pläne Folgendes umfassen:

  • Codeanalyse zum Suchen/Beheben hartcodierter Instanzen von TLS 1.0 oder älteren Sicherheitsprotokollen.

  • Netzwerkendpunktüberprüfung und Datenverkehrsanalyse zur Identifizierung von Betriebssystemen mithilfe von TLS 1.0 oder älteren Protokollen.

  • Vollständige Regressionstests durch den gesamten Anwendungsstapel mit deaktivierter TLS 1.0-Funktion.

  • Migration von älteren Betriebssystemen und Entwicklungsbibliotheken/Frameworks zu Versionen, die tls 1.2 standardmäßig aushandeln können.

  • Kompatibilitätstests auf allen Betriebssystemen, die von Ihrem Unternehmen verwendet werden, um Supportprobleme mit TLS 1.2 zu identifizieren.

  • Die Koordination mit Ihren Geschäftspartnern und Kunden, um sie über die Abschaffung von TLS 1.0 zu informieren.

  • Grundlegendes dazu, welche Clients möglicherweise nicht mehr mit Ihren Servern verbunden werden können, sobald TLS 1.0 deaktiviert ist.

Ziel dieses Dokuments ist es, Empfehlungen bereitzustellen, die dazu beitragen können, technische Blocker zum Deaktivieren von TLS 1.0 zu entfernen und gleichzeitig die Auswirkungen dieser Änderung auf Ihre eigenen Kunden zu erhöhen. Die Durchführung solcher Untersuchungen kann dazu beitragen, die geschäftlichen Auswirkungen der nächsten Sicherheitslücke in TLS 1.0 zu verringern. Für die Zwecke dieses Dokuments schließen Verweise auf die Abschaffung von TLS 1.0 auch TLS 1.1 ein.

Enterprise-Softwareentwickler haben eine strategische Notwendigkeit, mehr zukunftssichere und agile Lösungen (auch als Crypto Agility bezeichnet) zu übernehmen, um zukünftige Sicherheitsprotokollkompromittierungen zu bewältigen. Obwohl dieses Dokument agile Lösungen zur Beseitigung der TLS-Hardcodierung vorschlägt, liegen breitere Crypto Agility-Lösungen außerhalb des Umfangs dieses Dokuments.

Der aktuelle Status der TLS 1.0-Implementierung von Microsoft

Die TLS 1.0-Implementierung von Microsoft ist frei von bekannten Sicherheitsrisiken. Aufgrund des Potenzials für zukünftige Protokolldowngrade-Angriffe und anderer TLS 1.0-Schwachstellen, die nicht spezifisch für die Implementierung von Microsoft sind, wird empfohlen, die Abhängigkeiten von allen Sicherheitsprotokollen zu entfernen, die älter als TLS 1.2 sind (TLS 1.1/1.0/SSLv3/SSLv2).

Bei der Planung dieser Migration zu TLS 1.2+ sollten Entwickler und Systemadministratoren das Potenzial für das Hardcodieren von Protokollversionen in Anwendungen berücksichtigen, die von ihren Mitarbeitern und Partnern entwickelt wurden. Hardcoding bedeutet hier, dass die TLS-Version auf eine Veraltete und weniger sichere Version als neuere Versionen festgelegt ist. TLS-Versionen, die neuer als die hartcodierte Version sind, können nicht verwendet werden, ohne das betreffende Programm zu ändern. Diese Problemklasse kann nicht behoben werden, ohne dass Quellcodeänderungen und Die Bereitstellung von Softwareupdates vorgenommen werden. Die Protokollversions-Hardcodierung war in der Vergangenheit üblich, um Test- und Unterstützungszwecke zu unterstützen, da viele verschiedene Browser und Betriebssysteme unterschiedliche TLS-Unterstützung hatten.

Unterstützte Versionen von TLS in Windows

Viele Betriebssysteme haben veraltete TLS-Standardeinstellungen oder Begrenzungen bei der unterstützten Version, die berücksichtigt werden müssen.

Abbildung 1: Unterstützung des Sicherheitsprotokolls 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) Deaktiviert Aktiviert Aktiviert Aktiviert Aktiviert Nicht unterstützt
Windows 8.1 (WS2012 R2) Deaktiviert Aktiviert Aktiviert Aktiviert Aktiviert Nicht unterstützt
Windows 10 Deaktiviert Aktiviert Aktiviert Aktiviert Aktiviert Nicht unterstützt
Windows 11 Deaktiviert Aktiviert Aktiviert Aktiviert Aktiviert Aktiviert
Windows Server 2016 Nicht unterstützt Deaktiviert Aktiviert Aktiviert Aktiviert Nicht unterstützt
Windows Server 2016 Nicht unterstützt Deaktiviert Aktiviert Aktiviert Aktiviert Nicht unterstützt
Windows Server 2019 Nicht unterstützt Deaktiviert Aktiviert Aktiviert Aktiviert Nicht unterstützt
Windows Server 2019 GS Edition Nicht unterstützt Deaktiviert Deaktiviert Deaktiviert Aktiviert Nicht unterstützt
Windows Server 2022 Nicht unterstützt Deaktiviert Deaktiviert Deaktiviert Aktiviert Aktiviert

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

Windows Server 2022 Edition ist Microsoft SDL-kompatibel, TLS 1.2 und TLS 1.3 nur mit einer eingeschränkten Gruppe von Verschlüsselungssuiten.

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

Weitere Informationen zur Veraltetkeit von TLS 1.0/1.1 in IE/Edge finden Sie unter Modernisieren von TLS-Verbindungen in Microsoft Edge und Internet Explorer 11, Änderungen, die sich auf die Websitekompatibilität auswirken und TLS/1.0 und TLS/1.1 im neuen Edgebrowser deaktivieren

Eine schnelle Möglichkeit, um zu ermitteln, welche TLS-Version von verschiedenen Clients angefordert wird, wenn sie sich mit Ihren Onlinediensten verbinden, ist der Verweis auf die Handshake-Simulation auf Qualys SSL Labs. Diese Simulation umfasst Clientbetriebssystem-/Browserkombinationen in allen Herstellern. Ein ausführliches Beispiel für die TLS-Protokollversionen, die von verschiedenen simulierten Clientbetriebssystem-/Browserkombinationen beim Herstellen einer Verbindung mit www.microsoft.comausgehandelt wurden, finden Sie in Anhang A am Ende dieses Dokuments.

Wenn das Inventar noch nicht abgeschlossen ist, wird dringend empfohlen, ein solches für die von Ihrem Unternehmen, Ihren Kunden und Partnern verwendeten Betriebssysteme durchzuführen (bei den beiden letzteren durch Kontaktaufnahme/Kommunikation oder mindestens durch das Sammeln von HTTP-User-Agent-Strings). Dieses Inventar kann durch die Datenverkehrsanalyse an Ihrem Unternehmensnetzwerk-Edge weiter ergänzt werden. In einer solchen Situation führt die Datenverkehrsanalyse dazu, dass die TLS-Versionen erfolgreich von Kunden/Partnern ausgehandelt werden, die mit Ihren Diensten verbunden sind, aber der Datenverkehr selbst bleibt verschlüsselt.

Technische Verbesserungen von Microsoft zur Beseitigung von TLS 1.0-Abhängigkeiten

Seit der Veröffentlichung der Version 1 dieses Dokuments hat Microsoft eine Reihe von Softwareupdates und neuen Funktionen zur Unterstützung der Abschaffung von TLS 1.0 bereitgestellt. Dazu zählen:

  • Benutzerdefinierte IIS-Protokollierung zum Korrelieren von Client-IP-/Benutzer-Agent-Zeichenfolgen, Dienst-URI, TLS-Protokollversion und Verschlüsselungssuite.

    • Mit dieser Protokollierung können Administratoren schließlich die Exposition ihrer Kunden an schwache TLS quantifizieren.

  • SecureScore – Um Office 365-Mandantenadministratoren dabei zu helfen, ihre eigene schwache TLS-Nutzung zu identifizieren, wurde das SecureScore-Portal erstellt, um diese Informationen zu teilen, da der Support für TLS 1.0 in Office 365 im Oktober 2018 eingestellt wurde.

    • Dieses Portal stellt Office 365-Mandantenadministratoren die wertvollen Informationen bereit, die sie benötigen, um sich an ihre eigenen Kunden zu wenden, die möglicherweise nicht über ihre eigenen TLS 1.0-Abhängigkeiten informiert sind.

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

  • .Net Framework-Updates, um Hardcoding auf App-Ebene zu beseitigen und frameworkvererbte TLS 1.0-Abhängigkeiten zu verhindern.

  • Entwicklerleitfaden und Softwareupdates wurden veröffentlicht, um Kunden bei der Identifizierung und Beseitigung von .Net-Abhängigkeiten von schwachen TLS zu unterstützen: Bewährte Methoden für Transport Layer Security (TLS) mit .NET Framework

    • FYI: Alle Apps für .NET 4.5 oder darunter müssen wahrscheinlich geändert werden, um TLS 1.2 zu unterstützen.

  • TLS 1.2 wurde zu Windows Server 2008 SP2 und XP POSReady 2009 zurückportiert, um Kunden bei älteren Verpflichtungen zu unterstützen.

  • Anfang 2019 werden weitere Ankündigungen veröffentlicht und in nachfolgenden Aktualisierungen dieses Dokuments mitgeteilt.

Suchen und Beheben von TLS 1.0-Abhängigkeiten im Code

Für Produkte mit den vom Windows Betriebssystem bereitgestellten Kryptografiebibliotheken und Sicherheitsprotokollen sollten die folgenden Schritte dabei helfen, eine hartcodierte TLS 1.0-Verwendung in Ihren Anwendungen zu identifizieren:

  1. Identifizieren aller Instanzen von AcquireCredentialsHandle(). Dadurch erhalten Prüfer eine engere Nähe zu Codeblöcken, bei denen TLS möglicherweise hartcodiert ist.

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

  3. Legen Sie in systemeigenem Code alle Nicht-Null-Zuordnungen von grbitEnabledProtocols auf Null fest. Auf diese Weise kann das Betriebssystem seine Standard-TLS-Version verwenden.

  4. Deaktivieren Sie den FIPS-Modus, wenn er aktiviert ist, da es zu potenziellen Konflikten mit den in diesem Dokument erforderlichen Einstellungen zum expliziten Deaktivieren von TLS 1.0/1.1 kommen kann. Weitere Informationen finden Sie in Anhang B .

  5. Aktualisieren und kompilieren Sie alle Anwendungen mithilfe von WinHTTP, die auf Server 2012 oder älter gehostet werden.

    1. Verwaltete Anwendungen – neu erstellen und neuzielen auf die neueste .NET Framework-Version

    2. Anwendungen müssen Code hinzufügen, um TLS 1.2 über WinHttpSetOption zu unterstützen.

  6. Um alle Basen abzudecken, scannen Sie Quellcode- und Onlinedienstkonfigurationsdateien für die folgenden Muster, die enumerierten Typwerten entsprechen, die häufig in der TLS-Hardcodierung verwendet werden:

    1. Sicherheitsprotokolltyp

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

    3. WINHTTP_FLAG_SECURE_PROTOCOL_

    4. SP_PROT_

    5. NSStreamSocketSecurityLevel

    6. PROTOCOL_SSL oder PROTOCOL_TLS

Die empfohlene Lösung in allen oben genannten Fällen besteht darin, die Hartcodierte Protokollversionsauswahl zu entfernen und auf den Standardwert des Betriebssystems zurückzustellen. Wenn Sie DevSkim verwenden, klicken Sie hier , um Regeln zu den oben genannten Prüfungen anzuzeigen, die Sie mit Ihrem eigenen Code verwenden können.

Windows PowerShell verwendet .NET Framework 4.5, das TLS 1.2 nicht als verfügbares Protokoll enthält. Um dies zu umgehen, stehen zwei Lösungen zur Verfügung:

  1. Ändern Sie das fragliche Skript so, dass Folgendes eingeschlossen wird:

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

  2. Fügen Sie einen systemweiten Registrierungsschlüssel (z. B. über Gruppenrichtlinien) zu jedem Computer hinzu, der TLS 1.2-Verbindungen von einer .NET-App herstellen muss. Dies führt dazu, dass .NET die TLS-Versionen "Systemstandard" verwendet, die TLS 1.2 als verfügbares Protokoll hinzufügt. Außerdem können die Skripts zukünftige TLS-Versionen verwenden, wenn das Betriebssystem sie unterstützt. (z. B. 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

Lösungen (1) und (2) schließen sich gegenseitig aus, was bedeutet, dass sie nicht zusammen implementiert werden müssen.

Erstellen Sie verwaltete Anwendungen neu oder zielgerichtet mit der neuesten Version des .Net Frameworks.

Anwendungen, die .NET Framework-Versionen vor 4.7 verwenden, weisen möglicherweise Einschränkungen auf, die die Unterstützung für TLS 1.0 unabhängig von den zugrunde liegenden Betriebssystemstandarden effektiv abgrenzen. Weitere Informationen finden Sie im folgenden Diagramm und den bewährten Methoden für TLS (Transport Layer Security) mit .NET Framework .

Neuerstellen verwalteter Anwendungen

SystemDefaultTLSVersion hat Vorrang vor der Zielbestimmung auf App-Ebene von TLS-Versionen. Die empfohlene bewährte Methode besteht darin, immer auf die standardmäßige TLS-Version des Betriebssystems zurückzustellen. Es ist auch die einzige krypto-agile Lösung, mit der Ihre Apps zukünftige TLS 1.3-Unterstützung nutzen können.

Wenn Sie auf ältere Versionen von .NET Framework wie 4.5.2 oder 3.5 abzielen, verwendet Ihre Anwendung standardmäßig die älteren und nicht empfohlenen Protokolle wie SSL 3.0 oder TLS 1.0. Es wird dringend empfohlen, ein Upgrade auf neuere Versionen von .NET Framework wie .NET Framework 4.6 durchzuführen oder die entsprechenden Registrierungsschlüssel für "UseStrongCrypto" festzulegen.

Testen mit TLS 1.2+

Nach den oben empfohlenen Korrekturen sollten die Produkte einer Regressionstestprüfung hinsichtlich Protokollverhandlungsfehlern und der Kompatibilität mit anderen Betriebssystemen in Ihrem Unternehmen unterzogen werden.

  • Das häufigste Problem in diesem Regressionstest ist ein TLS-Aushandlungsfehler aufgrund eines Clientverbindungsversuchs von einem Betriebssystem oder Browser, das TLS 1.2 nicht unterstützt.

    • Beispielsweise kann ein Vista-Client TLS nicht mit einem server aushandeln, der für TLS 1.2+ konfiguriert ist, da die maximal unterstützte TLS-Version von Vista 1.0 ist. Dieser Client sollte entweder in einer TLS 1.2+-Umgebung aktualisiert oder außer Betrieb genommen werden.

  • Produkte, die die zertifikatbasierte gegenseitige TLS-Authentifizierung verwenden, erfordern möglicherweise zusätzliche Regressionstests, da der mit TLS 1.0 verknüpfte Zertifikatauswahlcode weniger ausdrucksstark war als für TLS 1.2.

    • Wenn ein Produkt MTLS mit einem Zertifikat von einem ungewöhnlichen Speicherort aushandelt (außerhalb der benannten standardmäßigen Zertifikatspeicherorte in Windows), muss der Code möglicherweise aktualisiert werden, um sicherzustellen, dass das Zertifikat ordnungsgemäß erworben wird.

  • Dienstübergreifende Abhängigkeiten sollten auf Problemstellen überprüft werden.

    • Alle Dienste, die mit Drittanbieter-Diensten zusammenarbeiten, sollten zusätzliche Interoperabilitätstests mit diesen Drittanbietern durchführen.

    • Alle nicht verwendeten Windows-Anwendungen oder Serverbetriebssysteme erfordern Untersuchung/Bestätigung, dass sie TLS 1.2 unterstützen können. Das Scannen ist die einfachste Möglichkeit, dies zu ermitteln.

Eine einfache Blaupause zum Testen dieser Änderungen in einem Onlinedienst besteht aus den folgenden Komponenten:

  1. Führen Sie eine Überprüfung von Produktionsumgebungssystemen durch, um Betriebssysteme zu identifizieren, die TLS 1.2 nicht unterstützen.

  2. Scannen Sie Quellcode- und Onlinedienstkonfigurationsdateien nach hartcodiertem TLS, wie unter "Suchen und Beheben von TLS 1.0-Abhängigkeiten im Code" beschrieben.

  3. Aktualisieren/erneutes Kompilieren von Anwendungen nach Bedarf:

    1. Verwaltete Apps

      1. Erstellen Sie erneut mit der neuesten .NET Framework-Version.

      2. Überprüfen Sie, ob die Verwendung der SSLProtocols-Enumeration auf SSLProtocols.None festgelegt ist, um die OS-Standardeinstellungen zu verwenden.

    2. WinHTTP-Apps – Neuerstellen mit WinHttpSetOption zur Unterstützung von TLS 1.2

  4. Starten Sie Tests in einer vorproduktiven oder Stagingumgebung, indem Sie alle Sicherheitsprotokolle, die älter als TLS 1.2 sind, über die Registrierung deaktivieren.

  5. Beheben Sie alle verbleibenden Instanzen der TLS-Hardcodierung, da sie beim Testen aufgetreten sind. Stellen Sie die Software erneut zur Anwendung, und führen Sie eine neue Regressionstestausführung aus.

Benachrichtigung der Partner über Ihre Pläne zur Einstellung von TLS 1.0

Nachdem das TLS-Hardcoding behoben wurde und die Betriebssystem- und Entwicklungsframework-Updates abgeschlossen sind, sollten Sie, falls Sie sich entscheiden, TLS 1.0 auszumustern, mit Kunden und Partnern koordinieren.

  • Eine frühzeitige Partner-/Kundenansprache ist für eine erfolgreiche Einführung der TLS 1.0-Abschaffung unerlässlich. Dies sollte mindestens aus Blogbeiträgen, Whitepapers oder anderen Webinhalten bestehen.

  • Partner müssen ihre jeweilige TLS 1.2-Bereitschaft durch die im obigen Abschnitt beschriebenen Betriebssystem-/Code-Scan-/Regressionstestinitiativen bewerten.

Fazit

Das Entfernen von TLS 1.0-Abhängigkeiten ist ein kompliziertes Problem, das von Anfang bis Ende durchgeführt werden muss. Microsoft und Branchenpartner ergreifen heute Maßnahmen, um sicherzustellen, dass unser gesamter Produktstapel standardmäßig sicherer ist, von unseren Betriebssystemkomponenten und Entwicklungsframeworks bis hin zu den anwendungen/Diensten, die darauf aufbauen. Wenn Sie die in diesem Dokument beschriebenen Empfehlungen befolgen, kann Ihr Unternehmen den richtigen Kurs einschlagen und wissen, mit welchen Herausforderungen es zu rechnen hat. Dies wird auch Ihren eigenen Kunden helfen, sich auf den Übergang vorzubereiten.

Anhang A: Handshake-Simulation für verschiedene Clients, die sich mit www.microsoft.com verbinden, mit freundlicher Genehmigung von SSLLabs.com

Ergebnisse der Handshake-Simulation

Anhang B: Abschaffung von TLS 1.0/1.1 und Beibehaltung des FIPS-Modus

Führen Sie die folgenden Schritte aus, wenn Ihr Netzwerk FIPS-Modus erfordert, aber Sie tls 1.0/1.1 nicht mehr verwenden möchten:

  1. Konfigurieren Sie TLS-Versionen über die Registrierung, indem Sie für die unerwünschten TLS-Versionen "Aktiviert" auf Null festlegen.

  2. Deaktivieren Sie Curve 25519 (nur Server 2016) über Gruppenrichtlinien.

  3. Deaktivieren Sie alle Cipher-Suites mit Algorithmen, die in der relevanten FIPS-Publikation nicht erlaubt sind. Für Server 2016 (vorausgesetzt, die Standardeinstellungen sind in Kraft) bedeutet dies, RC4-, PSK- und NULL-Verschlüsselungen zu deaktivieren.

Mitwirkende/Danke

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

  • Last updated on