Bewährte Methoden für Transport Layer Security (TLS) mit .NET Framework

Das TLS-Protokoll (Transport Layer Security) ist ein Industriestandard zum Schutz von Daten, die über das Internet übertragen werden. TLS 1.2 ist ein Standard, der Sicherheitsverbesserungen gegenüber früheren Versionen umfasst. TLS 1.2 wird schließlich durch den neuesten freigegebenen Standard TLS 1.3 ersetzt, der schneller ist und eine erhöhte Sicherheit bietet. Dieser Artikel enthält Empfehlungen zur Sicherung von .NET Framework-Anwendungen, die das TLS-Protokoll verwenden.

Um die Sicherheit von .NET Framework-Anwendungen zu gewährleisten, sollte die TLS-Version nicht hartcodiert sein. .NET Framework-Anwendungen sollten die vom Betriebssystem unterstützte TLS-Version verwenden.

Dieses Dokument richtet sich an Entwickler, für die Folgendes zutrifft:

Beachten Sie die folgenden Empfehlungen:

  • Verwenden Sie für TLS 1.2 mindestens .NET Framework 4.7 als Ziel für Ihre Apps und mindestens .NET Framework 4.7.1 als Ziel für Ihre WCF-Apps.
  • Verwenden Sie für TLS 1.3 mindestens .NET Framework 4.8 als Ziel.
  • Geben Sie keine TLS-Version an. Konfigurieren Sie Ihren Code so, dass das Betriebssystem über die TLS-Version entscheidet.
  • Führen Sie eine gründliche Codeüberprüfung durch, um sicherzustellen, dass Sie keine TLS- oder SSL-Version festlegen.

Wenn die TLS-Version in Ihrer App vom Betriebssystem gewählt wird:

  • Werden automatisch neue Protokolle genutzt, die in Zukunft hinzugefügt werden, wie z.B. TLS 1.3.
  • Blockiert das Betriebssystem Protokolle, die als nicht sicher erkannt werden.

Der Abschnitt Überprüfen Ihres Codes und vornehmen von Codeänderungen unterstützt Sie dabei, Ihren Code zu überprüfen und zu aktualisieren.

Dieser Artikel erklärt, wie Sie die höchste Sicherheit für die Version des .NET-Frameworks erreichen, auf die Ihre App abzielt und unter der sie ausgeführt wird. Wenn ein Sicherheitsprotokoll und eine Sicherheitsversion von einer App explizit festlegt werden, sind somit jede andere Alternative und das Standardverhalten von .NET Framework und dem Betriebssystem ausgeschlossen. Wenn Sie möchten, dass Ihre App eine TLS 1.2-Verbindung aushandeln kann, wird dies durch das explizite Festlegen auf eine niedrigere Version als TLS 1.2 verhindert.

Sollte sich die Hartcodierung einer Protokollversion nicht vermeiden lassen, wird dringend empfohlen, TLS 1.2 festzulegen. Eine Anleitung zum Identifizieren und Entfernen von TLS 1.0-Abhängigkeiten finden Sie im Whitepaper Solving the TLS 1.0 Problem (Lösung des TLS 1.0-Problems), das als Download verfügbar ist.

WCF unterstützt TLS 1.0, 1.1 und 1.2 als Standard in .NET Framework 4.7. Ab .NET Framework 4.7.1 verwendet WCF standardmäßig die vom Betriebssystem konfigurierte Version. Wenn eine Anwendung explizit mit SslProtocols.None konfiguriert ist, verwendet WCF die Standardeinstellung des Betriebssystems für den NetTcp-Transport.

Fragen zu diesem Dokument können Sie im GitHub-Thema Transport Layer Security (TLS) best practices with the .NET Framework (Bewährte Methoden für TLS mit .NET Framework) stellen.

Überprüfen Ihres Codes und vornehmen von Codeänderungen

Für ASP.NET-Anwendungen überprüfen Sie das Element <system.web><httpRuntime targetFramework> von web.config, um sicherzustellen, dass Sie die beabsichtigte Version von .NET Framework verwenden.

Für Windows Forms und andere Anwendungen lesen Sie Vorgehensweise: Erstellen von Projekten für eine bestimmte .NET Framework-Version.

