it-swarm.com.de

Standard-Sicherheitsprotokoll in .NET 4.5

Was ist das Standardsicherheitsprotokoll für die Kommunikation mit Servern, die bis zu TLS 1.2 unterstützen? Wählt .NET standardmäßig das höchste auf der Serverseite unterstützte Sicherheitsprotokoll oder muss ich diese Codezeile explizit hinzufügen:

System.Net.ServicePointManager.SecurityProtocol = 
SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

Gibt es eine Möglichkeit, diese Standardeinstellung zu ändern, abgesehen von einer Codeänderung?

Unterstützt .NET 4.0 nur bis zu TLS 1.0? ich muss Client-Projekte auf 4.5 aktualisieren, um TLS 1.2 zu unterstützen.

Meine Motivation ist es, die Unterstützung für SSLv3 auf der Clientseite zu entfernen, auch wenn der Server dies unterstützt (ich habe bereits ein Powershell-Skript, um dies in der Maschinenregistrierung zu deaktivieren) und das höchste TLS-Protokoll zu unterstützen, das der Server unterstützt.

Update: Wenn ich die ServicePointManager -Klasse in .NET 4.0 betrachte, sehe ich keine aufgezählten Werte für TLS 1.0 und 1.1. In beiden .NET 4.0/4.5 ist der Standardwert SecurityProtocolType.Tls|SecurityProtocolType.Ssl3. Hoffentlich bricht dieser Standard nicht durch Deaktivieren von SSLv3 in der Registrierung.

Ich habe jedoch beschlossen, alle Apps auf .NET 4.5 zu aktualisieren und SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12; trotzdem explizit zu allen Bootstrapping-Codes aller Anwendungen hinzuzufügen.

Dadurch werden ausgehende Anfragen an verschiedene APIs und Dienste gestellt, nicht auf SSLv3 heruntergestuft zu werden, und es sollte die höchste Stufe von TLS ausgewählt werden.

Klingt dieser Ansatz vernünftig oder übertrieben? Ich muss viele Anwendungen aktualisieren, und ich möchte sie zukunftssicher machen, da ich höre, dass in naher Zukunft sogar TLS 1.0 von einigen Anbietern veraltet sein wird.

Hat das Deaktivieren von SSL3 in der Registrierung als Client, der ausgehende Anforderungen an APIs sendet, überhaupt Auswirkungen auf das .NET-Framework? Ich sehe standardmäßig, dass TLS 1.1 und 1.2 nicht aktiviert sind. Müssen wir es über die Registrierung aktivieren? RE http://support.Microsoft.com/kb/2450 .

Nach einigem Nachforschen glaube ich, dass die Registrierungseinstellungen keine Auswirkungen haben werden, da sie für IIS (Server-Unterschlüssel) und Browser (Client-Unterschlüssel) gelten.

Entschuldigung, dieser Beitrag wurde zu mehreren Fragen, gefolgt von "vielleicht" Antworten.

227
Luke Hutton

Einige derjenigen, die Kommentare hinterlassen, haben festgestellt, dass das Festlegen von System.Net.ServicePointManager.SecurityProtocol auf bestimmte Werte bedeutet, dass Ihre App zukünftige TLS-Versionen nicht mehr nutzen kann, die möglicherweise die Standardwerte in zukünftigen Updates für .NET werden. Anstatt eine feste Liste von Protokollen anzugeben, können Sie Protokolle, die Sie kennen und die Ihnen wichtig sind, aktivieren oder deaktivieren und alle anderen so lassen, wie sie sind.

So aktivieren Sie TLS 1.1 und 1.2, ohne andere Protokolle zu beeinflussen:

System.Net.ServicePointManager.SecurityProtocol |= 
    SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

Beachten Sie die Verwendung von |=, um diese Flags zu aktivieren, ohne andere zu deaktivieren.

So deaktivieren Sie SSL3, ohne andere Protokolle zu beeinflussen:

System.Net.ServicePointManager.SecurityProtocol &= ~SecurityProtocolType.Ssl3;
234
Scott

Der Standardwert System.Net.ServicePointManager.SecurityProtocol in beiden .NET-Versionen 4.0/4.5 ist SecurityProtocolType.Tls|SecurityProtocolType.Ssl3.

.NET 4.0 unterstützt bis zu TLS 1.0, während .NET 4.5 bis zu TLS 1.2 unterstützt

Eine auf .NET 4.0 ausgerichtete Anwendung kann jedoch weiterhin bis zu TLS 1.2 unterstützen, wenn .NET 4.5 in derselben Umgebung installiert ist. .NET 4.5 wird über .NET 4.0 installiert und ersetzt System.dll.

Ich habe dies überprüft, indem ich das im Datenverkehr mit fiddler4 festgelegte richtige Sicherheitsprotokoll eingehalten und die aufgezählten Werte in einem .NET 4.0 -Projekt manuell festgelegt habe:

ServicePointManager.SecurityProtocol = (SecurityProtocolType)192 |
(SecurityProtocolType)768 | (SecurityProtocolType)3072;

Referenz:

namespace System.Net
{
    [System.Flags]
    public enum SecurityProtocolType
    {
       Ssl3 = 48,
       Tls = 192,
       Tls11 = 768,
       Tls12 = 3072,
    }
}

Wenn Sie den Hack in einer Umgebung ausführen, in der NUR .NET 4.0 installiert ist, wird die folgende Ausnahme angezeigt:

Nicht behandelte Ausnahme: System.NotSupportedException: Das angeforderte Sicherheitsprotokoll wird nicht unterstützt. bei System.Net.ServicePointManager.set_SecurityProtocol (SecurityProtocolType v alue)

Allerdings würde ich diesen "Hack" nicht empfehlen, da ein zukünftiger Patch usw. ihn möglicherweise kaputt machen könnte. *

Aus diesem Grund habe ich beschlossen, die Unterstützung für SSLv3 auf folgende Weise zu entfernen:

  1. Aktualisieren Sie alle Anwendungen auf .NET 4.5
  2. Fügen Sie dem Boostrapping-Code Folgendes hinzu, um den Standardcode zu überschreiben und ihn zukunftssicher zu machen:

    System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls | SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

* Jemand korrigiert mich, wenn dieser Hack falsch ist, aber erste Tests, die ich sehe, funktionieren

180
Luke Hutton

Sie können das Standardverhalten in der folgenden Registrierung überschreiben:

Key  : HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\.NETFramework\v4.0.30319 
Value: SchUseStrongCrypto
Type: REG_DWORD
Data : 1

und

Key  : HKEY_LOCAL_MACHINE\SOFTWARE\WOW6432Node\Microsoft\.NETFramework\v4.0.30319
Value: SchUseStrongCrypto
Type: REG_DWORD
Data : 1

Einzelheiten finden Sie in Implementierung von ServicePointManager .

63
Jiri Mares

Erstellen Sie eine Textdatei mit der Erweiterung .reg und dem folgenden Inhalt:

Windows Registry Editor Version 5.00

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

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

Oder laden Sie es von der folgenden Quelle herunter:

https://tls1test.salesforce.com/s/NET40-Enable-TLS-1_2.reg

Zum Installieren doppelklicken ...

48
dana

Ich habe festgestellt, dass, wenn ich nur TLS 1.2 spezifiziere, es immer noch auf 1.1 herunterverhandelt wird. System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls12;

Ich habe dies in der Startmethode Global.asax für meine .net 4.5-Webanwendung angegeben.

19
Jim

Der Registrierungsänderungsmechanismus funktionierte nach einem Kampf für mich. Eigentlich lief meine Anwendung als 32bit. Also musste ich den Wert unter Pfad ändern.

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v4.0.30319

Der Werttyp muss DWORD und ein Wert über 0 sein. Verwenden Sie besser 1.Registry settings to get .Net 4.0 app use TLS 1.2 provided .Net 4.5 is installed in the machine.

