Verschlüsselung im WWW
Die sichere Übertragung von Daten im Internet gewinnt immer mehr an
Bedeutung. Nicht nur für Anwendungen wie Online-Shopping oder Banküberweisungen
sind sichere Kommunikationswege absolut unerläßlich. Auch das
Anbieten von vertraulichen Informationen, die nur für einen bestimmten
Personenkreis bestimmt sind, oder die Publikation elektronischer Dokumente
erfordern den Einsatz von Sicherheitsmaßnahmen, um die Daten vor
unbefugtem Zugriff oder unerlaubter Veränderung zu schützen.
In diesem Artikel sollen Möglichkeiten für sichere Verbindungen
im WWW aufgezeigt werden. Nach einer Einführung zum Sicherheitsprotokoll
SSL und den dabei verwendeten Zertifikaten soll anhand eines praktischen
Beispiels die Implementation eines sicheren Webservers demonstriert werden.
Sichere Kommunikation
Schon im ersten Absatz wurde von sicheren Verbindungen gesprochen. Welches
sind nun konkrete Anforderungen an solche Verbindungen? Zuallererst ist
die Vertraulichkeit des Datenaustausches zu nennen. Niemand außer
den Kommunikationspartnern soll in der Lage sein, die übertragenen
Informationen "mitzuhören", z. B. durch Aufzeichnen des Datenstroms
auf dem Netzwerk. Mit den derzeit verwendeten Internetprotokollen werden
ohne Zusatzmaßnahmen selbst solch sensible Daten wie Paßwörter
unverschlüsselt über das Netz übertragen, so daß sie
schon mit mittelmäßigem technischen Geschick mitgeschnitten
werden können. Eine zweite Forderung ist die Sicherung der Integrität
der übermittelten Daten, d. h. sie sollen so beim Empfänger ankommen,
wie sie abgeschickt wurden. So hat das simple Anhängen von sechs Nullen
an den Betrag einer Banküberweisung sicherlich fatale Folgen für
den ahnungslosen Absender. Zuletzt ist noch die Forderung nach der Authentizität
von Verbindungen im Internet zu stellen. Sowohl der Empfänger als
auch der Absender wollen sicher sein, wirklich mit dem gewünschten
Partner und nicht mit einem Dritten zu kommunizieren. Wer sich z. B. die
aktuellen Aktienkurse von einem WWW-Server lädt, möchte natürlich
sichergehen, daß er wirklich mit dem Server der Börse verbunden
ist, um sich auf die Zahlen verlassen zu können. Neben diesen technischen
Anforderungen sollte allerdings nicht vergessen werden, daß ausgefeilte
Protokolle oder aufwendige Software gar nichts nutzen, wenn sie so kompliziert
sind, daß die Anwender weder die Hintergründe (wenigstens in
Grundzügen) durchschauen noch die entsprechenden Programme verstehen
können. Einfache Bedienbarkeit der Programme und anwenderorientierte
Vermittlung der Sicherheitsprobleme im Internet sind Grundvoraussetzungen
für die breite Anwendung von sicherer Kommunikationssoftware.
Die im letzten Absatz genannten technischen Forderungen lassen sich
mit unterschiedlichen kryptographischen Verfahren erfüllen. So werden
vertrauliche Kommunikationswege mit Hilfe von symmetrischen Verfahren verschlüsselt.
Der dafür notwendige Schlüssel wird mit Hilfe asymmetrischer
Verfahren ausgehandelt. Digitale Unterschriften sichern die Authentizität
der Kommunikationspartner. Zur Sicherung der Integrität der Daten
werden Message-Digest-Verfahren verwendet. Die Erläuterung der theoretischen
Grundlagen dieser Verfahren würde den Rahmen des Artikels sprengen,
jedoch sollte der Leser für das weitere Verständnis mit den wesentlichen
Eigenschaften vertraut sein. Eine kurze Einführung findet man unter
[1]. Detaillierte Informationen werden auf dem Server [2] angeboten.
Zertifikate
Grundlegend für das Zustandekommen authentischer Verbindungen sind
Zertifikate. Diese können als "digitale Personalausweise" angesehen
werden, da sie es ermöglichen, auf elektronischem Wege gegenseitig
die Identität der Kommunikationspartner zu überprüfen. Sie
lösen das Problem, bei Anwendung der asymmetrischen Verschlüsselung
die Zugehörigkeit eines public key zu einer Person sicherzustellen.
Zertifikate enthalten allgemeine Informationen zur Person oder Einrichtung
(z. B. Name, Adresse, E-Mail-Adresse usw.) und den eigenen public key.
Diese Informationen werden mit einer Prüfsumme versehen und mit dem
private key einer trusted third party (auch certificate authority
oder kurz CA) unterschrieben, also einer Institution, der beide Kommunikationspartner
vertrauen. Das bedeutet, der public key der CA ist entweder von einer übergeordneten
CA unterschrieben oder weithin publiziert und bekannt, so daß Betrug
ausgeschlossen werden kann. Weiterhin muß die CA so sorgfältig
arbeiten, daß sie erstens ihren eigenen private key äußerst
sorgfältig schützt und zweitens die Identität von Nutzern,
die ein Zertifikat beantragen, genau prüft. Zertifikate werden nach
dem X.509-Standard kodiert. Informationen zum Nutzer selbst werden als
Distinguished Name (DN) bezeichnet. Hierbei werden in genau beschriebenen
Feldern z. B. der Wohnort, der Staat oder der eigentliche Name eingetragen.
Jedes dieser Felder hat eine Kurzbezeichnung. So könnte der Autor
folgenden DN besitzen:
/CN=Daniel Ohst/O=Humboldt-University/ OU=Computer Center/L=Berlin/C=Germany.
SSL-Protokoll
Insbesondere für die Anwendung im World Wide Web hat Netscape das
Secure Socket Layer (SSL)-Protokoll entworfen. Es setzt auf dem TCP/IP-Protokoll
auf und kann deshalb auch für andere Internetdienste, wie z. B. FTP
oder telnet, verwendet werden. Das Protokoll erlaubt verschlüsselte
Verbindungen, Authentisierung mit Zertifikaten nach X.509 von Server und
Client sowie die Sicherung der Integrität der Daten mit Message-Digest-Verfahren.
Dabei werden zahlreiche kryptographische Verfahren unterstützt. SSL
initialisiert eine sichere Verbindung mit einem Handshake-Protokoll zwischen
den Kommunikationspartnern, das zulässige Algorithmen aushandelt,
Zertifikate austauscht und zuletzt einen session key für die Verschlüsselung
festlegt. Ausführliche Informationen hierzu erhält man unter
[3].
Auf der Clientseite wurde SSL in die Browser Netscape Navigator und
Internet Explorer (ab Version 3) integriert. Beide unterstützen verschlüsselte
Verbindungen mit einem SSL-basierten Webserver und die Verwaltung von Zertifikaten.
In den weiteren Ausführungen wird nur noch auf die konkrete Implementation
der aktuellen Version 4.03 des Navigators Bezug genommen, da der Funktionsumfang
und die Nutzung der SSL-Dienste zwischen den verschiedenen Browsern und
Versionen zum Teil stark differieren. In [4] und [5] findet man weitergehende
Hinweise zu diesen Unterschieden, auf die aus Platzgründen hier keine
Rücksicht genommen werden kann.
Nach der Installation von Netscape sind standardmäßig unter
dem Punkt Security Info/Certificates Zertifikate der bekannten internationalen
CAs wie z. B. Verisign integriert. Mit einem WWW-Server, der ein von einer
dieser CAs unterschriebenes Zertifikat besitzt, kann also sofort eine sichere
Verbindung aufgebaut werden. Diese CA-Zertifikate werden im Navigator in
die Gruppe Signers eingeordnet. Unter Websites können
Nutzer selbstunterschriebene Zertifikate eines WWW-Servers akzeptieren.
Unter People und Yours können sogenannte client certificates
geladen werden, die an Personen und nicht an Server gebunden sind. Ab der
Version 4 des Navigators werden Zertifikate auch für das Versenden
sicherer E-Mail nach dem S/MIME-Standard verwendet.
Unter Security Info/Navigator können noch einige Einstellungen
für die Aushandlung sicherer Verbindungen (z. B. verwendete Algorithmen)
vorgenommen werden. Hierbei gelten immer noch US-Exportbeschränkungen,
so daß größere Schlüssellängen von z. B. 128
bit nicht genutzt werden können, obwohl die Algorithmen implementiert
sind.
SSL-Implementationen
Wer selbst einen WWW-Server aufbauen will, zu dem sichere Verbindungen
möglich sind, hat die Wahl zwischen der Implementation auf der Basis
frei verfügbarer Produkte oder einer kommerziellen Lösung. Beide
haben Vor- und Nachteile.
Zahlreiche Firmen, darunter selbstverständlich auch die beiden
großen Browserhersteller, bieten entsprechende Server an. Ein bekannter
Vertreter ist der Enterprise-Server von Netscape. Eine Sonderrolle nimmt
der Secure Server von Stronghold ein, der kommerziell vertrieben wird,
jedoch auf freier Software basiert. Die Kosten für einen kommerziellen
Server belaufen sich auf ca. $ 500 - 2000. Weiterhin schlägt ein Serverzertifikat
einer anerkannten CA mit ca. $ 400 pro Jahr zu Buche. Wer Clientzertifikate
zur Autorisierung benutzen will, muß noch einmal ca. $ 20 pro Nutzer
und Jahr dazurechnen.
Das frei verfügbare SSLeay-Paket von Eric Young und Tim Hudson
hat sich als Quasistandard bei der Nutzung von SSL durchgesetzt. Es ist
eine umfangreiche Sammlung kryptographischer Algorithmen und enthält
Programme und Skripte zur Verwaltung eigener CAs und Zertifikate. SSLeay
ist im Sourcecode für UNIX- und Windowssysteme zu erhalten. Um geeignete
Applikationen nutzen zu können, wurden Patches für die wichtigsten
Internetdienste erarbeitet, so für den hervorragenden Apache-Webserver,
aber auch für telnet- oder ftp-Dienste.
Einer Firma, die ihren Katalog nun auch im Internet anbieten und den
Kunden Gelegenheit zur sicheren Onlinebestellung geben will, ist sicherlich
mit einem kommerziellen Angebot am besten gedient. Die Server besitzen
grafische Oberflächen zur Administration, und das Einbinden des Serverzertifikats
ist auch für Laien durchführbar. Allerdings ist über einen
Zeitraum von drei Jahren mit Kosten für Software, Updates und Zertifikate
von ca. $ 4000 zu rechnen, was schon ein recht beachtlicher Betrag ist.
Wer für seine Einrichtung sichere Weblösungen installieren
will, wenig oder gar kein Geld, aber dafür Kenntnisse in der UNIX-Administration
und im Sicherheitsmanagement besitzt (z. B. nach dem Lesen dieses Artikels),
kann auf freie Softwarelösungen zurückgreifen. Eine solche soll
im nächsten Abschnitt praktisch demonstriert werden. Hierbei ist jedoch
ein erhöhter Personalbedarf einzukalkulieren, da das Betreiben einer
eigenen CA klar definierte Handlungsabläufe und Sicherheitsmaßnahmen
erfordert.
Auf der Basis frei verfügbarer Software soll im folgenden ein Beispielprojekt
beschrieben werden, das zum Ziel hat, verschlüsselte Verbindungen
zu einem Webserver aufzubauen. Weiterhin sollen sich Server und Clients
gegenseitig authentifizieren können. Voraussetzung für die Implementation
ist die Verwaltung einer eigenen CA, die Certificate Signing Requests entgegennimmt
und Serverzertifikate ausstellt. Nutzer sollen über ein Formular Clientzertifikate
beantragen können. Nach einem bestimmten Verfahren wird dann die Identität
geprüft, der Request durch die CA unterschrieben und an den Nutzer
zurückgesandt.
Als Hardwareplattform wird ein PC mit einer aktuellen Linuxdistribution
(Kernel 2.0.30) vorausgesetzt. Alle Installationsanweisungen sind jedoch
ohne Probleme auf andere Plattformen und Betriebssysteme, z. B. SUN Solaris
2.5.1, zu übertragen. Es kommt das SSLeay-Paket in der Version 0.8.1
zur Anwendung, was nach der Kompilierung unter /usr/local/ssl installiert
sein sollte. Als Webserver kommt Apache in der Version 1.2.4 zum Einsatz.
Er muß vor dem Übersetzen mit der Version 1.11 von Apache-SSL
gepatcht und unter /usr/local/httpsd installiert werden. Als Client wurde
der Netscape Navigator 4.03 verwendet. Wenn man einige kleine Bugs in Kauf
nimmt, kann auch die Version 3.01 eingesetzt werden. Der Internet Explorer
unterstützt zwar auch alle SSL-Features, unterscheidet sich jedoch
zum Teil stark in der Zertifikatsverwaltung und soll deshalb in diesem
Beispiel keine Verwendung finden. Auch kann nicht auf jedes Detail der
Konfiguration (insbesondere des WWW-Servers) eingegangen werden. Die obengenannte
Software und umfangreiche Installationshinweise kann man sich unter [4]
und [6] herunterladen.
CA-Verwaltung
Der Rechner, auf dem sich die CA-Schlüssel befinden und auf dem Zertifikate
ausgestellt werden, ist idealerweise physikalisch abgeschirmt und besitzt
keinen Netzanschluß. Es ist klar, daß ein Eindringling, der
in der Lage ist, den CA-Rechner und die dazugehörigen Daten zu kompromittieren,
die Sicherheit des ganzen Systems in Frage stellt. Datentransfers sollten
deshalb per Diskette stattfinden. Zu Testzwecken ist jedoch die Installation
auf dem Rechner des WWW-Servers ratsam, um Fehlkonfigurationen schneller
beheben zu können.
Der erste Schritt nach der Installation von SSLeay sollte das Editieren
der Datei ssleay.cnf im lib-Verzeichnis (immer bezogen auf das Installationsverzeichnis
/usr/local/ssl) sein. Hier werden Voreinstellungen zu Schlüssellänge,
Gültigkeitsdauer und Bestandteilen des DN vorgenommen. Der Eintrag
dir sollte in einen absoluten Pfad geändert werden. Policies
legen z. B. fest, ob Zertifikate nur für Nutzer der eigenen Abteilung
oder auch der gesamten Einrichtung ausgegeben werden können. Weitere
Informationen hierzu erhält man in [5].
Mit
dem Aufruf von bin/CA.sh - newca erzeugt man eine Verzeichnisstruktur
mit dem gewählten Namen und ein Schlüsselpaar. Die Passphrase
sollte möglichst lang sein und ist der einzige Schutz des private
key. Sie ist deshalb unter allen Umständen geheimzuhalten und niemals
auf dem Rechner selbst zu speichern. Danach wird der DN der CA festgelegt.
Der Common Name könnte z. B. der Domainname Ihrer Einrichtung sein
(rz.hu-berlin.de). Damit der Browser alle Zertifikate, die von dieser CA
ausgestellt wurden, ohne weitere Sicherheitsabfragen akzeptiert, muß
das Zertifikat im Browser installiert werden. Dazu muß in srm.conf
von Apache die Zeile AddType application/x-x509-ca-cert .ca eingetragen
werden. Das CA-Zertifikat, das als cacert.pem im ASCII-Format vorliegt,
muß zuerst mit der Kommandozeile bin/x509 -in cacert.pem -out
cacert.der -outform DER in ein für den Navigator verständliches
Binärformat konvertiert werden. Dieses kann dann unterhalb des Dokumentenverzeichnisses
des Servers abgelegt und heruntergeladen werden, was auch auf unverschlüsseltem
Wege geschehen kann. Man sollte den Nutzern jedoch auf jeden Fall auf einem
sicheren Wege (z. B. in einem Rundschreiben oder einer Zeitung) die Prüfsumme
des Zertifikats zur Kontrolle übermitteln. Nach einem kurzen Dialog
und der Vergabe eines Namens für die CA erscheint dieser auch schon
in der Liste der Signers (Abb. 1: Akzeptierte CA-Zertifikate in
Netscape 4.03).
Ein
selbsterstelltes CA-Zertifikat im Navigator könnte dann z. B. wie
in Abb. 2 (CA-Zertifikate im Netscape Navigator) aussehen.
Der nächste Schritt ist die Erstellung eines Serverzertifikats.
Mit dem Befehl bin/CA.sh -newreq wird ein Certificate Signing Request
(CSR) und ein neues Schlüsselpaar erzeugt. In der Datei newreq.pem
befindet sich dann der CSR und der verschlüsselte private key. Mit
bin/CA.sh -sign wird das eigentliche Zertifikat in der Datei newcert.pem
erzeugt, nachdem das Paßwort für den CA private key und die
Angaben für den DN geprüft wurden. Dieses Zertifikat kann nun
im WWW-Server verwendet werden.
Bei der Apache-Konfiguration ist es günstig, den sicheren Server
auf Port 443 als VirtualHost zu deklarieren. Die SSL-Optionen, wie Pfade
zu CA- und Serverzertifikaten, sind auszufüllen. Bei jedem Start des
Servers ist nun das Paßwort für den private key des Zertifikats
einzugeben. Zum jetzigen Zeitpunkt ist es schon möglich, sichere HTTP-Verbindungen
aufzubauen, bei denen sich der Server gegenüber dem Nutzer durch Angabe
seines Zertifikats authentisiert. Auch Anwender, die das CA-Zertifikat
nicht geladen haben, können das Zertifikat nach einem kurzen Netscape-Dialog
in die Gruppe Websites aufnehmen und ebenfalls sicher kommunizieren.
Client-Zertifikate
Zuletzt soll noch das herkömmliche Authentisierungsschema für
Webseiten (Name/Paßwort) durch die Anwendung von Clientzertifikaten
verbessert werden. Hierzu ist etwas mehr Arbeit nötig, da ein Schlüsselpaar
im Navigator erzeugt, daraus ein CSR generiert und an die CA-Verwaltung
geschickt werden muß. Diese prüft die Identität, stellt
das Zertifikat aus und schickt Informationen zu dessen Download an den
Anwender zurück.
Zur Beantragung eines Zertifikats muß der Nutzer ein HTML-Formular
ausfüllen, in das er seine persönlichen Angaben einträgt.
Ein Beispiel findet man unter [7] als cert.html. Geändert werden muß
der URL des Scripts im FORM-Tag. Nach dem Abschicken erzeugt der Navigator
durch das spezielle <KEYGEN>-Tag ein Schlüsselpaar. Auch hier steht
durch Exportbeschränkungen nur die Schlüssellänge 512 bit
zur Verfügung. Der private key wird in einer Datenbank gespeichert
und sollte durch ein Paßwort geschützt werden. Danach wird ein
CSR erzeugt und an das angegebene Perl-Skript weitergeleitet. Auch hier
kann man als Anregung für eigene Implementationen das Programm generate.pl
unter [7] nutzen, das bezüglich der Adressen und Pfade an die eigenen
Gegebenheiten angepaßt werden muß. Es wird eine Datei im /tmp-Verzeichnis
erzeugt, die den CSR in einem speziellen Netscape-Format enthält.
Weiterhin wird im Verzeichnis $HOME/requests des Nutzers webadm
eine Datei angelegt, die den CSR sowie die generierte Zufallszahl und die
Telefonnummer enthält. Die Identitätsprüfung könnte
nun darin bestehen, daß der Nutzer zurückgerufen wird und die
richtige Zufallszahl nennen muß. Danach wird das Zertifikat erzeugt
und dem Nutzer der URL mitgeteilt. Eine einfachere Lösung besteht
darin, den gesamten Prozeß zu automatisieren und eine E-Mail mit
den Downloadinformationen zu versenden, was natürlich keiner echten
Identitätsprüfung entspricht. Eine aufwendige, aber sehr sichere
Variante ist das Einreichen von notariell beglaubigten Identitätsunterlagen.
In der Praxis sieht es meist so aus, daß für Clientzertifikate
unterschiedliche Sicherheitslevel angeboten werden und jeder selbst entscheiden
kann, welche Sicherheitsanforderungen bezüglich der Zertifikate seine
Anwendung benötigt.
Aus
der von generate.pl erzeugten Datei kann mit dem Kommando ca
-spkac "CSR-Datei" -out "Clientcert.cln" das Zertifikat
für den Nutzer erstellt werden, das dann unterhalb der Dokumentenhierarchie
des WWW-Servers erreichbar sein muß. Zum Download muß noch
der MIME-Type application/x-x509-user-cert .cln in die Datei srm.conf
eingetragen werden. Nach erfolgreichem Laden steht das neue Zertifikat
unter der Gruppe Yours im Netscape Navigator.
Um nun auch Client-Zertifikate für die Autorisierung für
Seiten oder Verzeichnisse auf dem WWW-Server nutzen zu können, müssen
noch einige SSL-Optionen in der Datei httpd.conf gesetzt werden.
Der Pfad zu dem oder den CA-Zertifikaten muß entsprechend eingetragen
und die Optionen SSLFakeBasicAuth und SSLVerifyClient gesetzt
sein. Eintragungen in access.conf oder .htaccess werden entsprechend der
herkömmlichen Autorisierung vorgenommen. Unterschiedlich ist der Aufbau
der Accountdateien. Anstatt des Usernamens wird der entsprechende DN eingetragen.
Ein Paßwort ist nicht mehr notwendig, so daß dort der Standardstring
xxj31ZMTZzkVA verwendet wird, um den syntaktischen Anforderungen
zu genügen. Wenn nun der Navigator auf eine Seite zugreifen will,
die die Angabe eines Clientzertifikats erfordert, erscheint eine ähnliche
Aufforderung wie sie in Abb. 3 (Anforderung eines Clientzertifikates) dargestellt
ist.
Zum Abschluß dürfen natürlich auch einige kritische
Anmerkungen zur verwendeten Lösung nicht fehlen. Zum einen sind die
durch die Exportbeschränkungen zugelassenen Schlüssellängen
(symmetrisch 40 bit) für hohe Sicherheitsanforderungen keinesfalls
mehr als ausreichend anzusehen. Hier könnte die Verwendung von SSL-Proxies
helfen [8]. Zum anderen ist der Aufbau einer CA aufwendig, insbesondere
in bezug auf das strikte Einhalten der Sicherheitsvorkehrungen. Möglich
wäre der Anschluß an eine übergeordnete CA, z. B. die DFN-PCA
[9]. Leider werden in diesem Projekt z. Z. nur PGP-Schlüssel unterschrieben.
Zertifikate nach X.509 für SSL-Anwendungen sind erst in Vorbereitung.
Aus diesem Grunde wird das RZ noch in diesem Jahr den Testbetrieb einer
eigenen CA für die Universität aufnehmen.
Weiterführende Informationen:
[1] http://www2.rz.hu-berlin.de/~h0444saa/rdi/
[2] http://www.cs.hut.fi/crypto/
[3] http://home.netscape.com/eng/ssl3/
[4] http://www.psy.uq.oz.au/~ftp/Crypto/
[5] http://www.opengroup.org/RI/www/prism/wwwj/
[6] http://www.apache.de/
[7] http://www2.rz.hu-berlin.de/~h0444saa/ssl/
[8] http://stronghold.ukweb.com/
[9] http://www.cert.dfn.de/dfnpca/