Übersicht über TLS – SSL (Schannel SSP)

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

In diesem Thema für IT-Profis werden die Funktionsänderungen im Schannel Security Support Provider (SSP) beschrieben, zu denen die Authentifizierungsprotokolle Transport Layer Security (TLS), Secure Sockets Layer (SSL) und Datagram Transport Layer Security (DTLS) für Windows Server 2012 R2, Windows Server 2012 , Windows 8.1, und Windows 8.

Schannel ist ein Security Support Provider (SSP), der die standardmäßigen Internetauthentifizierungsprotokolle SSL, TLS und DTLS implementiert. Die Security Support Provider-Schnittstelle (Security Support Provider Interface, SSPI) ist eine API, die von Windows-Systemen verwendet wird, um sicherheitsbezogene Funktionen wie Authentifizierungen durchzuführen. Die SSPI dienst als gemeinsame Schnittstelle für mehrere SSPs (Security Support Providers), einschließlich des Schannel SSP.

Weitere Informationen zur Microsoft-Implementierung von TLS und SSL im Schannel-SSP finden Sie in der technischen Referenz zu TLS/SSL (2003).

TLS/SSL-Features (Schannel SSP)

Im Folgenden werden die Features von TLS im Schannel-SSP beschrieben.

TLS-Sitzungswiederaufnahme

Das Transport Layer Security (TLS)-Protokoll, eine Komponente von Schannel-Security Support Provider, wird verwendet, um Daten zu schützen, die zwischen Programmen in einem nicht vertrauenswürdigen Netzwerk gesendet werden. Mit TLS/SSL können Server und Clientcomputer authentifiziert werden, und mit dem Protokoll können Nachrichten zwischen den authentifizierten Parteien verschlüsselt werden.

Geräte, die häufig eine TSL-Verbindung mit Servern aufbauen, müssen sich bei Ablauf einer Sitzung jeweils neu verbinden. Windows 8.1 und Windows Server 2012 R2 unterstützen jetzt RFC 5077 (TLS-Sitzungs fortsetzen ohne Server-Side Zustand). Diese Änderung bewirkt bei Windows Phone- und Windows RT-Geräten folgende Vorteile:

  • Reduzierter Ressourcenbedarf auf dem Server

  • Reduzierte Bandbreite und damit verbesserte Effizienz von Clientverbindungen

  • Geringere Dauer des TLS-Handshakes durch Wiederaufnahme der Verbindung

Hinweis

Die Implementierung der clientseitigen RFC 5077 wurde in Windows 8 hinzugefügt.

Informationen zur Wiederaufnahme zustandsloser TLS-Sitzungen finden Sie im IETF-Dokument RFC 5077.

Anwendungsprotokollverhandlung

Windows Server 2012 R2 und Windows 8.1 unterstützen die clientseitige AUShandlung des TLS-Anwendungsprotokolls, damit Anwendungen Protokolle als Teil der HTTP 2.0-Standardentwicklung nutzen können und Benutzer über Apps, auf denen das PROTOKOLL AUSGEFÜHRT wird, auf Onlinedienste wie Google und Twitter zugreifen können.

So funktioniert's

Client- und Serveranwendungen aktivieren die Erweiterung zum Aushandeln des Anwendungsprotokolls durch das Bereitstellen von Listen unterstützter Anwendungsprotokoll-IDs in absteigender bevorzugter Reihenfolge. Der TLS-Client gibt an, dass er das Aushandeln des Anwendungsprotokolls unterstützt, indem er die ALPN-Erweiterung (Application Layer Protocol Negotiation) mit einer Liste clientseitig unterstützter Protokolle in der ClientHello-Nachricht mit einschließt.

Beim Empfang der TLS-Anfrage des Clients durch den Server wertet dieser die Liste unterstützter Protokolle aus, um ein bevorzugtes Protokoll zu finden, das auch der Client unterstützt. Wenn ein solches Protokoll gefunden wird, antwortet der Server mit der ausgewählten Protokoll-ID und führt den Handshake wie gewohnt fort. Ist kein gemeinsames Anwendungsprotokoll vorhanden, sendet der Server eine Meldung über einen kritischen Handshake-Fehler.