Verwenden Sie die folgenden Abschnitte, um sicherzustellen, dass Sie keine bestimmte TLS- oder SSL-Version verwenden.

Wenn Ihre App auf .NET Framework 4.7 oder höhere Versionen abzielt

Die folgenden Abschnitte zeigen, wie Sie sicherstellen können, dass Sie keine bestimmte TLS- oder SSL-Version verwenden.

Für HTTP-Netzwerke

Bei Verwendung von .NET Framework 4.7 und höheren Versionen nutzt ServicePointManager das Standardsicherheitsprotokoll, das im Betriebssystem konfiguriert ist. Damit die Standardauswahl des Betriebssystems übernommen wird, sofern möglich, legen Sie keinen Wert für die ServicePointManager.SecurityProtocol-Eigenschaft fest. Diese ist standardmäßig auf SecurityProtocolType.SystemDefault festgelegt.

Da die Einstellung für SecurityProtocolType.SystemDefault bewirkt, dass ServicePointManager das vom Betriebssystem konfigurierte Standardsicherheitsprotokoll verwendet, wird Ihre Anwendung je nach Betriebssystem möglicherweise etwas anders ausgeführt. Ein Beispiel: Windows 7 SP1 verwendet TLS 1.0, während Windows 8 und Windows 10 TLS 1.2 nutzen.

Der Rest dieses Artikels ist nicht relevant, wenn .NET Framework 4.7 oder höhere Versionen für HTTP-Netzwerke verwendet werden sollen.

Für TCP-Socketnetzwerke

SslStream wird bei Verwendung von .NET Framework 4.7 oder höheren Versionen standardmäßig auf die Vorgabe des Betriebssystems gesetzt, welches das beste Sicherheitsprotokoll und die beste Version auswählt. Damit standardmäßig die beste Wahl des Betriebssystems übernommen wird, verwenden Sie möglichst nicht die Methodenüberladungen von SslStream, die einen expliziten SslProtocols-Parameter übernehmen. Andernfalls übergeben Sie SslProtocols.None. Die Verwendung von Default wird nicht empfohlen. Durch die Einstellung SslProtocols.Default wird die Verwendung von SSL 3.0/TLS 1.0 erzwungen und TLS 1.2 nicht genutzt.

Legen Sie (bei HTTP-Netzwerken) keinen Wert für die SecurityProtocol-Eigenschaft fest.

Verwenden Sie (bei TCP-Socketnetzwerken) keine Methodenüberladungen von SslStream, die einen expliziten SslProtocols-Parameter übernehmen. Wenn Sie Ihre App erneut auf .NET Framework 4.7 oder höhere Versionen ausrichten, folgen Sie der Empfehlung in den bewährten Methoden.

Der Rest dieses Themas ist nicht relevant, wenn es um .NET Framework 4.7 oder höhere Versionen für TCP-Socketnetzwerke geht.

Für WCF-TCP-Transport unter Berücksichtigung der Transportsicherheit mit Zertifikatanmeldeinformationen

WCF verwendet den gleichen Netzwerkstack wie der Rest des .NET Frameworks.

Wenn Sie auf 4.7.1 abzielen, ist WCF so konfiguriert, dass das Betriebssystem standardmäßig das beste Sicherheitsprotokoll auswählen kann, sofern es nicht explizit an einem der folgenden Orte festgelegt ist:

  • In der Konfigurationsdatei Ihrer Anwendung
  • Oder, im Quellcode Ihrer Anwendung

.NET Framework 4.7 und höhere Versionen sind standardmäßig für die Verwendung von TLS 1.2 konfiguriert und erlauben Verbindungen mit TLS 1.1 oder TLS 1.0. Konfigurieren Sie WCF, damit das Betriebssystem das beste Sicherheitsprotokoll auswählen kann, indem Sie für Ihre Bindung die Verwendung von SslProtocols.None festlegen. Dies kann auf SslProtocols festgelegt werden. SslProtocols.None kann von Transport aus aufgerufen werden. NetTcpSecurity.Transport kann von Security aus aufgerufen werden.

