Freigeben über


Änderungen an TLS (Schannel SSP) in Windows 10 und Windows Server 2016

Gilt für: Windows Server 2022, Windows Server 2019, Windows Server 2016 und Windows 10

Änderungen an der Verschlüsselungssammlung

Unter Windows 10, Version 1511 und Windows Server 2016 wurde Unterstützung für die Konfiguration der Reihenfolge der Verschlüsselungssammlung mit der Verwaltung mobiler Geräte (MDM) hinzugefügt.

Informationen zu Änderungen der Prioritätsreihenfolge für die Verschlüsselungssammlung finden Sie unter Verschlüsselungssammlungen in Schannel.

Unterstützung für die folgenden Verschlüsselungssammlungen hinzugefügt:

  • TLS_ECDHE_RSA_WITH_AES_128_GCM_SHA256 (RFC 5289) in Windows 10, Version 1507 und Windows Server 2016
  • TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384 (RFC 5289) in Windows 10, Version 1507 und Windows Server 2016

Änderung bei DisabledByDefault für die folgenden Verschlüsselungssammlungen:

  • TLS_DHE_DSS_WITH_AES_256_CBC_SHA256 (RFC 5246) in Windows 10, Version 1703
  • TLS_DHE_DSS_WITH_AES_128_CBC_SHA256 (RFC 5246) in Windows 10, Version 1703
  • TLS_DHE_DSS_WITH_AES_256_CBC_SHA (RFC 5246) in Windows 10, Version 1703
  • TLS_DHE_DSS_WITH_AES_128_CBC_SHA (RFC 5246) in Windows 10, Version 1703
  • TLS_DHE_DSS_WITH_3DES_EDE_CBC_SHA (RFC 5246) in Windows 10, Version 1703
  • TLS_RSA_WITH_RC4_128_SHA in Windows 10, Version 1709
  • TLS_RSA_WITH_RC4_128_MD5 in Windows 10, Version 1709

Ab Windows 10, Version 1507 und Windows Server 2016 werden SHA 512-Zertifikate standardmäßig unterstützt.

Änderungen bei RSA-Schlüsseln

Unter Windows 10, Version 1507 und Windows Server 2016 wurden Registrierungskonfigurationsoptionen für RSA-Clientschlüsselgrößen hinzugefügt.

Weitere Informationen finden Sie unter KeyExchangeAlgorithm-Schlüsselgrößen.

Änderungen bei Diffie-Hellman-Schlüsseln

Unter Windows 10, Version 1507 und Windows Server 2016 wurden Registrierungskonfigurationsoptionen für Diffie-Hellman Schlüsselgrößen hinzugefügt.

Weitere Informationen finden Sie unter KeyExchangeAlgorithm-Schlüsselgrößen.

Änderungen bei der Option SCH_USE_STRONG_CRYPTO

Unter Windows 10, Version 1507 und Windows Server 2016 deaktiviert die Option SCH_USE_STRONG_CRYPTO jetzt NULL-, MD5-, DES- und Exportchiffren.

Änderungen bei elliptischen Kurven

Unter Windows 10, Version 1507 und Windows Server 2016 wurde die Gruppenrichtlinienkonfiguration für elliptische Kurven unter „Computerkonfiguration“ > „Administrative Vorlagen“ > „Netzwerk“ > „SSL-Konfigurationseinstellungen“ hinzugefügt. In der Liste mit der ECC-Kurvenreihenfolge ist die Reihenfolge angegeben, in der elliptische Kurven priorisiert werden. Außerdem werden Kurven unterstützt, die nicht aktiviert sind.

Unterstützung für die folgenden elliptischen Kurven hinzugefügt:

  • BrainpoolP256r1 (RFC 7027) in Windows 10, Version 1507 und Windows Server 2016
  • BrainpoolP384r1 (RFC 7027) in Windows 10, Version 1507 und Windows Server 2016
  • BrainpoolP512r1 (RFC 7027) in Windows 10, Version 1507 und Windows Server 2016
  • Curve25519 (RFC draft-ietf-tls-curve25519) in Windows 10, Version 1607 und Windows Server 2016

Unterstützung auf Verteilerebene für SealMessage & UnsealMessage

Unter Windows 10, Version 1507 und Windows Server 2016 wurde Unterstützung für SealMessage/UnsealMessage auf Verteilerebene hinzugefügt.

DTLS 1.2

Unter Windows 10, Version 1607 und Windows Server 2016 wurde Unterstützung für DTLS 1.2 (RFC 6347) hinzugefügt.

HTTP.SYS-Threadpool

Unter Windows 10, Version 1607 und Windows Server 2016 wurde die Registrierungskonfiguration der Größe des Threadpools zum Verarbeiten von TLS-Handshakes für HTTP.SYS hinzugefügt.

Registrierungspfad:

HKLM\SYSTEM\CurrentControlSet\Control\LSA

Um die maximale Threadpoolgröße pro CPU-Kern anzugeben, erstellen Sie einen MaxAsyncWorkerThreadsPerCpu-Eintrag. Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden. Nachdem Sie den Eintrag erstellt haben, ändern Sie den DWORD-Wert in die gewünschte Größe. Wenn der Wert nicht konfiguriert wird, beträgt der Höchstwert 2 Threads pro CPU-Kern.

