Seite 3: Verschlüsseln per SSL

Inhaltsverzeichnis

Sehr sichere Leitung

Mit der so eingerichteten einfachen Benutzerverwaltung lässt sich zwar festlegen, wer in die WebDAV-Freigabe schreiben darf. Da jedoch die Kennwörter unverschlüsselt übertragen werden, ist es durchaus möglich, fremde Passwörter zu erlauschen. Auch die Nutzdaten sollten besser verschlüsselt über die Leitung gehen.

HTTP bietet mit SSL (Secure Socket Layer) eine sehr sichere Möglichkeit, Daten verschlüsselt zu übertragen. Um SSL im Apache 2.0 zu aktivieren, sind das Modul mod_ssl (Bestandteil des Lieferumfangs) und ein Serverzertifikat notwendig. Das Serverzertifikat authentifiziert den Server gegenüber dem Client und stellt die Schlüssel für die Verschlüsselung bereit.

Wer es sich leisten kann, wird sicher auf ein Zertifikat zurückgreifen, das von einer offiziellen Certificate Authority wie Verisign oder Thawte ausgestellt wurde. Für ein kleines Netzwerk mit wenigen Anwendern und für erste Tests reicht aber ein selbst signiertes Zertifikat. Dieses erledigt die Verschlüsselung genauso gut. Allerdings ist es für Attacken anfälliger, bei denen der Angreifer den Datenverkehr in beiden Richtungen abfängt und so ein eigenes Zertifikat hineinschmuggeln kann (Man in the Middle Attack). Außerdem erscheint beim Benutzer beim ersten Zugriff eine Warndialogbox, dass das Zertifikat nicht von einer vertrauenswürdigen Stelle signiert wurde.

Mit dem Open-Source-Tool OpenSSL erzeugt man in nur vier einfachen Schritten ein selbst signiertes Zertifikat, das sich für SSL in Apache eignet: Schlüssel erzeugen, Zertifizierungsantrag stellen, Schlüssel selbst zertifizieren und Zertifikat installieren.

Zum Erzeugen des geheimen RSA-Schlüssels in der Datei server.key dient der Aufruf

openssl genrsa -des3 -out server.key 1024

Länger als die hier angegebenen 1024 Bit sollte der Schlüssel nicht sein, da einige Browser damit sonst nicht zurechtkommen.

OpenSSL fragt nach einem Kennwort, mit dem es die Schlüsseldatei verschlüsselt, damit nicht jeder den privaten Schlüssel und das daraus generierte Zertifikat verwenden kann. Denn die Kenntnis des privaten Schlüssels ist der Beweis für die Identität des Servers. Wer ihn ausspäht, kann sich als der legitimere Server ausgeben.

Allerdings fragt Apache bei jedem Start nach diesem Kennwort, da er sonst den privaten Schlüssel nicht lesen kann. Wer das Kennwort nicht jedes Mal eintippen will oder den Webserver auch ohne diese Abfrage starten möchte, hat zwei nicht besonders sichere

Lösungen zur Wahl: Entweder gibt er in httpd.conf die Direktive "SSLPassPhraseDialog exec:Programm" aus, die Apache veranlasst, das Programm zu starten, das dann über Stdout das Kennwort zurückliefert. Oder er lässt einfach den Parameter -des3 weg, um die Schlüsseldatei unverschlüsselt abzulegen.

Die zweite Methode ist weniger fehlerträchtig und braucht kein zusätzliches Programm. Um den geheimen Schlüssel vor fremden Augen zu schützen, setzt man einfach die Dateirechte so, dass nur der User root ihn lesen darf:

chmod 400 server.key
chown root server.key

Als Nächstes muss eine Zertifikatssignierungsanfrage (Certificate Signing Request, CSR) erzeugt werden, welche die Daten des eigenen Zertifikates enthält:

openssl req -new -key server.key -out server.csr

Openssl fragt nun diverse Verwaltungsinformationen wie Land und Ort ab, die bei einem selbst signierten Zertifikat größtenteils nicht wichtig sind. Nur der "Common Name" (CN) muss exakt dem Namen des Servers entsprechen, über den die Clients ihn ansprechen, zum Beispiel davserver.example.com. Denn für die Zuordnung des Zertifikats zu einem Server nutzen sie den CN; Unterschiede führen zu einem Warnhinweis auf dem Client.

Diese beiden Schritte sehen genauso aus, wenn man sich das Zertifikat bei einem Dienstleister kauft. Dann reicht man den CSR dort ein und erhält das Zertifikat zurück.

Beim selbst signierten Zertifikat dient der Befehl

openssl x509 -req -days 1825 -in server.csr -signkey server.key -out server.crt

zum Bestätigen des Schlüssels. Er bescheinigt dem Zertifikat eine Gültigkeit von fünf Jahren und legt es im X.509-Format in der Datei server.crt ab.

Die Installation des Zertifikates und des geheimen Schlüssels in Apache ist kein Hexenwerk mehr. Es genügt, den geheimen Schlüssel und das Zertifikat in das richtige Verzeichnis zu kopieren und dann SSL zu aktivieren. Die Verzeichnisse liegen unterhalb des Apache-Konfigurationsverzeichnisses. Der private Schlüssel server.key gehört in das Verzeichnis ssl.key, das Zertifikat server.crt ins Verzeichnis ssl.crt.

Die gängigen Linux-Distributoren konfigurieren Apache bereits so vor, dass die SSL-Konfiguration aus der Datei ssl.conf in httpd.conf eingefügt wird. Der Webmaster muss lediglich über die Direktiven SSLCertificateFile und SSLCertificateKeyFile bekannt geben, wo sich Schlüssel und Zertifikat befinden.

Zum Aktivieren von SSL gibt man Apache beim Start die Option -D SSL mit. Wie das im Startskript /etc/init.d/apache2 geschieht, hängt von der Distribution ab. Das Skript von Suse-Linux liest die Optionen aus der Datei /etc/sysconfig/apache2 ein, in die der Administrator daher die Zeile

APACHE_SERVER_FLAGS="-D SSL"

einträgt. Die Zeile ist recht weit unten in der Datei bereits angelegt, enthält aber bei der Installation noch keine Flags.

Nach einem Neustart des Webservers stehen seine Seiten auch per https zur Verfügung. Beim ersten Aufruf warnt der Browser den Benutzer wegen des selbst signierten Zertifikats. Um das bei den weiteren Zugriffen zu vermeiden, installiert man es nach genauer Prüfung über den Zertifikatmanager des Browsers auf dem Client.

In dieser Konfiguration erlaubt Apache den WebDAV-Zugriff mit und ohne Verschlüsselung. Um SSL zu erzwingen, ist lediglich die Anweisung SSLRequireSSL innerhalb der Directory-Direktive notwendig.

Die gängigen Distributoren installieren Apache normalerweise schon recht sicher. Anders als bei dem im vorherigen Artikel besprochenen IIS sind daher in der Regel keine weiteren Maßnahmen zur Grundsicherung erforderlich. Allerdings ist auch Apache nicht ohne Fehler, sodass hier ebenfalls die oberste Direktive heißt: immer auf dem aktuellen Stand bleiben und Sicherheitspatches einspielen.

Wenn Apache als Fileserver mit WebDAV dient, ist bei der Verwendung von CGI-Skripten besondere Vorsicht geboten. Auch sollte man .htaccess-Dateien über die Direktive "AllowOverride None" verbieten, da damit die Konfiguration durch das Einspielen einer .htaccess-Datei manipuliert werden könnte.