Bei Verwendung einer benutzerdefinierten Bindung:

  • Konfigurieren Sie WCF, damit das Betriebssystem das beste Sicherheitsprotokoll auswählen kann, indem Sie für SslProtocols.None die Verwendung von SslProtocols festlegen.
  • Oder konfigurieren Sie das Protokoll, das mit dem Konfigurationspfad system.serviceModel/bindings/customBinding/binding/sslStreamSecurity:sslProtocols verwendet wird.

Wenn Sie keine benutzerdefinierte Bindung verwenden und Ihre WCF-Bindung über die Konfiguration einstellen, legen Sie das verwendete Protokoll mit dem Konfigurationspfad system.serviceModel/bindings/netTcpBinding/binding/security/transport:sslProtocols fest.

Für WCF-Nachrichtensicherheit mit Zertifikatanmeldeinformationen

.NET Framework 4.7 und höhere Versionen verwenden standardmäßig das in der SecurityProtocol-Eigenschaft angegebene Protokoll. Wenn der AppContextSwitch auf true"AppContextSwitchSwitch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols" festgelegt ist, wählt WCF das beste Protokoll bis zu TLS 1.0 aus.

Wenn Ihre App auf eine höhere .NET Framework-Version als 4.7 abzielt

Überprüfen Sie Ihren Code, um sicherzustellen, dass Sie keine bestimmte TLS- oder SSL-Version verwenden, wie in den folgenden Abschnitten beschrieben:

Für .NET Framework 4.6 bis 4.6.2 und ohne WCF

Setzen Sie die DontEnableSystemDefaultTlsVersionsAppContext-Option auf false. Siehe Konfigurieren der Sicherheit über AppContext-Switches.

Für WCF mit .NET Framework 4.6 bis 4.6.2 unter Berücksichtigung der Transportsicherheit mit Zertifikatanmeldeinformationen

Sie müssen die neuesten Betriebssystempatches installieren. Siehe Sicherheitsupdates.

Das WCF-Framework wählt automatisch das höchste bis TLS 1.2 verfügbare Protokoll, es sei denn, Sie konfigurieren explizit eine Protokollversion. Weitere Informationen finden Sie im vorhergehenden Abschnitt Für WCF-TCP-Transport unter Berücksichtigung der Transportsicherheit mit Zertifikatanmeldeinformationen.

Für .NET Framework 3.5 bis 4.5.2 und ohne WCF

Es wird empfohlen, ein Upgrade Ihrer App auf .NET Framework 4.7 oder höher auszuführen. Wenn Sie kein Upgrade ausführen können, gehen Sie wie folgt vor.

Setzen Sie die Registrierungsschlüssel SchUseStrongCrypto und SystemDefaultTlsVersions auf 1. Siehe Konfigurieren der Sicherheit über die Windows-Registrierung. Die .NET Framework-Version 3.5 unterstützt das Flag SchUseStrongCrypto nur, wenn ein expliziter TLS-Wert übergeben wird.

Wenn Sie .NET Framework 3.5 ausführen, müssen Sie einen Hotpatch installieren, damit TLS 1.2 von Ihrem Programm festgelegt werden kann:

KB3154518 Zuverlässigkeitsrollup HR-1605 – Unterstützung für Standardversionen des TLS-Systems im .NET Framework 3.5.1 unter Windows 7 SP1 und Windows Server 2008 R2 SP1
KB3154519 Zuverlässigkeitsrollup HR-1605 – Unterstützung für Standardversionen des TLS-Systems im .NET Framework 3.5 unter Windows Server 2012
KB3154520 Zuverlässigkeitsrollup HR-1605 – Unterstützung für Standardversionen des TLS-Systems im .NET Framework 3.5 unter Windows 8.1 und Windows Server 2012 R2
KB3156421 1605 Hotfixrollup 3154521 für das .NET Framework 4.5.2 und 4.5.1 unter Windows

Für WCF mit .NET Framework 3.5 bis 4.5.2 unter Berücksichtigung der Transportsicherheit mit Zertifikatanmeldeinformationen

Diese Versionen des WCF-Frameworks sind für die Verwendung der Werte SSL 3.0 und TLS 1.0 hartcodiert. Diese Werte können nicht geändert werden. Sie müssen auf .NET Framework 4.6 oder höhere Versionen aktualisieren und diese dann als Ziel wählen, um TLS 1.1 und 1.2 verwenden zu können.