Verwaltung vertrauenswürdiger Aussteller für die Clientauthentifizierung

Wenn die Authentifizierung des Clientcomputers über SSL oder TLS erforderlich ist, kann der Server so konfiguriert werden, dass eine Liste vertrauenswürdiger Zertifikataussteller gesendet wird. Diese Liste enthält die Gruppe der Zertifikataussteller, denen der Server vertraut, und hilft dem Clientcomputer bei der Auswahl des Clientzertifikats, falls mehrere Zertifikate vorhanden sind. Darüber hinaus muss die Zertifikatkette, die der Clientcomputer an den Server sendet, anhand der Liste der konfigurierten vertrauenswürdigen Aussteller überprüft werden.

Vor Windows Server 2012 und Windows 8 konnten Anwendungen oder Prozesse, die den Schannel-SSP verwendet haben (einschließlich HTTP.sys und IIS), eine Liste der vertrauenswürdigen Aussteller bereitstellen, die sie für die Clientauthentifizierung über eine Zertifikatvertrauensliste (Certificate Trust List, CTL) unterstützt haben.

In Windows Server 2012 und Windows 8 wurden Änderungen am zugrunde liegenden Authentifizierungsprozess vorgenommen, sodass:

  • Eine CTL-basierte Verwaltung der Liste vertrauenswürdiger Aussteller wird nicht mehr unterstützt.

  • Das Verhalten, die Liste der vertrauenswürdigen Aussteller standardmäßig zu senden, ist deaktiviert: Der Standardwert des Registrierungsschlüssels SendTrustedIssuerList ist jetzt 0 (standardmäßig deaktiviert) anstelle von 1.

  • Die Kompatibilität mit früheren Versionen von Windows-Betriebssystemen wurde gewahrt.

Hinweis

Wenn System Mapper von der Clientanwendung SendTrustedIssuersaktiviert wird und Sie konfiguriert haben, CN=NT Authority wird diese Systemzuordnung der Ausstellerliste hinzugefügt.

Welchen Wert bietet dies?

Ab Windows Server 2012 wurde die Verwendung der CTL durch eine zertifikatspeicherbasierte Implementierung ersetzt. Dies ermöglicht eine vertrautere Verwaltung mithilfe der vorhandenen Cmdlets zur Zertifikatverwaltung des PowerShell-Anbieters und von Befehlszeilentools wie „certutil.exe“.

Obwohl die maximale Größe der Liste der vertrauenswürdigen Zertifizierungsstellen, die der Schannel-SSP unterstützt (16 KB), unverändert bleibt wie in Windows Server 2008 R2 Windows Server 2012 gibt es in Windows Server 2012 einen neuen dedizierten Zertifikatspeicher für Clientauthentifizierungsaussteller, sodass nicht verknüpfte Zertifikate nicht in der Nachricht enthalten sind.

Funktionsweise

In Windows Server 2012 wird die Liste der vertrauenswürdigen Aussteller mithilfe von Zertifikatspeichern konfiguriert. Ein standardmäßiger globaler Computerzertifikatspeicher und einer, der pro Standort optional ist. Die Quelle der Liste wird wie folgt bestimmt:

  • Wenn ein bestimmter Anmeldeinformationsspeicher für diese Site konfiguriert ist, wird dieser als Quelle verwendet.

  • Wenn keine Zertifikate in dem von der Anwendung definierten Speicher vorhanden sind, prüft Schannel den Speicher Clientauthentifizierungsaussteller auf dem lokalen Computer und verwendet diesen Speicher als Quelle, wenn Zertifikate vorhanden sind. Wenn in keinem der Speicher ein Zertifikat gefunden wird, wird der Speicher für vertrauenswürdige Stämme überprüft.

  • Wenn weder die globalen noch lokalen Speicher Zertifikate enthalten, verwendet der Schannel-Anbieter den Speicher Vertrauenswürdige Stammzertifizierungsstellen als Quelle der Liste der vertrauenswürdigen Aussteller. (Dies ist das Verhalten für Windows Server 2008 R2 .)