14

Folgender Code wird:

  • druckfähige Protokolle
  • verfügbare Protokolle drucken
  • aktivieren Sie TLS1.2, wenn die Plattform dies unterstützt und nicht aktiviert ist
  • deaktivieren Sie SSL3, wenn es aktiviert ist
  • endergebnis drucken

Konstanten:

  • 48 ist SSL3
  • 192 ist TLS1
  • 768 ist TLS1.1
  • 3072 ist TLS1.2

Andere Protokolle sind nicht betroffen. Dies macht dies kompatibel mit zukünftigen Protokollen (Tls1.3, etc).

Code

// print initial status
    Console.WriteLine("Runtime: " + System.Diagnostics.FileVersionInfo.GetVersionInfo(typeof(int).Assembly.Location).ProductVersion);
    Console.WriteLine("Enabled protocols:   " + ServicePointManager.SecurityProtocol);
    Console.WriteLine("Available protocols: ");
    Boolean platformSupportsTls12 = false;
    foreach (SecurityProtocolType protocol in Enum.GetValues(typeof(SecurityProtocolType))) {                
        Console.WriteLine(protocol.GetHashCode());
        if (protocol.GetHashCode() == 3072){
            platformSupportsTls12 = true;
        }
    }
    Console.WriteLine("Is Tls12 enabled: " + ServicePointManager.SecurityProtocol.HasFlag((SecurityProtocolType)3072));    


// enable Tls12, if possible
    if (!ServicePointManager.SecurityProtocol.HasFlag((SecurityProtocolType)3072)){
        if (platformSupportsTls12){
            Console.WriteLine("Platform supports Tls12, but it is not enabled. Enabling it now.");
            ServicePointManager.SecurityProtocol |= (SecurityProtocolType)3072;
        } else {
            Console.WriteLine("Platform does not supports Tls12.");
        }
    }

// disable ssl3
   if (ServicePointManager.SecurityProtocol.HasFlag(SecurityProtocolType.Ssl3)) { 
      Console.WriteLine("Ssl3SSL3 is enabled. Disabling it now.");
      // disable SSL3. Has no negative impact if SSL3 is already disabled. The enclosing "if" if just for illustration.
      System.Net.ServicePointManager.SecurityProtocol &= ~SecurityProtocolType.Ssl3;                      
   }
    Console.WriteLine("Enabled protocols:   " + ServicePointManager.SecurityProtocol);

Ausgabe

Runtime: 4.7.2114.0
Enabled protocols:   Ssl3, Tls
Available protocols: 
0
48
192
768
3072
Is Tls12 enabled: False
Platform supports Tls12, but it is not enabled. Enabling it now.
Ssl3 is enabled. Disabling it now.
Enabled protocols:   Tls, Tls12
13
gerasoras

Ich habe das Problem, als mein Kunde TLS von 1.0 auf 1.2 aktualisiert hat. Meine Anwendung verwendet .NET Framework 3.5 und wird auf einem Server ausgeführt. Also habe ich es so behoben:

  1. Korrigieren Sie das Programm

Fügen Sie vor dem Aufruf von HttpWebRequest.GetResponse () den folgenden Befehl hinzu:

ServicePointManager.SecurityProtocol = SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolTypeExtensions.Tls11 | SecurityProtocolTypeExtensions.Tls12;

Erweiterungen 2 DLLs durch Hinzufügen von 2 neuen Klassen: System.Net und System.Security.Authentication

    namespace System.Net
    {
        using System.Security.Authentication;
        public static class SecurityProtocolTypeExtensions
        {
            public const SecurityProtocolType Tls12 = (SecurityProtocolType)SslProtocolsExtensions.Tls12;
            public const SecurityProtocolType Tls11 = (SecurityProtocolType)SslProtocolsExtensions.Tls11;
            public const SecurityProtocolType SystemDefault = (SecurityProtocolType)0;
        }
    } 

    namespace System.Security.Authentication
    {
        public static class SslProtocolsExtensions
        {
            public const SslProtocols Tls12 = (SslProtocols)0x00000C00;
            public const SslProtocols Tls11 = (SslProtocols)0x00000300;
        }
    } 
  1. Aktualisieren Sie Microsoft Batch