Wenn Ihre App auf .NET Framework 3.5 abzielt

Wenn Sie explizit ein Sicherheitsprotokoll festlegen müssen, anstatt .NET oder das Betriebssystem das Sicherheitsprotokoll auswählen zu lassen, fügen Sie Ihrem Code die Enumerationen SecurityProtocolTypeExtensions und SslProtocolsExtension hinzu. SecurityProtocolTypeExtensions und SslProtocolsExtension enthalten Werte für Tls12, Tls11 und den Wert SystemDefault. Weitere Informationen finden Sie unter Unterstützung für Standardversionen des TLS-Systems im .NET Framework 3.5 unter Windows 8.1 und Windows Server 2012 R2.

Konfigurieren der Sicherheit über AppContext-Switches (für .NET Framework 4.6 oder höhere Versionen)

Die in diesem Abschnitt beschriebenen AppContext-Switches sind relevant, wenn Ihre App auf .NET Framework 4.6 oder höher abzielt und darunter ausgeführt wird. Ob standardmäßig oder explizit, die Switches sollten nach Möglichkeit auf false festgelegt sein. Wenn Sie die Sicherheitseinstellungen über einen oder beide Switches festlegen möchten, dann geben Sie in Ihrem Code keinen Wert für das Sicherheitsprotokoll an; dies würde die von den Switches vorgenommenen Einstellungen überschreiben.

Die Switches haben den gleichen Effekt, unabhängig davon, ob Sie HTTP-Netzwerke (ServicePointManager) oder TCP-Socketnetzwerke (SslStream) betreiben.

Switch.System.Net.DontEnableSchUseStrongCrypto

Der Wert false für Switch.System.Net.DontEnableSchUseStrongCrypto bewirkt, dass Ihre App starke Kryptographie verwendet. Durch den Wert false für DontEnableSchUseStrongCrypto werden sicherere Netzwerkprotokolle (TLS 1.2, TLS 1.1 und TLS 1.0) verwendet und nicht sichere Protokolle blockiert. Weitere Informationen finden Sie unter Das Flag SCH_USE_STRONG_CRYPTO. Ein Wert true deaktiviert eine starke Kryptographie für Ihre App. Dieser Schalter wirkt sich nur auf Clientverbindungen (ausgehende) Verbindungen in Ihrer Anwendung aus.

Wenn Ihre App auf .NET Framework 4.6 oder höhere Versionen abzielt, wird dieser Switch standardmäßig auf false gesetzt. Das ist der empfohlene sichere Standard. Wenn Ihre App unter .NET Framework 4.6 ausgeführt wird, aber auf eine frühere Version abzielt, wird der Switch standardmäßig auf true gesetzt. In diesem Fall sollten Sie ihn explizit auf false setzen.

DontEnableSchUseStrongCrypto sollte nur dann den Wert true aufweisen, wenn Sie sich mit älteren Diensten verbinden müssen, die keine starke Kryptographie unterstützen und nicht aktualisiert werden können.

Switch.System.Net.DontEnableSystemDefaultTlsVersions

Der Wert false für Switch.System.Net.DontEnableSystemDefaultTlsVersions bewirkt, dass in Ihrer App das Protokoll vom Betriebssystem ausgewählt werden kann. Der Wert true bewirkt, dass Ihre App Protokolle verwendet, die vom .NET Framework ausgewählt wurden.

Wenn Ihre App auf .NET Framework 4.7 oder höhere Versionen ausgerichtet ist, wird dieser Switch standardmäßig auf false festgelegt. Das ist der empfohlene sichere Standard. Wenn Ihre App unter .NET Framework 4.7 oder höheren Versionen ausgeführt wird, aber auf eine frühere Version abzielt, wird der Switch standardmäßig auf true gesetzt. In diesem Fall sollten Sie ihn explizit auf false setzen.

Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols

Der Wert false für Switch.System.ServiceModel.DisableUsingServicePointManagerSecurityProtocols bewirkt, dass Ihre Anwendung den in ServicePointManager.SecurityProtocols definierten Wert für die Nachrichtensicherheit unter Verwendung von Zertifikatanmeldeinformationen verwendet. Durch den Wert true wird das höchste verfügbare Protokoll, bis zu TLS 1.0, verwendet.

