Registrierungseinstellungen für Transport Layer Security (TLS)

In diesem Artikel werden die unterstützten Registrierungseinstellungsinformationen für die Windows-Implementierung des TLS-Protokolls (Transport Layer Security) und das SSL-Protokoll (Secure Sockets Layer) über den Schannel Security Support Provider (SSP) erläutert. Die in diesem Artikel behandelten Registrierungsunterschlüssel und Einträge helfen Ihnen bei der Verwaltung und Problembehandlung des Schannel-SSP, insbesondere der TLS- und SSL-Protokolle.

Schannel-Protokollierung

Es gibt acht Protokollierungsebenen für Schannel-Ereignisse, die im Systemereignisprotokoll gespeichert und mithilfe der Ereignisanzeige angezeigt werden können. Dieser Registrierungspfad ist in HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL unter dem Schlüssel EventLogging mit einem auf 1.

CertificateMappingMethods

Wenn eine Serveranwendung eine Clientauthentifizierung erfordert, versucht Schannel automatisch, das vom Clientcomputer bereitgestellte Zertifikat einem Benutzerkonto zuzuordnen. Sie können Benutzer authentifizieren, die sich mit einem Clientzertifikat anmelden, indem Sie Zuordnungen erstellen, die die Zertifikatsinformationen einem Windows-Benutzerkonto zuordnen.

Nachdem Sie eine Zertifikatzuordung erstellt und aktiviert haben, ordnet Ihre Serveranwendung immer dann, wenn ein Client ein Clientzertifikat vorlegt, diesen Benutzer dem entsprechenden Windows-Benutzerkonto zu.

In den meisten Fällen wird ein Zertifikat einem Benutzerkonto auf eine von zwei Arten zugeordnet:

• Ein einzelnes Zertifikat wird einem einzelnen Benutzerkonto zugeordnet (1:1-Zuordnung).
• Mehrere Zertifikate werden einem Benutzerkonto zugeordnet (n:1-Zuordnung).

Der Schannel-Anbieter verwendet vier Zertifikatzuordnungsmethoden:

1. Kerberos-S4U-Zuordnung (Service-for-User) (standardmäßig aktiviert)
2. Zuordnung von Benutzerprinzipalnamen
3. 1:1-Zuordnung (auch bekannt als Antragsteller/Aussteller- Zuordnung)
4. n:1-Zuordnung

Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Ciphers

TLS/SSL-Verschlüsselungen sollten durch Konfigurieren der Reihenfolge von Verschlüsselungssammlungen gesteuert werden. Details finden Sie unter Konfigurieren der Reihenfolge von TLS-Verschlüsselungssammlungen.

Informationen zu standardchiffre suite orders that are used by the Schannel SSP, see Cipher Suites in TLS/SSL (Schannel SSP).

CipherSuites

Die Konfiguration von TLS/SSL-Cipher-Suites sollte mithilfe von Gruppenrichtlinien, MDM oder PowerShell erfolgen, siehe Konfigurieren der TLS-Cipher-Suite-Reihenfolge for details.

Informationen zu standardchiffre suite orders that are used by the Schannel SSP, see Cipher Suites in TLS/SSL (Schannel SSP).

ClientCacheTime

Dieser Eintrag gibt die Lebensdauer von Client-TLS-Sitzungscacheelementen in Millisekunden an. Ab Windows Server 2008 und Windows Vista beträgt die Standardeinstellung 10 Stunden. Der Wert 0 deaktiviert die TLS-Sitzungszwischenspeicherung auf dem Client.

Wenn ein Client zum ersten Mal über den Schannel-SSP eine Verbindung mit einem Server herstellt, wird ein vollständiger TLS/SSL-Handshake ausgeführt. Nach Abschluss werden der geheime Hauptschlüssel, die Verschlüsselungssammlung und Zertifikate im Sitzungscache auf dem jeweiligen Client und Server gespeichert.

Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

EnableOcspStaplingForSni

