HTTP-Transportsicherheit
Bei der Verwendung von HTTP zum Transport wird die Sicherheit durch eine Secure Sockets Layer (SSL)-Implementierung bereitgestellt. SSL wird im Internet häufig verwendet, um einen Dienst gegenüber einem Client zu authentifizieren und anschließend Vertraulichkeit (Verschlüsselung) für den Kanal bereitzustellen. In diesem Artikel wird erläutert, wie SSL funktioniert und wie es in Windows Communication Foundation (WCF) implementiert wird.
Standard-SSL
Die Funktionsweise von SSL lässt sich am besten durch ein typisches Szenario erläutern, in diesem Fall die Website einer Bank. Die Website ermöglicht einem Kunden die Anmeldung mit Benutzernamen und Kennwort. Nach der Authentifizierung kann der Benutzer Transaktionen ausführen, z. B. den Kontostand anzeigen, Rechnungen begleichen und Geld auf ein anderes Konto überweisen.
Wenn ein Benutzer die Website zum ersten Mal besucht, startet der SSL-Mechanismus mit dem Client des Benutzers (in diesem Fall der Webbrowser) mehrere Aushandlungen, die als Handshake bezeichnet werden. SSL authentifiziert zuerst die Website der Bank für den Kunden. Dies ist ein wichtiger Schritt, da die Kunden zuerst wissen müssen, ob sie tatsächlich mit der Website kommunizieren und nicht auf einer vorgetäuschte Site ihren Benutzernamen und das Kennwort eingeben sollen. SSL führt diese Authentifizierung mit einem von einer vertrauenswürdigen Stelle, z. B. VeriSign, bereitgestellten SSL-Zertifikat durch. Die Logik ist wie folgt: VeriSign verbürgt sich für die Identität der Bank-Website. Da der Browser VeriSign vertraut, ist die Website vertrauenswürdig. Wenn Sie Informationen zu VeriSign erhalten möchten, klicken Sie auf das VeriSign-Logo. Es wird eine Echtheitserklärung mit Ablaufdatum und Adressat der Ausstellung (die Bank-Website) angezeigt.
Zum Initiieren einer sicheren Sitzung sendet der Client das Äquivalent eines "Hallo" an den Server, zusammen mit einer Liste kryptografischer Algorithmen zum Signieren, Generieren von Hashs sowie zum Verschlüsseln und Entschlüsseln. Als Antwort sendet die Site eine Bestätigung und ihre Wahl einer der Algorithmensammlungen zurück. Während dieses ersten Handshakes senden und empfangen beide Seiten Nonces. Eine Nonce sind zufällig generierte Daten, die zusammen mit dem öffentlichen Schlüssel der Website zum Erstellen eines Hashs verwendet werden. Ein Hash ist eine neue Zahl, die von den beiden Zahlen mit einem Standardalgorithmus, z. B. SHA1, abgeleitet wird. (Der Client und die Website tauschen auch Nachrichten aus, um zuzustimmen, welcher Hashalgorithmus verwendet werden soll.) Der Hash ist eindeutig und wird nur für die Sitzung zwischen dem Client und der Website zum Verschlüsseln und Entschlüsseln von Nachrichten verwendet. Sowohl der Client als auch die Site verfügen über die ursprüngliche Nonce und den öffentlichen Schlüssel des Zertifikats, sodass beide Seiten den gleichen Hash generieren können. Deshalb prüft der Client den vom Dienst gesendeten Hash durch (a) Verwenden des vereinbarten Algorithmus zum Berechnen des Hashs auf Basis der Daten und durch (b) Vergleichen des Hashs mit dem vom Dienst gesendeten Hash. Stimmen die beiden überein, ist sichergestellt, dass der Hash nicht manipuliert wurde. Der Client kann dann diesen Hash als Schlüssel zum Verschlüsseln einer Nachricht verwenden, die noch einen weiteren neuen Hash enthält. Der Dienst kann die Nachricht mit dem Hash entschlüsseln und diesen vorletzten Hash wiederherstellen. Die gesammelten Informationen (Nonces, öffentlicher Schlüssel und andere Daten) sind jetzt beiden Seiten bekannt, und ein letzter Hash (oder Hauptschlüssel) kann erstellt werden. Dieser letzte Schlüssel wird verschlüsselt mit dem vorletzten Hash gesendet. Der Hauptschlüssel wird anschließend verwendet, um Nachrichten für den Rest der Sitzung zu verschlüsseln und zu entschlüsseln. Da sowohl der Client als auch der Dienst den gleichen Schlüssel verwenden, wird dieser auch als Sitzungsschlüssel bezeichnet.
Der Sitzungsschlüssel ist auch als symmetrischer Schlüssel oder als „gemeinsamer geheimer Schlüssel“ gekennzeichnet. Es ist wichtig, dass ein symmetrischer Schlüssel vorhanden ist, da die Berechnung reduziert wird, die von beiden Seiten der Transaktion benötigt wird. Wenn jede Nachricht einen neuen Austausch von Nonces und Hashs erfordern würde, würde sich die Leistung verschlechtern. Daher ist das wichtigste Ziel von SSL die Verwendung eines symmetrischen Schlüssels, der die freie Übertragung von Nachrichten zwischen den beiden Seiten mit höherer Sicherheit und Effizienz ermöglicht.
Die vorangehende Beschreibung ist eine vereinfachte Version des Ablaufs, da die Protokolle je nach Website variieren können. Es ist auch möglich, dass sowohl der Client als auch die Site Nonces generieren, die während des Handshakes algorithmisch kombiniert werden, um mehr Komplexität und demzufolge Schutz für den Datenaustausch zu erreichen.
Zertifikate und Public Key-Infrastruktur
Während des Handshakes sendet der Dienst auch sein SSL-Zertifikat an den Client. Das Zertifikat enthält Informationen wie Ablaufdatum, ausstellende Stelle und URI (Uniform Resource Identifier) der Website. Der Client vergleicht, ob der URI mit dem ursprünglich kontaktierten URI übereinstimmt, und überprüft auch das Datum und die ausstellende Stelle.
Jedes Zertifikat verfügt über zwei Schlüssel, einen privaten und einen öffentlichen Schlüssel, die als Austauschschlüsselpaar bezeichnet werden. Kurz gesagt ist der private Schlüssel nur dem Besitzer des Zertifikats bekannt, während der öffentliche Schlüssel aus dem Zertifikat gelesen werden kann. Jeder der beiden Schlüssel kann zum Verschlüsseln oder Entschlüsseln eines Hashwerts, Hashs oder anderen Schlüssels verwendet werden, jedoch nur als umgekehrte Vorgänge. Wenn z. B. der Client mit dem öffentlichen Schlüssel verschlüsselt, kann nur die Site die Nachricht mit dem privaten Schlüssel entschlüsseln. Analog kann der Client mit dem öffentlichen Schlüssel entschlüsseln, wenn die Site mit dem privaten Schlüssel verschlüsselt. Dies gibt dem Client die Gewissheit, dass die Nachrichten nur mit dem Besitzer des privaten Schlüssels ausgetauscht werden, da nur mit dem privaten Schlüssel verschlüsselte Nachrichten mit dem öffentlichen Schlüssel entschlüsselt werden können. Für die Site wird sichergestellt, dass sie Nachrichten mit einem Client austauscht, der mit dem öffentlichen Schlüssel verschlüsselt hat. Dieser Austausch ist jedoch nur für einen ersten Handshake sicher, daher wird mehr für das Erstellen des tatsächlichen symmetrischen Schlüssels getan. Alle Kommunikationen hängen trotzdem davon ab, dass der Dienst über ein gültiges SSL-Zertifikat verfügt.
Implementieren von SSL mit WCF
HTTP-Transportsicherheit (oder SSL) wird für WCF extern bereitgestellt. Sie können SSL auf zwei Wegen implementieren; der entscheidende Faktor ist, wie die Anwendung gehostet wird:
Verwenden Sie die IIS-Infrastruktur zum Einrichten eines SSL-Diensts, wenn Sie Internetinformationsdienste (IIS) als WCF-Host nutzen.
Wenn Sie eine selbst gehostete WCF-Anwendung erstellen, können Sie mit dem Tool „HttpCfg.exe“ ein SSL-Zertifikat an die Adresse binden.
Verwenden von IIS für Transportsicherheit
IIS 7.0
Informationen zum Einrichten von IIS 7.0 als sicheren Host (mit SSL) finden Sie unter Konfigurieren von SSL (Secure Sockets Layer) in IIS 7.0.
Informationen zum Konfigurieren von Zertifikaten für IIS 7.0 finden Sie unter Konfigurieren von Serverzertifikaten in IIS 7.0.
IIS 6.0
Informationen zum Einrichten von IIS 6.0 als sicheren Host (mit SSL) finden Sie unter Konfigurieren von SSL (Secure Sockets Layer).
Informationen zum Konfigurieren von Zertifikaten für IIS 6.0 finden Sie unter Certificates_IIS_SP1_Ops.
Verwenden von HttpCfg für SSL
Wenn Sie eine selbstgehostete WCF-Anwendung erstellen, verwenden Sie das Tool HttpCfg.exe.
Weitere Informationen zur Verwendung des Tools „HttpCfg.exe“ zum Einrichten eines Ports mit einem X.509-Zertifikat finden Sie unter Vorgehensweise: Konfigurieren eines Ports mit einem SSL-Zertifikat.