Für Anwendungen, die auf .NET Framework 4.7 und höhere Versionen abzielen, wird dieser Wert standardmäßig auf false festgelegt. Für Anwendungen, die auf .NET Framework 4.6.2 und frühere Versionen abzielen, wird dieser Wert standardmäßig auf true festgelegt.

Switch.System.ServiceModel.DontEnableSystemDefaultTlsVersions

Der Wert false für Switch.System.ServiceModel.DontEnableSystemDefaultTlsVersions legt in der Standardkonfiguration fest, dass das Protokoll vom Betriebssystem ausgewählt werden kann. Der Wert true legt die Standardeinstellung auf das höchste verfügbare Protokoll, bis zu TLS 1.2, fest.

Für Anwendungen, die auf .NET Framework 4.7.1 und höhere Versionen abzielen, wird dieser Wert standardmäßig auf false festgelegt. Für Anwendungen, die auf .NET Framework 4.7 und frühere Versionen abzielen, wird dieser Wert standardmäßig auf true festgelegt.

Weitere Informationen über TLS-Protokolle finden Sie unter Entschärfung: TLS-Protokolle. Weitere Informationen über AppContext-Switches finden Sie unter <AppContextSwitchOverrides> Element.

Konfigurieren der Sicherheit über die Windows-Registrierung

Warnung

Das Festlegen von Registrierungsschlüsseln betrifft alle Anwendungen auf dem System. Verwenden Sie diese Option nur, wenn Sie die vollständige Kontrolle über den Computer innehaben und die Änderungen an der Registrierung kontrollieren können.

Wenn die Einstellung mindestens eines AppContext-Switches nicht möglich ist, können Sie die Sicherheitsprotokolle für Ihre App mit den in diesem Abschnitt beschriebenen Windows-Registrierungsschlüsseln steuern. Möglicherweise können Sie einen oder beide AppContext-Switches nicht verwenden, wenn Ihre App unter .NET Framework-Version 4.5.2 oder früheren Versionen ausgeführt wird oder Sie die Konfigurationsdatei nicht bearbeiten können. Wenn Sie die Sicherheit mit der Registrierung konfigurieren möchten, geben Sie keinen Sicherheitsprotokollwert in Ihrem Code an; dies würde die Registrierungseinstellung außer Kraft setzen.

Die Namen der Registrierungsschlüssel ähneln den Namen der entsprechenden AppContext-Switches, jedoch ohne DontEnable vor dem Namen. Der AppContext-Switch DontEnableSchUseStrongCrypto ist beispielsweise der Registrierungsschlüssel SchUseStrongCrypto.

Diese Schlüssel sind in allen Versionen von .NET Framework verfügbar, für die es einen aktuellen Sicherheitspatch gibt. Siehe Sicherheitsupdates.

Alle unten beschriebenen Registrierungsschlüssel haben den gleichen Effekt, unabhängig davon, ob Sie HTTP-Netzwerke (ServicePointManager) oder TCP-Socketnetzwerke (SslStream) betreiben.

SchUseStrongCrypto

Der Registrierungsschlüssel HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node\]Microsoft\.NETFramework\<VERSION>: SchUseStrongCrypto hat einen Wert vom Typ DWORD. Der Wert 1 bewirkt, dass Ihre App eine starke Kryptographie verwendet. Bei der starken Kryptographie werden sicherere Netzwerkprotokolle (TLS 1.2, TLS 1.1 und TLS 1.0) verwendet und nicht sichere Protokolle blockiert. Der Wert 0 deaktiviert die starke Kryptographie. Weitere Informationen finden Sie unter Das Flag SCH_USE_STRONG_CRYPTO. Diese Registrierungseinstellung wirkt sich nur auf Clientverbindungen (ausgehende) Verbindungen in Ihrer Anwendung aus.