Wenn der verwendete Speicher für vertrauenswürdige Stammzertifizierungsstellen eine Mischung aus Stammzertifikaten (selbstsignierte Zertifikate) und Zertifizierungsstellenausstellerzertifikaten enthält, werden standardmäßig nur die Zertifizierungsstellenausstellerzertifikate an den Server gesendet.

Konfigurieren von Schannel für die Verwendung des Zertifikatspeichers für vertrauenswürdige Aussteller

Die Schannel-SSP-Architektur in Windows Server 2012 verwendet standardmäßig die Speicher, wie oben beschrieben, um die Liste der vertrauenswürdigen Aussteller zu verwalten. Es können weiterhin die vorhandenen Cmdlets des PowerShell-Anbieters und von Befehlszeilentools wie „Certutil“ für die Zertifikatverwaltung verwendet werden.

Informationen zum Verwalten von Zertifikaten mithilfe des PowerShell-Anbieters finden Sie unter AD CS Administration Cmdlets in Windows.

Informationen zum Verwalten von Zertifikaten mithilfe des Zertifikatdienstprogramms finden Sie unter certutil.exe.

Informationen dazu, welche Daten einschließlich des anwendungsdefinierten Speichers als Anmeldeinformationen für Schannel definiert sind, finden Sie unter SCHANNEL_CRED structure (Windows).

Standardwerte für Vertrauensmodi

Es gibt drei Vertrauensstellungsmodi für die Clientauthentifizierung durch den Schannel-Anbieter. Der Vertrauensmodus steuert, wie die Überprüfung der Zertifikatkette des Clients ausgeführt wird, und ist eine systemweite Einstellung, die vom REG_DWORD "ClientAuthTrustMode" unter HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\Schannel.

Wert Vertrauensstellungsmodus Beschreibung
0 Maschinenvertrauensstellung (Standard) Erfordert, dass das Clientzertifikat von einem Zertifikat in der Liste der vertrauenswürdigen Aussteller ausgestellt wurde.
1 Exklusive Stammvertrauensstellung Erfordert, dass das Clientzertifikat in der Zertifikatkette auf ein Stammzertifikat zurückgeht, das in dem durch den Aufrufer festgelegten Speicher für vertrauenswürdige Aussteller enthalten ist. Das Zertifikat muss auch von einem Herausgeber in der Liste der vertrauenswürdigen Aussteller ausgestellt worden sein.
2 Exklusive Zertifizierungsstellen-Vertrauensstellung Erfordert, dass das Clientzertifikat in der Zertifikatkette auf ein dazwischenliegendes Zertifizierungsstellenzertifikat oder ein Stammzertifikat zurückgeht, das in dem durch den Aufrufer festgelegten Speicher für vertrauenswürdige Aussteller enthalten ist.

Informationen zu Authentifizierungsfehlern aufgrund von Konfigurationsproblemen vertrauenswürdiger Aussteller finden Sie im Knowledge Base-Artikel 280256.

TLS-Unterstützung für SNI-Erweiterungen (Server Name Indicator, Servernamensanzeige)

Das SNI-Feature stellt eine Erweiterung der Protokolle SSL und TLS dar und ermöglicht die richtige Identifizierung des Servers, wenn zahlreiche virtuelle Images auf einem einzelnen Server ausgeführt werden. Um die Sicherheit der Kommunikation zwischen einem Clientcomputer und einem Server herzustellen, fordert der Clientcomputer ein digitales Zertifikat beim Server an. Nachdem der Server auf die Anforderung geantwortet und das Zertifikat gesendet hat, prüft der Clientcomputer es, verwendet es zur Verschlüsselung der Kommunikation und fährt mit dem normalen Austausch von Anforderungen und Antworten fort. Bei virtuellen Hostszenarien werden jedoch mehrere Domänen, von denen jede über ein eigenes Zertifikat verfügt, auf einem Server gehostet. In diesem Fall kann der Server nicht im Voraus wissen, welches Zertifikat er an den Clientcomputer senden muss. Dank SNI kann der Clientcomputer die Zieldomäne zu einem früheren Zeitpunkt im Protokoll informieren, damit der Server das richtige Zertifikat auswählen kann.