Batch herunterladen:

  • Für Windows 2008 R2: windows6.1-kb3154518-x64.msu
  • Für Windows 2012 R2: windows8.1-kb3154520-x64.msu

Für den Download Batch und weitere Details sehen Sie hier:

https://support.Microsoft.com/de-de/help/3154518/support-for-tls-system-default-versions-inclusive-in-the-.net-framework-3.5.1-on -windows-7-sp1-and-server-2008-r2-sp1

13
Hieu

Ich arbeite unter .NET 4.5.2 und war mit keiner dieser Antworten zufrieden. Da ich mit einem System spreche, das TLS 1.2 unterstützt und SSL3, TLS 1.0 und TLS 1.1 fehlerhaft und unsicher sind, möchte ich diese Protokolle nicht aktivieren. Unter .NET 4.5.2 sind die Protokolle SSL3 und TLS 1.0 standardmäßig aktiviert. Dies kann ich im Code sehen, indem ich ServicePointManager.SecurityProtocol inspiziere. Unter .NET 4.7 gibt es den neuen Protokollmodus SystemDefault, mit dem die Auswahl des Protokolls explizit an das Betriebssystem übergeben wird, wobei es meines Erachtens angemessen wäre, sich auf die Registrierung oder andere Systemkonfigurationseinstellungen zu verlassen. Dies scheint jedoch unter .NET 4.5.2 nicht unterstützt zu werden. Damit Sie vorwärtskompatiblen Code schreiben können, müssen Sie auch dann die richtigen Entscheidungen treffen, wenn TLS 1.2 in Zukunft unvermeidlich beschädigt ist oder wenn ich ein Upgrade auf .NET 4.7+ durchführe und dem Betriebssystem mehr Verantwortung für die Auswahl eines geeigneten Protokolls übergebe Ich habe folgenden Code übernommen:

SecurityProtocolType securityProtocols = ServicePointManager.SecurityProtocol;
if (securityProtocols.HasFlag(SecurityProtocolType.Ssl3) || securityProtocols.HasFlag(SecurityProtocolType.Tls) || securityProtocols.HasFlag(SecurityProtocolType.Tls11))
{
    securityProtocols &= ~(SecurityProtocolType.Ssl3 | SecurityProtocolType.Tls | SecurityProtocolType.Tls11);
    if (securityProtocols == 0)
    {
        securityProtocols |= SecurityProtocolType.Tls12;
    }
    ServicePointManager.SecurityProtocol = securityProtocols;
}

Dieser Code erkennt, wenn ein bekanntes unsicheres Protokoll aktiviert ist. In diesem Fall werden diese unsicheren Protokolle entfernt. Wenn keine anderen expliziten Protokolle mehr vorhanden sind, wird TLS 1.2 als einziges bekanntes sicheres Protokoll, das derzeit von .NET unterstützt wird, aktiviert. Dieser Code ist vorwärtskompatibel, da er neue Protokolltypen berücksichtigt, von denen er nicht weiß, dass sie in Zukunft hinzugefügt werden, und er wird auch mit dem neuen SystemDefault -Status in .NET 4.7 kompatibel sein, was bedeutet, dass ich gewonnen habe muss diesen Code in Zukunft nicht mehr erneut aufrufen. Ich würde dringend empfehlen, einen solchen Ansatz zu wählen, anstatt bestimmte Sicherheitsprotokollzustände unbedingt fest zu codieren. Andernfalls müssen Sie Ihren Client neu kompilieren und durch eine neue Version ersetzen, um bei TLS 1.2 ein Upgrade auf ein neues Sicherheitsprotokoll durchführen zu können ist unvermeidlich defekt, oder es ist wahrscheinlicher, dass Sie die vorhandenen unsicheren Protokolle jahrelang auf Ihrem Server aktiviert lassen müssen, sodass Ihre Organisation ein Ziel für Angriffe ist.

