SSL-Verbindungen unter Apache 2 einrichten

© Milosh Kojadinovich, 123RF

Sicher serviert

Um lauernden Datendieben gehörig den Tag zu vermiesen, benötigen Apache-Administratoren lediglich drei zusätzliche Direktiven und eine Handvoll Kommandozeilenbefehle. Das reicht bereits aus, um die Kommunikation mit den Browsern per SSL zu verschlüsseln.
Mit den Tipps und Workshops im ADMIN-Magazin 03/2013 sichern Administratoren ihre Webserver und Netze gegen Angriffe ab: gegen Abhören sensibler Informationen, ... (mehr)

Noch immer wandern täglich erschreckend viele sensible Daten im Klartext durch das Internet. Fängt ein Angreifer etwa die Anmeldeinformationen für ein Blog ab, kann er nicht nur den entsprechenden Benutzer ausspionieren, sondern auch in das Blog und somit oft in den Webserver einbrechen. Als Administrator sollte man daher tunlichst alle sensiblen Bereiche einer Website absichern. Das Mittel der Wahl heißt dabei Transport Layer Security, kurz TLS. Mit diesem Verfahren errichten Browser und Webserver selbstständig eine verschlüsselte Verbindung, über die sie dann ihre Kommunikation abwickeln. Die Vorgängerversionen von TLS waren unter dem Namen Secure Sockets Layer, kurz SSL, bekannt, weshalb man noch heute häufig allgemein von SSL-Verbindungen spricht. Wie der Aufbau einer solchen verschlüsselten Verbindung abläuft, verrät der Kasten "Abhörsicher".

Abhörsicher

TLS beziehungsweise SSL sind kryptografische Netzwerkprotokolle (genau genommen sogar Sammlungen aus mehreren Protokollen). Die von einem Browser gelieferten Daten verschlüsselt TLS und schickt sie dann via TCP zum Webserver (siehe Abbildung 2). SSL kann somit nicht nur HTTP-Verkehr, sondern prinzipiell auch die Daten von anderen Anwendungsprotokollen wie etwa FTP chiffrieren. Neben der Verschlüsselung von Daten ermöglicht TLS auch Authentifizierung und Integritätskontrolle. Ein Browser kann somit sicher sein, dass er über eine SSL-Verbindung mit dem richtigen Server spricht, die verschickten Informationen niemand mitlesen kann und diese Daten unverändert beim Gegenüber ankommen. Die dabei jeweils zum Einsatz kommenden Algorithmen dürfen die beiden Parteien in Grenzen selbst wählen. Die Verschlüsselung der Daten übernimmt in jedem Fall ein symmetrisches Verfahren, bei dem ein gemeinsamer Schlüssel sowohl zum Ver- als auch Entschlüsseln dient. Den geheimen Austausch dieses Schlüssels stellt ein Schlüsselaustauschverfahren sicher (wie etwa Diffie-Hellman [1]).

Abbildung 2: SSL bildet eigentlich eine eigene Zwischenschicht im Protokollstapel, in der Praxis zählt man es jedoch in der Regel zur Transport- beziehungsweise TCP-Schicht.

Mit dem Präfix »https://« in der URL zeigt der Benutzer eines Browsers an, dass er eine verschlüsselte Verbindung nutzen möchte. Den nun folgenden Aufbau einer SSL-Verbindung bezeichnet man als SSL-Handshake. Dabei schickt der Client zunächst eine Anfrage an den Server (das sogenannte Client-Hello). Diese Anfrage enthält unter anderem die gewünschte SSL-Version sowie die bevorzugten Algorithmen für den Schlüsselaustausch, die eigentliche Verschlüsselung, die Authentifizierung und die Integritätsprüfung. Ein solches Algorithmen-Gespann bezeichnet man als Cipher Suite.

In seiner Antwort (Server-Hello) teilt der Server dem Client mit, für welche Algorithmen er sich entschieden hat und legt gleich noch ein Zertifikat im X.509-Format bei [2]. Wie bei einer Ausweiskontrolle kann der Client damit feststellen, ob der Webserver tatsächlich derjenige ist, mit dem er kommunizieren möchte.

Abschließend handeln Client und Server einen gemeinsamen Sitzungsschlüssel aus. Mit diesem sogenannten Session Key verschlüsseln beide Parteien dann ihre weitere Kommunikation. Der Session Key gilt ausschließlich für die aktuelle Sitzung, was ein Kapern durch Angreifer erschweren soll.

Die erste Version des Secure Sockets Layer geht übrigens auf die Firma Netscape zurück, die 1995 das Verfahren erstmals in ihrem Browser Navigator einsetzte. Nach der dritten Version übernahm die Internet Engineering Task Force (IETF) die Weiterentwicklung. Sie erhob das Verfahren zu einem Standard und taufte es dabei auch gleich noch in Transport Layer Security (TLS) um.

Im Apache-Webserver kümmert sich das Modul »mod_ssl« um die Verschlüsselung per SSL und TLS. Es liegt seit Version 2 dem Webserver bei und greift auf das OpenSSL-Paket zurück [3]. Die darin enthaltenen Bibliotheken implementieren das SSL-Protokoll und führen somit die eigentliche Verschlüsselung durch. OpenSSL liegt den meisten Linux-Distributionen von Haus aus bei. Windows-Nutzer sollten direkt zum Apache-Binärpaket mit integriertem OpenSSL greifen. Die entsprechende Datei trägt die Bezeichnung »-openssl« und findet sich auf der Download-Seite der Apache Foundation [4] unter »Other files« im Verzeichnis »binaries« und dann »win32« . In CentOS 6.4 ist das Modul »mod_ssl« kein Bestandteil des Apache2-Pakets, man muss es daher explizit über das Paket »mod_ssl« nachladen.