Welchen Wert bietet dies?

Die folgende zusätzliche Funktionalität:

  • Sie können mehrere SSL-Websites mit einer einzelnen IP- und Portkombination hosten.

  • Der Speicherbedarf wird reduziert, wenn mehrere SSL-Websites auf einem einzelnen Webserver gehostet werden.

  • Mehr Benutzer können gleichzeitig die Verbindung zu SSL-Websites herstellen.

  • Sie können Endbenutzern über die Benutzeroberfläche des Computers Hinweise zur Auswahl des richtigen Zertifikats während eines Clientauthentifizierungsprozesses geben.

So funktioniert's

Schannel SSP unterhält einen speicherinternen Cache der Clientverbindungsstatus, die für Clients zulässig sind. Dadurch erhalten Clientcomputer die Möglichkeit, die Verbindung mit dem SSL-Server bei Folgeaufrufen schnell wieder aufzubauen, ohne einen vollständigen SSL-Handshake durchführen zu müssen. Durch diese effiziente Verwendung der Zertifikatverwaltung können im Vergleich zu früheren Betriebssystemversionen mehr Standorte auf Windows Server 2012 gehostet werden.

Die Zertifikatauswahl durch den Endbenutzer wurde verbessert, indem Ihnen die Möglichkeit gegeben wird, eine Liste der Namen möglicher Zertifikataussteller zu erstellen, die Endbenutzern Anhaltspunkte bei der Auswahl liefert. Diese Liste kann mit einer Gruppenrichtlinie konfiguriert werden.

Datagram Transport Layer Security (DTLS)

Das DTLS-Protokoll in der Version 1.0 wurde Schannel Security Support Provider hinzugefügt. Das DTLS-Protokoll sorgt bei der Kommunikation mit Datagrammprotokollen für Datenschutz. Das Protokoll ermöglicht es Client/Server-Anwendungen, so zu kommunizieren, dass Lauschangriffe, Manipulationen oder Nachrichtenfälschung vermieden werden. Das DTLS-Protokoll basiert auf dem TLS-Protokoll (Transport Layer Security) und bietet gleichwertige Sicherheitsgarantien. Daher wird die Notwendigkeit der Verwendung von IPsec oder der Erstellung eines benutzerdefinierten Sicherheitsprotokolls für die Anwendungsschicht verringert.

Welchen Wert bietet dies?

Datagramme werden häufig in Streamingmedien verwendet, z. B. spiele- oder gesicherte Videokonferenzen. Indem Sie das DTLS-Protokoll dem Schannel-Provider hinzufügen, können Sie das gewohnte Windows SSPI-Modell zur Sicherung der Kommunikation zwischen Clientcomputern und -servern nutzen. Zum Konzept von DTLS gehört es, TLS so ähnlich wie möglich zu sein, um einerseits weitere Sicherheitsvorkehrungen zu minimieren und andererseits den Umfang der Code- und Infrastrukturwiederverwendung zu maximieren.

So funktioniert's

Anwendungen, die DTLS über UDP verwenden, können das SSPI-Modell in Windows Server 2012 und Windows 8. Bestimmte Verschlüsselungssammlungen sind für die Konfiguration verfügbar, die der Konfiguration von TLS ähnelt. Schannel nutzt weiterhin den CNG-Kryptografieanbieter, der die in Windows Vista eingeführte FIPS 140-Zertifizierung nutzt.

Veraltete Funktionen

Im Schannel-SSP für Windows Server 2012 und Windows 8 gibt es keine veralteten Features oder Funktionen.

Weitere Verweise