Das Online Certificate Status-Protokoll (OCSP) ermöglicht es einem Webserver, z. B. Internetinformationsdienste (IIS), den aktuellen Sperrstatus eines Serverzertifikats bereitzustellen, wenn er dieses Zertifikat während des TLS-Handshakes an einen Client sendet. Dieses Feature verringert die Last auf OCSP-Servern, weil der Webserver den aktuellen OCSP-Status des Serverzertifikats zwischenspeichern und an mehrere Webclients senden kann. Ohne dieses Feature würde jeder Webclient versuchen, den aktuellen OCSP-Status des Serverzertifikats vom OCSP-Server abzurufen. Dadurch würde eine hohe Last auf diesem OCSP-Server generiert.

Neben IIS können auch Webdienste über „http.sys“ von dieser Einstellung profitieren, darunter Active Directory-Verbunddienste (AD FS) und Webanwendungsproxy (WAP).

Bei IIS-Websites, die eine einfache sichere Bindung (SSL/TLS) haben, ist die OCSP-Unterstützung standardmäßig aktiviert. Diese Unterstützung ist jedoch nicht standardmäßig aktiviert, wenn die IIS-Website eine oder beide der folgenden Arten von SSL/TLS-Bindungen verwendet:

• Servernamensanzeige anfordern
• Zentralisierten Zertifikatspeicher verwenden

In diesem Fall enthält die Server-Helo-Antwort während des TLS-Handshakes standardmäßig keinen OCSP-Stapelstatus. Dieses Verhalten verbessert die Leistung: Die Windows-Implementierung der OCSP-Stapelung wird auf Hunderte von Serverzertifikaten skaliert. Server Name Indication (SNI) und Central Certificate Store (CCS) ermöglichen es IIS jedoch, auf Tausende von Websites zu staffeln, die möglicherweise Tausende von Serverzertifikaten haben.

Registrierungspfad: HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Fügen Sie den folgenden Schlüssel hinzu:

"EnableOcspStaplingForSni"=dword:00000001

Legen Sie zum Deaktivieren den DWORD-Wert auf „0“ fest:

"EnableOcspStaplingForSni"=dword:00000000

Hashes

TLS/SSL-Hashalgorithmen sollten durch Konfigurieren der Reihenfolge von Verschlüsselungssammlungen gesteuert werden. Details finden Sie unter Konfigurieren der TLS-Verschlüsselungssuitereihenfolge .

IssuerCacheSize

Dieser Eintrag steuert die Größe des Ausstellercache und wird mit der Ausstellerzuordnung verwendet. Der Schannel-SSP versucht, alle Aussteller in der Zertifikatkette des Clients zuzuordnen, nicht nur der direkte Aussteller des Clientzertifikats. Wenn die Aussteller keinem Konto zugeordnet werden – was der Normalfall ist –, versucht der Server möglicherweise, denselben Ausstellernamen wiederholt (hunderte Male pro Sekunde) zuzuordnen.

Um dies zu verhindern, weist der Server einen negativen Cache auf. Wenn also ein Ausstellername keinem Konto zugeordnet ist, wird er dem Cache hinzugefügt, und der Schannel-SSP versucht nicht, den Ausstellernamen erneut zuzuordnen, bis der Cacheeintrag abläuft. Dieser Registrierungseintrag gibt die Cachegröße an. Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden. Der Standardwert ist 100.

Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

IssuerCacheTime

Dieser Eintrag steuert die Länge des Cachetimeoutintervalls in Millisekunden. Der Schannel-SSP versucht, alle Aussteller in der Zertifikatkette des Clients zuzuordnen, nicht nur der direkte Aussteller des Clientzertifikats. Wenn die Aussteller keinem Konto zugeordnet werden – was der Normalfall ist –, versucht der Server möglicherweise, denselben Ausstellernamen wiederholt (hunderte Male pro Sekunde) zuzuordnen.