NPN-Unterstützung (Next Protocol Negotiation, Nächste Protokollverhandlung)

Ab Windows 10, Version 1703 wurde die NPN (Next Protocol Negotiation, Nächste Protokollverhandlung) entfernt und wird nicht mehr unterstützt.

Vorinstallierter Schlüssel (PSK)

Unter Windows 10, Version 1607 und Windows Server 2016 wurde Unterstützung für den PSK-Schlüsselaustauschalgorithmus (RFC 4279) hinzugefügt.

Unterstützung für die folgenden PSK-Verschlüsselungssammlungen hinzugefügt:

  • TLS_PSK_WITH_AES_128_CBC_SHA256 (RFC 5487) in Windows 10, Version 1607 und Windows Server 2016
  • TLS_PSK_WITH_AES_256_CBC_SHA384 (RFC 5487) in Windows 10, Version 1607 und Windows Server 2016
  • TLS_PSK_WITH_NULL_SHA256 (RFC 5487) in Windows 10, Version 1607 und Windows Server 2016
  • TLS_PSK_WITH_NULL_SHA384 (RFC 5487) in Windows 10, Version 1607 und Windows Server 2016
  • TLS_PSK_WITH_AES_128_GCM_SHA256 (RFC 5487) in Windows 10, Version 1607 und Windows Server 2016
  • TLS_PSK_WITH_AES_256_GCM_SHA384 (RFC 5487) in Windows 10, Version 1607 und Windows Server 2016

Wiederaufnahme der Sitzung ohne serverseitige Leistungsverbesserungen

Windows 10, Version 1507 und Windows Server 2016 bieten jetzt 30 % mehr Sitzungswiedereinführungen pro Sekunde mit Sitzungstickets als Windows Server 2012.

Sitzungshash und erweiterte Mastergeheimniserweiterung

Unter Windows 10, Version 1507 und Windows Server 2016 wurde Unterstützung für RFC 7627: TLS-Sitzungshash (Transport Layer Security) und erweiterte Mastergeheimniserweiterung hinzugefügt.

Aufgrund dieser Änderung erfordern Windows 10 und Windows Server 2016 Updates der CNG-SSL-Anbieter von Drittanbietern, um NCRYPT_SSL_INTERFACE_VERSION_3 zu unterstützen und diese neue Schnittstelle zu beschreiben.

SSL-Unterstützung

Ab Windows 10, Version 1607 und Windows Server 2016 sind der TLS-Client und serverseitiges SSL 3.0 standardmäßig deaktiviert. Dies bedeutet, dass der Client niemals SSL 3.0 anbietet oder akzeptiert und dass der Server niemals SSL 3.0 auswählt, sofern die Anwendung oder der Dienst nicht speziell SSL 3.0 über die SSPI anfordert.

Ab Windows 10, Version 1607 und Windows Server 2016 wurde SSL 2.0 entfernt und wird nicht mehr unterstützt.

Änderungen an den Anforderungen an die Einhaltung von TLS 1.2 für Verbindungen mit nicht konformen TLS-Clients unter Windows

In TLS 1.2 verwendet der Client die Erweiterung „signature_algorithms“, um dem Server mitzuteilen, welche Signatur-Hash-Algorithmuspaare in digitalen Signaturen (z. B. Serverzertifikate und Serverschlüsselaustausch) verwendet werden können. Der RFC zu TLS 1.2 erfordert auch, dass die Serverzertifikatnachricht die Erweiterung „signature_algorithms“ berücksichtigt:

„Wenn der Client die Erweiterung „signature_algorithms“ bereitgestellt hat, MÜSSEN alle vom Server bereitgestellten Zertifikate von einem Hash-Signatur-Algorithmuspaar signiert werden, das in dieser Erweiterung enthalten ist.“

In der Praxis sind einige TLS-Clients von Drittanbietern nicht mit dem RFC für TLS 1.2 konform und schließen nicht alle Signatur-Hash-Algorithmuspaare ein, die sie in der Erweiterung „signature_algorithms“ akzeptieren könnten, oder sie lassen die Erweiterung ganz weg (letzteres gibt dem Server an, dass der Client nur SHA-1 mit RSA, DSA oder ECDSA unterstützt).

Ein TLS-Server verfügt häufig nur über ein konfiguriertes Zertifikat pro Endpunkt. Das bedeutet, dass der Server nicht immer ein Zertifikat bereitstellen kann, das den Anforderungen des Clients entspricht.

Vor Windows 10 und Windows Server 2016 hat der Windows-TLS-Stapel die RFC-Anforderungen für TLS 1.2 strikt eingehalten, was zu Verbindungsfehlern mit nicht mit dem RFC konformen TLS-Clients und Interoperabilitätsproblemen führte. Unter Windows 10 und Windows Server 2016 werden die Einschränkungen gelockert, und der Server kann ein Zertifikat senden, das nicht dem RFC für TLS 1.2 entspricht, wenn dies die einzige Option des Servers ist. Der Client kann dann den Handshake fortsetzen oder beenden.

Beim Überprüfen von Server- und Clientzertifikaten ist der Windows-TLS-Stapel streng mit dem RFC für TLS 1.2 konform und erlaubt nur die ausgehandelten Signatur- und Hashalgorithmen in den Server- und Clientzertifikaten.