Gesichtskontrolle

Damit der Browser erfährt, mit wem er eine verschlüsselte Verbindung eingeht, schickt der Webserver ihm ein Zertifikat. Ein solches erstellen Administratoren schnell mit dem Kommandozeilenprogramm »openssl« aus dem OpenSSL-Paket. Windows-Nutzer des Apache-Binärpakets finden es im »bin« -Verzeichnis ihrer Apache-Installation. Zertifikate basieren auf asymmetrischen Kryptografieverfahren (Public Key Krypto-grafie), bei dem jede Partei zwei Schlüssel besitzt. Um ein Zertifikat zu erstellen, muss man zunächst für den Server einen sogenannten privaten Schlüssel generieren:

openssl genrsa -aes256 -out privaterschluessel.pem 2048

Der Schlüssel ist in diesem Fall 2048 Bit lang. Zur Sicherheit chiffriert ihn der Befehl noch mit dem AES256-Verfahren, weshalb man sich eine Passphrase (also ein längeres Passwort) ausdenken und eingeben muss. Mit dem privaten Schlüssel in der Hand und der Passphrase im Kopf lässt sich anschließend ein Zertifikat erzeugen:

openssl req -new -x509 -days 365 -key privaterschluessel.pem -out zertifikat.pem

Unter Windows muss man dabei explizit auf die OpenSSL-Konfigurationsdatei verweisen:

openssl req -config ..\conf\openssl.cnf -new -x509 -days 365 -key privaterschluessel.pem -out zertifikat.pem

In jedem Fall erstellt der Befehl ein neues Zertifikat (»-new« ), dessen Aufbau dem X.509-Standard folgt (»-x509« ), 365 Tage lang gültig ist und in der Datei »zertifikat.pem« landet. Nach dem Aufruf des Befehls bekommt man zahlreiche Fragen gestellt. Auch wenn man die Vorgaben nur mit der Eingabetaste abnickt, muss man bei der Frage zum »Common Name« unbedingt den Domainnamen angeben, unter dem später die per HTTPS gesicherten Seiten erreichbar sind. Andernfalls verweigern die Browser der Benutzer später den Verbindungsaufbau. Liegt das Angebot etwa unter »https://login.example.com« , lautet die Antwort auf den Common Name »login.example.com« (Abbildung 1). Das Zertifikat, den privaten Schlüssel und dessen Passphrase sollte man sichern beziehungsweise sich gut merken, sie kommen später noch einmal zum Einsatz.

Abbildung 1: Der Common Name ist nicht der eigene Name, sondern der Domainname.

Trau schau wem

Ein selbst erstelltes Zertifikat hat den Nachteil, dass es die Browser der Benutzer zunächst als unsicher einstufen – schließlich könnte jeder ein solches Zertifikat ausstellen. Die Benutzer müssen es daher beim ersten Zugriff auf den Server explizit als korrekt und vertrauenswürdig einstufen. Bei einem öffentlich betriebenen Webserver empfiehlt es sich deshalb, das Zertifikat von einer entsprechenden Zertifizierungsstelle, der Certificate Authority, beglaubigen zu lassen. Es gibt verschiedene kommerzielle Anbieter, der bekannteste dürfte Verisign Security sein (mittlerweile ein Unternehmen von Symantec, [5]). Die Browser bringen bereits Unterschriften dieser Zertifikatsverwalter mit und winken alle von ihnen unterschriebenen beziehungsweise ausgestellten Zertifikate durch. Wenn die Zertifizierungsstelle eine Zertifikatsanfrage haben möchte, erstellt man diese mit folgendem Befehl:

openssl req -new -key privaterschluessel.pem -out anfrage.csr

Die Anfrage in der Datei »anfrage.csr« muss man dann der Certificate Authority übermitteln. In einem Unternehmensnetzwerk könnte man alternativ die eigenen Zertifikate vorab in die Browser aufnehmen oder gar eine eigene Certification Authority betreiben [6].

In jedem Fall sollte jetzt eine Datei mit dem Zertifikat und eine mit dem privaten Schlüssel vorliegen. Das Duo sammelt man am besten in einem eigenen Unterverzeichnis bei den übrigen Konfigurationsdateien. Letztgenannte liegen auf Linux-Systemen meist unter »/etc/apache2« oder »/etc/httpd« , unter Windows normalerweise im Ordner »conf« des Apache-Verzeichnisses. Dort erstellt man dann ein Unterverzeichnis »ssl« und kopiert das Zertifikat nebst privatem Schlüssel hinein:

mkdir -p /etc/apache2/ssl
cp *.pem /etc/apache2/ssl

Im Normalfall erfordern diese Befehle Root-Rechte.

comments powered by Disqus

Artikel der Woche

Systeme mit Vamigru verwalten

Auch wer nur kleine Flotten von Linux-Servern verwaltet, freut sich über Werkzeuge, die ihm diese Arbeit erleichtern. Vamigru tritt mit diesem Versprechen an. Wir verraten, was es leistet und wie Sie es in der eigenen Umgebung in Betrieb nehmen. (mehr)
Einmal pro Woche aktuelle News, kostenlose Artikel und nützliche ADMIN-Tipps.
Ich habe die Datenschutzerklärung gelesen und bin einverstanden.

Container

Wie setzen Sie Container ein?

  • Gar nicht
  • Docker standalone
  • Docker mit Kubernetes
  • Docker mit Swarm
  • Docker mit anderem Management
  • LXC/LXD
  • Rocket
  • CRI-O auf Kubernetes
  • Container auf vSphere
  • Andere (siehe Kommentare auf der Ergebnisseite)

Google+

Ausgabe /2018

Microsite