Wenn Ihre App auf .NET Framework 4.6 oder höhere Versionen ausgerichtet ist, wird dieser Schlüssel standardmäßig auf 1 festgelegt. Das ist der empfohlene sichere Standard. Wenn Ihre App auf .NET Framework 4.5.2 oder Vorgängerversionen ausgerichtet ist, wird der Schlüssel standardmäßig auf 0 festgelegt. In diesem Fall sollten Sie dessen Wert explizit auf 1 setzen.

Dieser Schlüssel sollte nur dann den Wert 0 aufweisen, wenn Sie sich mit älteren Diensten verbinden müssen, die keine starke Kryptographie unterstützen und nicht aktualisiert werden können.

SystemDefaultTlsVersions

Der Registrierungsschlüssel HKEY_LOCAL_MACHINE\SOFTWARE\[Wow6432Node\]Microsoft\.NETFramework\<VERSION>: SystemDefaultTlsVersions hat einen Wert vom Typ DWORD. Der Wert 1 bewirkt, dass in Ihrer App das Protokoll vom Betriebssystem ausgewählt werden kann. Der Wert 0 bewirkt, dass Ihre App Protokolle verwendet, die vom .NET Framework ausgewählt wurden.

<VERSION> muss v4.0.30319 (für .NET Framework 4 und höher) oder v2.0.50727 (für .NET Framework 3.5) sein.

Wenn Ihre App auf .NET Framework 4.7 oder höhere Versionen ausgerichtet ist, wird dieser Schlüssel standardmäßig auf 1 festgelegt. Das ist der empfohlene sichere Standard. Wenn Ihre App auf .NET Framework 4.6.1 oder Vorgängerversionen ausgerichtet ist, wird der Schlüssel standardmäßig auf 0 festgelegt. In diesem Fall sollten Sie dessen Wert explizit auf 1 setzen.

Weitere Informationen finden Sie unter Kumulatives Update für Windows 10 Version 1511 und Windows Server 2016 Technical Preview 4: 10. Mai 2016.

Weitere Informationen für die Verwendung mit .NET Framework 3.5.1 finden Sie unter Unterstützung für Standardversionen des TLS-Systems im .NET Framework 3.5.1 unter Windows 7 SP1 und Server 2008 R2 SP1.

Die folgende .REG-Datei legt die Registrierungsschlüssel und deren Varianten auf die sichersten Werte fest:

Windows Registry Editor Version 5.00

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v2.0.50727]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319]
"SystemDefaultTlsVersions"=dword:00000001
"SchUseStrongCrypto"=dword:00000001

Konfigurieren von Schannel-Protokollen in der Windows-Registrierung

Sie können die Registrierung verwenden, um die Protokolle, die Ihre Client- und/oder Server-App aushandelt, genau zu steuern. Die Vernetzung Ihrer App erfolgt über Schannel (eine andere Bezeichnung für Secure Channel). Durch die Konfiguration von Schannel können Sie das Verhalten Ihrer App konfigurieren.

Beginnen Sie mit dem Registrierungsschlüssel HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols. Unter diesem Schlüssel können Sie beliebige Unterschlüssel im Satz SSL 2.0, SSL 3.0, TLS 1.0, TLS 1.1 und TLS 1.2 anlegen. Unter jedem dieser Unterschlüssel können Sie die Unterschlüssel Client und/oder Server anlegen. Unter Client und Server können Sie die DWORD-Werte DisabledByDefault (0 oder 1) und Enabled (0 oder 1) erstellen.

Das Flag SCH_USE_STRONG_CRYPTO

Wenn sie aktiviert ist (standardmäßig durch einen AppContext Schalter oder durch die Windows Registrierung), verwendet die .NET Framework das SCH_USE_STRONG_CRYPTO Flag, wenn Ihre App eine TLS-Verbindung mit einem Server initiiert. .NET Framework übergibt die KennzeichnungSchannel, um sie anzuweisen, bekannte schwache kryptografische Algorithmen, Verschlüsselungssuiten und TLS/SSL-Protokollversionen zu deaktivieren, die sonst für eine bessere Interoperabilität aktiviert sind. Weitere Informationen finden Sie unter:

Das SCH_USE_STRONG_CRYPTO Flag wird auch für Clientverbindungen (ausgehende) Verbindungen übergeben Schannel , wenn Sie explizit die Tls Werte (TLS 1.0) Tls11oder Tls12 aufgezählte Werte von SecurityProtocolType oder SslProtocols. Das SCH_USE_STRONG_CRYPTO Flag wird nur für Verbindungen verwendet, bei denen Ihre Anwendung die Rolle des Clients fungiert. Sie können schwache Protokolle und Algorithmen deaktivieren, wenn Ihre Anwendungen die Rolle des Servers verwenden, indem Sie die computerweiten Schannel Registrierungseinstellungen konfigurieren.

Sicherheitsupdates

Die bewährten Methoden in diesem Artikel hängen von der Installation aktueller Sicherheitsupdates ab. Diese Updates beinhalten die Möglichkeit, erweiterte Features von .NET Framework 4.7 und höher zu verwenden. Aktuelle Sicherheitsupdates sind wichtig, wenn Ihre App unter .NET Framework 4.7 und höheren Versionen läuft (auch wenn sie auf eine frühere Version abzielt).

Um .NET Framework zu aktualisieren, damit das Betriebssystem die beste Version von TLS verwenden kann, müssen mindestens folgende Installationsanforderungen erfüllt sein:

Siehe auch:

Unterstützung für TLS 1.2

Damit Ihre App TLS 1.2 aushandeln kann, müssen sowohl das Betriebssystem als auch die .NET Framework-Version TLS 1.2 unterstützen.

Betriebssystemanforderungen zur Unterstützung von TLS 1.2

Um TLS 1.2 und/oder TLS 1.1 auf einem System, das sie unterstützt, zu aktivieren oder erneut zu aktivieren, siehe Transport Layer Security (TLS)-Registrierungseinstellungen.

Betriebssystem TLS 1.2-Unterstützung
Windows 10
Windows Server 2016
Unterstützt und standardmäßig aktiviert.
Windows 8.1
Windows Server 2012 R2
Unterstützt und standardmäßig aktiviert.
Windows 8.0
Windows Server 2012
Unterstützt und standardmäßig aktiviert.
Windows 7 SP1
Windows Server 2008 R2 SP1
Unterstützt und nicht standardmäßig aktiviert. Weitere Informationen zum Aktivieren von TLS 1.2 finden Sie auf der Webseite Transport Layer Security (TLS)-Registrierungseinstellungen.
Windows Server 2008 Für Unterstützung für TLS 1.2 und TLS 1.1 ist ein Update erforderlich. Siehe Update zum Hinzufügen der Unterstützung von TLS 1.1 und TLS 1.2 in Windows Server 2008 SP2.
Windows Vista Wird nicht unterstützt.

Informationen darüber, welche TLS/SSL-Protokolle auf den einzelnen Windows-Version standardmäßig aktiviert sind, finden Sie unter Protokolle in TLS/SSL (Schannel SSP).

Anforderungen zur Unterstützung von TLS 1.2 mit .NET Framework 3.5

Diese Tabelle zeigt das Betriebssystemupdate, das Sie benötigen, um TLS 1.2 mit .NET Framework 3.5 zu unterstützen. Es wird empfohlen, alle Betriebssystemupdates zu installieren.

Betriebssystem Erforderliches Mindestupdate zur Unterstützung von TLS 1.2 mit .NET Framework 3.5
Windows 10
Windows Server 2016
Kumulatives Update für Windows 10 Version 1511 und Windows Server 2016 Technical Preview 4: 10. Mai 2016
Windows 8.1
Windows Server 2012 R2
Unterstützung für Standardversionen des TLS-Systems im .NET Framework 3.5 unter Windows 8.1 und Windows Server 2012 R2
Windows 8.0
Windows Server 2012
Unterstützung für Standardversionen des TLS-Systems im .NET Framework 3.5 unter Windows Server 2012
Windows 7 SP1
Windows Server 2008 R2 SP1
Unterstützung für Standardversionen des TLS-Systems im .NET Framework 3.5.1 unter Windows 7 SP1 und Windows Server 2008 R2 SP1
Windows Server 2008 Unterstützung für Standardversionen des TLS-Systems im .NET Framework 2.0 SP2 unter Windows Vista SP2 und Windows Server 2008 SP2
Windows Vista Nicht unterstützt