Um dies zu verhindern, weist der Server einen negativen Cache auf. Wenn also ein Ausstellername keinem Konto zugeordnet ist, wird er dem Cache hinzugefügt, und der Schannel-SSP versucht nicht, den Ausstellernamen erneut zuzuordnen, bis der Cacheeintrag abläuft. Dieser Cache wird aus Leistungsgründen eingerichtet, damit das System nicht laufend versucht, dieselben Aussteller zuzuordnen. Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden. Der Standardwert ist 10 Minuten

Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

KeyExchangeAlgorithm-Schlüsselgrößen

Die folgenden Einträge sind möglicherweise nicht standardmäßig in der Registrierung vorhanden und müssen manuell erstellt werden. Die Verwendung von Schlüsselaustauschalgorithmen sollte durch Konfigurieren der Reihenfolge von Verschlüsselungssammlungen gesteuert werden. Weitere Informationen zu Kryptografiealgorithmen für TLS/SSL-Verschlüsselungssuiten finden Sie unter Verschlüsselungssammlungen in TLS/SSL (Schannel SSP).

MaximumCacheSize

Dieser Eintrag steuert die maximale Anzahl von TLS-Sitzungen, die zwischengespeichert werden soll. Wenn Sie MaximumCacheSize auf 0 aktivieren, wird der serverseitige Sitzungscache deaktiviert, um eine Wiederaufnahme der Sitzung zu verhindern. Das Erhöhen von MaximumCacheSize über die Standardwerte hinaus bewirkt, dass Lsass.exe zusätzlichen Speicher verbraucht. Für jedes Element im Sitzungscache sind normalerweise 2 bis 4 KB Arbeitsspeicher erforderlich. Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden. Der Standardwert ist 20.000 Elemente.

Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Nachrichten – Fragmentanalyse

Dieser Eintrag steuert die maximal zulässige Größe einer akzeptierten TLS-Handshake-Nachricht. Nachrichten, die größer als die zulässige Größe sind, werden nicht akzeptiert und der TLS-Handshake schlägt fehl. Diese Einträge sind in der Registrierung standardmäßig nicht enthalten.

Wenn Sie den Wert auf 0x0aktivieren, werden fragmentierte Nachrichten nicht verarbeitet und der TLS-Handshake schlägt fehl. Dadurch sind TLS-Clients oder -Server auf dem aktuellen Computer nicht mit den TLS-RFCs kompatibel.

Die maximal zulässige Größe kann auf bis zu 2^16 Bytes erhöht werden. Einem Client oder Server zu erlauben, große Mengen an ungeprüften Daten aus dem Netz zu lesen und zu speichern, ist keine gute Idee und verbraucht zusätzlichen Speicher für jeden Sicherheitskontext.

Wurde in Windows 7 und Windows Server 2008 R2 hinzugefügt: Ein Update, das es Internet Explorer unter Windows XP, Windows Vista oder Windows Server 2008 ermöglicht, fragmentierte TLS/SSL-Handshakenachrichten zu analysieren, ist verfügbar.

Registrierungspfad: HKLM\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Messaging

Um eine maximal zulässige Größe von fragmentierten TLS-Handshake-Nachrichten anzugeben, die der TLS-Client akzeptiert, erstellen Sie einen MessageLimitClient entry. Nachdem Sie den Eintrag erstellt haben, ändern Sie den DWORD-Wert auf die gewünschte Bitlänge. Wenn nicht konfiguriert, ist der Standardwert 0x8000 bytes.

Um die maximal zulässige Größe der fragmentierten TLS Handshake-Nachrichten anzugeben, die der TLS-Server akzeptiert, wenn keine Client-Authentifizierung vorliegt, erstellen Sie einen MessageLimitServer entry. Nachdem Sie den Eintrag erstellt haben, ändern Sie den DWORD-Wert auf die gewünschte Bitlänge. Wenn der DWORD-Wert nicht konfiguriert wurde, lautet der Standardwert gleich 0x4000 Bytes.