8
Roger Sanders

Microsoft hat kürzlich Best Practices veröffentlicht. https://docs.Microsoft.com/en-us/dotnet/framework/network-programming/tls

Zusammenfassung

Entfernen Sie für .Net Framework 4.7 den Code, der das Sicherheitsprotokoll festlegt, damit das Betriebssystem sicherstellt, dass Sie die sicherste Lösung verwenden.

NB: Sie müssen auch sicherstellen, dass die neueste Version von TLS auf Ihrem Betriebssystem unterstützt und aktiviert ist.

OS                          TLS 1.2 support

Windows 10                  \_ Supported, and enabled by default.
Windows Server 2016         /   
Windows 8.1                 \_ Supported, and enabled by default.
Windows Server 2012 R2      /
Windows 8.0                 \_ Supported, and enabled by default.
Windows Server 2012         /
Windows 7 SP1               \_ Supported, but not enabled by default*.
Windows Server 2008 R2 SP1  /
Windows Server 2008         -  Support for TLS 1.2 and TLS 1.1 requires an update. See Update to add support for TLS 1.1 and TLS 1.2 in Windows Server 2008 SP2.
Windows Vista               -  Not supported.

* To enable TLS1.2 via the registry see https://docs.Microsoft.com/en-us/windows-server/security/tls/tls-registry-settings#tls-12 

    Path: HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS1.2\Server

        Property: Enabled
        Type: REG_DWORD
        Value: 1

        Property: DisabledByDefault 
        Type: REG_DWORD
        Value: 0

    Path: HKLM:\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS1.2\Client

        Property: Enabled
        Type: REG_DWORD
        Value: 1

        Property: DisabledByDefault 
        Type: REG_DWORD
        Value: 0

Weitere Informationen und ältere Frameworks finden Sie unter dem MS-Link.

5
JohnLBevan

Der Vollständigkeit halber ist hier ein Powershell-Skript, das die oben genannten Registrierungsschlüssel festlegt:

new-itemproperty -path "HKLM:\SOFTWARE\Microsoft\.NETFramework\v4.0.30319" -name "SchUseStrongCrypto" -Value 1 -PropertyType "DWord";
new-itemproperty -path "HKLM:\SOFTWARE\Wow6432Node\Microsoft\.NETFramework\v4.0.30319" -name "SchUseStrongCrypto" -Value 1 -PropertyType "DWord"
3
qbik

Die BESTE Lösung für dieses Problem scheint ein Upgrade auf mindestens .NET 4.6 oder höher zu sein, bei dem automatisch sowohl starke Protokolle als auch starke Chiffren ausgewählt werden.

Wenn Sie nicht auf .NET 4.6 aktualisieren können, lesen Sie die Einstellungshinweise

System.Net.ServicePointManager.SecurityProtocol = SecurityProtocolType.Tls11 | SecurityProtocolType.Tls12;

Und mit den Registrierungseinstellungen:

HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft.NETFramework\v4.0.30319 - SchUseStrongCrypto = DWORD von 1 HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Microsoft.NETFramework\v4.0.30319 - SchUseStrongCrypto = 1

Dies führt dazu, dass etwas anderes als TLS 1.0 und eine starke Verschlüsselung verwendet wird.

In meinen Tests machte nur die Einstellung im Wow6432-Knoten einen Unterschied, obwohl meine Testanwendung für eine beliebige CPU erstellt wurde.

2
G W C

Eine Alternative zur Hardcodierung von ServicePointManager.SecurityProtocol oder des expliziten SchUseStrongCrypto Schlüssels, wie oben erwähnt:
Sie können .NET anweisen, die Standardeinstellungen für SCHANNEL mit dem Schlüssel SystemDefaultTlsVersions zu verwenden.
z.B.:

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