Um eine maximal zulässige Größe von fragmentierten TLS Handshake Nachrichten anzugeben, die der TLS Server akzeptiert, wenn es eine Client-Authentifizierung gibt, erzeuge einen MessageLimitServerClientAuth entry. Nachdem Sie den Eintrag erstellt haben, ändern Sie den DWORD-Wert auf die gewünschte Bitlänge. Wenn der DWORD-Wert nicht konfiguriert wurde, lautet der Standardwert gleich 0x8000 Bytes.

SendTrustedIssuerList

Standardmäßig wird für jeden neuen Watcher ein neuer Azure Data Explorer-Cluster erstellt, der sich in der gleichen Azure-Region wie der Watcher befindet. Dies kann TLS-Clients helfen, ein geeignetes TLS-Client-Zertifikat auszuwählen. Schannel-basierte TLS-Server senden diese Liste der vertrauenswürdigen Aussteller standardmäßig nicht, da sie die vom Server vertrauenswürdigen Zertifizierungsstellen passiven Beobachtern zur Verfügung stellt und auch die Menge der im Verlauf des TLS-Handshake ausgetauschten Daten erhöht. Wenn Dieser Wert auf 1 festgelegt wird, sendet Schannel-basierte Server ihre Listen von vertrauenswürdigen Ausstellern.

Wird keine Liste vertrauenswürdiger Aussteller gesendet, kann dies Auswirkungen darauf haben, was der Client sendet, wenn er um ein Client-Zertifikat gebeten wird. Wenn z. B. Microsoft Edge eine Anforderung für die Clientauthentifizierung empfängt, zeigt der Browser nur Clientzertifikate an, die mit einer der Zertifizierungsstellen verkettet sind, die vom Server gesendet wird. Wenn der Server keine Liste gesendet hat, zeigt Microsoft Edge alle Clientzertifikate an, die auf dem Client installiert sind.

Dieses Verhalten ist möglicherweise wünschenswert. Wenn PKI-Umgebungen beispielsweise Kreuzzertifikate enthalten, haben Client- und Serverzertifikate nicht dieselbe Stammzertifizierungsstelle. Aus diesem Grund kann Microsoft Edge kein Zertifikat auswählen, das mit einer der Zertifizierungsstellen des Servers verkettet ist. TLS-Clients können ein beliebiges verfügbares Client-Zertifikat anbieten, wenn ein Server nicht die Liste der vertrauenswürdigen Aussteller sendet. Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden.

Standardverhalten der Liste „Send Trusted Issuer“ (Vertrauenswürdigen Aussteller senden)

Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

ServerCacheTime

Dieser Eintrag gibt die Lebensdauer von Server-TLS-Sitzungscacheelementen in Millisekunden an. Der Standardwert ist 10 Stunden. Der Wert 0 deaktiviert die TLS-Sitzungszwischenspeicherung auf dem Server und verhindert die Wiederaufnahme der Sitzung. Das Erhöhen von "ServerCacheTime" über die Standardwerte bewirkt, dass "Lsass.exe" zusätzlichen Arbeitsspeicher beansprucht. Für jedes Element im Sitzungscache sind normalerweise 2 bis 4 KB Arbeitsspeicher erforderlich. Dieser Eintrag ist nicht standardmäßig in der Registrierung vorhanden.

Registrierungspfad: HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL

Standardzeit im Servercache: 10 Stunden

Einstellungen für die TLS-, DTLS- und SSL-Protokollversion

SChannel SSP implementiert Versionen der Protokolle TLS, DTLS und SSL. Verschiedene Windows-Versionen unterstützen verschiedene Protokollversionen. Die systemweit verfügbaren (D)TLS- und SSL-Versionen können durch SSPI-Aufrufer eingeschränkt (aber nicht erweitert) werden, die im AcquireCredentialsHandle-Aufruf die Struktur SCH_CREDENTIALS angeben. Es wird empfohlen, dass SSPI-Aufrufer die Systemstandardeinstellungen verwenden, statt Einschränkungen bei der Protokollversion aufzuerlegen.

Eine unterstützte (D)TLS- oder SSL-Protokollversion kann es in einem der folgenden Status geben:

• Aktiviert: Sofern der SSPI-Aufrufer diese Protokollversion nicht explizit mit SCH_CREDENTIALS Struktur deaktiviert, kann Schannel SSP diese Protokollversion mit einem unterstützenden Peer aushandeln.
• Deaktiviert: Schannel SSP handelt diese Protokollversion nicht aus, unabhängig von den Einstellungen, die der SSPI-Aufrufer angeben kann.

Diese Registrierungswerte werden separat für die Protokoll-Client- und -Serverrollen unter den benannten Registrierungsunterschlüsseln im folgenden Format konfiguriert:

<SSL/TLS/DTLS> <major version number>.<minor version number><Client\Server>

Diese versionsspezifischen Unterschlüssel können unter dem folgenden Registrierungspfad erstellt werden:

• HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols

Hier sind beispielsweise einige gültige Registrierungspfade mit versionsspezifischen Unterschlüsseln:

• HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\SSL 3.0\Client

• HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.2\Server

• HKLM SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\DTLS 1.2\Client

Um eine Systemvorgabe außer Kraft zu setzen und eine unterstützte (D)TLS- oder SSL-Protokollversion auf den Zustand Enabled zu aktivieren, erstellen Sie einen DWORD-Registrierungswert mit dem Namen Enabled mit einem Eintragswert von "1" unter dem Schlüssel corresponding version-specific subkey.

Das folgende Beispiel zeigt, dass der TLS 1.0-Client auf den Status Aktiviert festgelegt wurde:

Um eine Systemvorgabe außer Kraft zu setzen und eine unterstützte (D)TLS- oder SSL-Protokollversion auf den Zustand Disabled zu aktivieren, ändern Sie den DWORD-Registrierungswert von Enabled to "0" unter dem Schlüssel corresponding version-specific subkey.

Das folgende Beispiel zeigt, dass DTLS 1.2 in der Registrierung deaktiviert ist:

Umschalten einer (D)TLS- oder SSL-Protokollversion auf Disabled Zustand könnte dazu führen AcquireCredentialsHandle -Aufrufe fehlschlagen, weil nicht alle Protokollversionen systemweit aktiviert und gleichzeitig von bestimmten SSPI-Aufrufern zugelassen sind. Darüber hinaus könnte die Reduzierung der Enabled (D)TLS- und SSL-Versionen die Interoperabilität mit entfernten Gegenstellen unterbrechen.

Nachdem die Versionseinstellungen für das (D)TLS- oder SSL-Protokoll geändert wurden, werden sie auf Verbindungen angewendet, die mithilfe von Anmeldeinformationshandles hergestellt werden, die durch nachfolgende AcquireCredentialsHandle-Aufrufe geöffnet werden. (D)TLS- und SSL-Client- und Serveranwendungen und -dienste tendieren aus Leistungsgründen dazu, Anmeldeinformationshandles für mehrere Verbindungen wiederzuverwenden. Um diese Anwendungen dazu zu bringen, ihre Credential-Handles wiederzuerlangen, kann ein Neustart der Anwendung oder des Dienstes erforderlich sein.

Diese Registrierungseinstellungen gelten nur für Schannel SSP und wirken sich nicht auf D-TLS- und SSL-Implementierungen von Drittanbietern aus, die möglicherweise auf dem System installiert werden.

Weitere Informationen zum Verwalten der TLS-Verschlüsselungssammlung mit PowerShell finden Sie in der TLS-Befehlsreferenz. Wenn Sie an der Verwaltung von TLS-Einstellungen über Gruppenrichtlinien interessiert sind, lesen Sie die Konfiguration der TLS-Verschlüsselungssuitereihenfolge mithilfe von Gruppenrichtlinien.