33.4Verschlüsselte Verbindungen (HTTPS)
Für den gewöhnlichen Austausch von Daten zwischen Webserver und Browser kommt das Protokoll HTTP zum Einsatz. Es ist einfach, überträgt aber alle Daten unverschlüsselt. Damit ist es ungeeignet, um Kreditkartennummern oder andere vertrauliche Daten zu übermitteln. Für diesen Zweck kommt das Protokoll HTTPS zum Einsatz. HTTPS vereint die Protokolle Hypertext Transfer Protocol (HTTP) mit Secure Sockets Layer (SSL) und fügt HTTP so Verschlüsselungsfunktionen hinzu. Dieser Abschnitt erklärt, wie Sie Apache für HTTPS-Verbindungen konfigurieren.
HTTPS für jede Webseite
In der Vergangenheit war es üblich, HTTPS nur dann einzusetzen, wenn vertrauliche Daten transportiert wurden. Mittlerweile gibt es aber das Bestreben, möglichst jede Webseite via HTTPS anzubieten. Das soll die Sicherheit des Internets verbessern und die Privatsphäre der Benutzer besser schützen. Google hat sogar angekündigt, HTTPS-Webseiten in Suchergebnissen zu bevorzugen.
Die Initiative Let's Encrypt will noch 2015 damit beginnen, kostenlose Zertifikate zur Verfügung zu stellen. Eigene Kommandos sollen die Installation dieser Zertifikate besonders komfortabel machen. Momentan ist allerdings noch unklar, ob die Zertifikate von allen gängigen Webbrowsern als sicher angesehen werden. Den aktuellen Stand der Initiative können Sie hier feststellen:
Zertifikate
Bevor Sie nun mit den Konfigurationsarbeiten beginnen, brauchen Sie noch ein Server-Zertifikat. Und an dieser Stelle muss ich etwas ausholen ...
Die Verschlüsselung der Daten erfolgt auf der Basis asymmetrischer Verschlüsselungsverfahren. Die Grundidee besteht darin, dass es ein Schlüsselpaar gibt, das aus einem privaten (geheimen) und einem öffentlichen Schlüssel besteht. Der öffentliche Schlüssel eignet sich nur zum Verschlüsseln von Daten. Zum Entschlüsseln ist der private Schlüssel erforderlich. Auf die Details dieser Verfahren gehe ich hier nicht ein – sie wurden schon unzählige Male beschrieben und erklärt, unter anderem auch in der Wikipedia.
Beim Verbindungsaufbau zwischen dem Client (also einem Webbrowser) und dem Server (Apache) wird zuerst auf der Basis einer Zufallszahl vom Client und des öffentlichen Schlüssels vom Server ein gemeinsamer Schlüssel ausgehandelt (Handshake-Verfahren). Dieser Session Key wird dann zur Verschlüsselung der gesamten weiteren Kommunikation eingesetzt.
Der nach heutigem Wissensstand nahezu abhörsichere Datenaustausch ist aber nur ein Punkt zur Verbesserung der Sicherheit. Der ebenso wichtige zweite Punkt besteht darin, dass der Anwender Gewissheit haben muss, dass er mit dem richtigen Partner kommuniziert. Was nützt es, wenn die Daten für das Online-Banking zwar abhörsicher übertragen werden, aber statt zur Bank direkt in die Hände eines Betrügers gelangen?
Aus diesem Grund enthält ein Server-Zertifikat nicht nur den öffentlichen Schlüssel des Servers, sondern auch Daten über die Website sowie eine Art Unterschrift einer Zertifizierungseinrichtung. Deren Aufgabe ist es, die Identität des Zertifikatbewerbers anhand einer Passkopie, eines Gewerbescheins etc. zu überprüfen. Dieser Kontrollprozess macht Server-Zertifikate leider relativ teuer.
Wie vertrauenswürdig ein Zertifikat ist, hängt von der Vertrauenswürdigkeit der Authentifizierungsstelle ab. Bekannte Webbrowser wie Firefox oder Internet Explorer akzeptieren nur Zertifikate, die von etablierten Authentifizierungseinrichtungen ausgestellt wurden (z.B. Verisign oder Thawte). Bei anderen Zertifikaten werden unübersehbare Warnungen angezeigt. Mit etwas Hartnäckigkeit kann man den Webbrowser zwar dennoch dazu bringen, auch unsichere Zertifikate zu akzeptieren, ein florierendes Online-Geschäft ist auf dieser Basis aber unmöglich. Mit anderen Worten: Für ernsthafte Geschäftsanwendungen ist ein autorisiertes Zertifikat unabdingbar.
Tabelle 33.5 fasst die üblichen Dateikennungen für Schlüssel- und Zertifikatsdateien zusammen. Dabei steht pem für Privacy Enhanced Mail. Das ist ein Verfahren für verschlüsselte E-Mails, das sich aber nicht durchgesetzt hat. Das dort definierte PEM-Format ist aber bis heute üblich. *.crt-Dateien enthalten zumeist ebenfalls pem-Dateien. Dank der abweichenden Dateikennung wird die Datei vom Internet Explorer als Zertifikat erkannt.
|
Kennung |
Bedeutung |
|---|---|
|
*.key |
Private-Key-Datei |
|
*.csr |
unsigniertes Zertifikat (Certificate Signing Request) |
|
*.pem |
Container-Datei für ein signiertes Zertifikat oder eine ganze Zertifikatskette |
|
*.crt |
*.pem-Datei mit anderer Kennung (Windows) |
Tabelle 33.5Dateikennungen für Schlüssel- und Zertifikatsdateien
Ein eigenes Zertifikat erstellen
Nachdem ich Sie gerade zu überzeugen versucht habe, ein »richtiges« Zertifikat zu erwerben, erkläre ich Ihnen jetzt, wie Sie ein Zertifikat selbst erstellen können. Es gibt gute Gründe für diesen scheinbaren Sinneswandel: Für erste Experimente reicht ein selbst erstelltes Zertifikat vollkommen aus. Außerdem lässt sich ein eigenes Zertifikat in wenigen Minuten erstellen, während die Erteilung eines autorisierten Zertifikats erfahrungsgemäß tage-, wenn nicht wochenlang dauert. Diese Wartezeit nutzen Sie am besten, indem Sie sich mit den wichtigsten Stolperfallen vertraut machen. Wenn grundsätzlich alles funktioniert, können Sie Ihr eigenes Zertifikat mühelos durch ein »richtiges« ersetzen.
Als Erstes installieren Sie das Paket openssl. Es enthält das gleichnamige Kommando zum Erzeugen, Verwalten und Manipulieren von Schlüsseln und Zertifikaten.
Das folgende Kommando erzeugt eine Datei mit einem privaten 2048-Bit-RSA-Schlüssel. Diesen Schlüssel werden wir zweimal benötigen: einmal zum Erzeugen einer Zertifikatsanfrage (Certificate Signing Request) und dann nochmals zur Signierung.
Achten Sie darauf, dass nur root diese Datei lesen kann! Wenn diese Datei in fremde Hände gerät, ist Ihr Serverzertifikat wertlos, und Sie müssen es widerrufen!
Verschlüsselte Schlüssel
Schlüssel sind wertvoll – deswegen werden sie normalerweise selbst mit einer Passphrase, also mit einem besonders langen Passwort verschlüsselt. Im Englischen spricht man hier deutlich klarer von einem encrypted key. Wenn Sie das möchten, ergänzen Sie das obige openssl-Kommando um die Option -aes-256-cbc. Bei den weiteren Kommandos müssen Sie dann jedes Mal, wenn Sie den Schlüssel nutzen, wiederum dieses Passwort angeben.
Das gilt auch für Apache: Der Webserver braucht den Schlüssel, um das Zertifikat auszulesen. Deswegen fragt Apache nun bei jedem (Neu-)Start nach dem Passwort des Schlüssels. Ein automatisierter Neustart, z.B. bei einem Update, wird so unmöglich.
Um diesem Problem zu entgehen, wird für Apache eine unverschlüsselte Kopie des Schlüssels erzeugt (openssl rsa -in server.key -out server-unencrypted.key). Apache wird nun so konfiguriert, dass er anstelle des verschlüsselten Schlüssels die unsichere Schlüsseldatei verwendet. Diese muss also im Dateisystem des Servers gespeichert werden. Und spätestens jetzt wird klar, dass ein verschlüsselter Schlüssel in unserem Fall nur ein unnötiger Mehraufwand ist, der die Sicherheit nicht steigert. Das heißt aber natürlich nicht, dass verschlüsselte Schlüssel generell nicht zu empfehlen wären – ganz im Gegenteil!
Schon etwas mehr Arbeit macht es, das Zertifikat zu erstellen. Genau genommen erzeugt das folgende Kommando nicht das endgültige Zertifikat, sondern einen Certificate Signing Request, also eine Anfrage zur Signierung des Zertifikats. In das Zertifikat fließt auch der Schlüssel server.key ein (Option -key).
Bei der Ausführung des Kommandos müssen Sie angeben, in welchem Land und in welchem Ort Sie wohnen, wie Sie heißen etc. Entscheidend ist die Frage nach dem Common Name: Hier ist nicht Ihr Name gefragt, sondern der exakte Name Ihrer Website in der Form, in der er für verschlüsselte Verbindungen verwendet wird. Manche Websites verwenden für verschlüsselte Verbindungen eine eigene Subdomain (z.B. banking.ing-diba.de), andere nicht (z.B. www.amazon.de). Wie auch immer, das Zertifikat gilt nur für eine bestimmte Schreibweise. Sie können also beispielsweise ein Zertifikat für www.firma-abc.de nicht auch für firma-abc.de verwenden (oder umgekehrt)! Achten Sie darauf, dass Sie das Challenge-Passwort leer lassen, die entsprechende Frage also mit der Eingabe eines Punktes beantworten.
Mit dem nächsten Kommando unterschreiben Sie Ihr Zertifikat selbst. Bei einem »richtigen« Zertifikat erfolgt dieser Vorgang – natürlich nach einer Kontrolle der von Ihnen vorgelegten Dokumente – durch die Authentifizierungseinrichtung. Zur Unterschrift wird dann der Schlüssel der Authentifizierungsstelle verwendet.
Standardmäßig gilt das fertige Zertifikat nur für 30 Tage. Die Option -days 1900 verlängert den Gültigkeitszeitraum auf circa fünf Jahre:
unable to write random state
Mitunter tritt beim Ausführen des obigen Kommandos der Fehler unable to write random state auf. Der Grund dafür besteht zumeist darin, dass openssl das Heimatverzeichnis nicht findet – oft deswegen, weil Sie zuvor sudo -s ausgeführt haben. Abhilfe schafft export PATH=/root.
Physikalisch gesehen, handelt es sich bei den erzeugten Schlüsseln und Zertifikaten um relativ kleine Textdateien. Um die in einem Zertifikat enthaltenen Daten im Klartext anzuzeigen, verwenden Sie das Kommando openssl x509 -text. Die folgenden Ausgaben sind aus Platzgründen gekürzt:
Bei Debian und Ubuntu werden bei der Installation von Apache automatisch ein Snakeoil-Schlüssel und ein zehn Jahre lang gültiges Snakeoil-Zertifikat erzeugt:
»Snakeoil« wird im Englischen als Bezeichnung für vorgebliche Wunder- oder Allheilmittel verwendet. Das Zertifikat wird erzeugt, damit Web- und Mail-Server ohne das umständliche Erzeugen eigener Zertifikate sofort verschlüsselt verwendet werden können. Die Apache-Konfigurationsdatei default-ssl.conf enthält dementsprechend die folgenden Zeilen:
Natürlich gelten für das Snakeoil-Zertifikat dieselben Einschränkungen wie bei mit openssl selbst erzeugten und signierten Zertifikaten – daher auch der Name. Das Snakeoil-Zertifikat berücksichtigt den bei der Erstellung gültigen Rechnernamen (/etc/hostname). Wenn Sie nach einer Hostname-Änderung ein neues Zertifikat benötigen, rufen Sie das folgende Kommando auf:
make-ssl-cert ist ein relativ simples Script, das auf das vorhin beschriebene openssl-Kommando zurückgreift.
Wenn Sie ein selbst signiertes Zertifikat oder ein Snakeoil-Zertifikat verwenden, zeigt der Webbrowser dem Besucher Ihrer Seite eine Sicherheitswarnung wie in Abbildung 33.2 an. Die Warnung bezieht sich nicht darauf, dass die Verschlüsselung nicht sicher wäre – das ist sie! Vielmehr warnt der Webbrowser, weil die Identität dessen, der das Zertifikat unterzeichnet hat, unbekannt ist. Für technisch unbedarfte Anwender ist das eine Feinheit; sie werden die Webseite als unsicher betrachten. Wenn es Ihnen aber nur darum geht, dass Sie selbst phpMyAdmin sicher verwenden können, um die MySQL-Installation auf dem Server zu administrieren, dann reicht dieses Zertifikat vollkommen aus!
Abbildung 33.2Warnung vor einem selbst signierten Zertifikat
Kostenlose Zertifikate
Einige Anbieter wie https://www.startssl.com und in naher Zukunft voraussichtlich auch https://letsencrypt.org bieten kostenlose bzw. sehr preisgünstige Zertifikate an. Die Besucher Ihrer Website bekommen damit die Gewissheit, dass sie wirklich mit http://ihre-website.de kommunizieren und nicht mit einem anderen Host. Bei derartigen Zertifikaten findet nur eine Domain-Validierung statt. Es wird nicht überprüft, wer für diese Website wirklich verantwortlich ist. Es kann sich also auch jeder Betrüger mühelos ein derartiges Zertifikat beschaffen. Ein weiterer Nachteil ist die begrenzte Gültigkeitsdauer, z.B. maximal ein Jahr bei StartSSL.
Trotz dieser Einschränkungen sind Zertifikate von Firmen wie StartSSL einem selbst erzeugten Zertifikat oft vorzuziehen: Die meisten Webbrowser akzeptieren die Zertifikate ohne die abschreckenden Warnungen, die bei selbst erstellten Zertifikaten üblich sind. Die vom Webbrowser angezeigte Sicherheitsstufe ist zwar gering und es wird kein grüner Balken bzw. ein grünes Schloss samt Firmennamen in der Adressleiste angezeigt, aber immerhin gelingt eine verschlüsselte Kommunikation bei den meisten Webbrowsern auf Anhieb.
Kostenlose bzw. preisgünstige Domain-Zertifikate sind damit ein Kompromiss zwischen vollwertigen, aber teueren Zertifikaten mit Identitätsüberprüfung und selbst erstellten Zertifikaten. Erwarten Sie aber nicht, dass das Erstellen der Zertifikatsdateien einfacher ist als mit dem openssl-Kommando: Gerade die StartSSL-Website ist ausgesprochen unübersichtlich zu bedienen. Um die Kommunikation zwischen StartSSL und dem Browser abzusichern, wird ein eigener Schlüssel auf Ihrem Computer installiert. Dieser Schlüssel ist die Voraussetzung für jeden weiteren Login. Verwenden Sie nach Möglichkeit Firefox: Damit bereitet StartSSL nach meinen Erfahrungen die geringsten Probleme.
Apache-Konfiguration für den HTTPS-Betrieb
Die für das Protokoll HTTPS erforderlichen Apache-Funktionen befinden sich im Modul mod_ssl. Unter Debian oder Ubuntu ist dieses Modul standardmäßig installiert und muss nur aktiviert werden:
Unter Fedora bzw. RHEL müssen Sie das SSL-Modul zuerst installieren:
Apache muss die Schlüssel- und Zertifikatsdatei lesen – daher liegt es nahe, die beiden Dateien in das Apache-Konfigurationsverzeichnis zu kopieren:
Als Nächstes müssen Sie httpd.conf (Fedora, RHEL) um einen VirtualHost-Eintrag erweitern bzw. die entsprechenden Zeilen in eine neue Datei in /etc/apache2/sites-available einfügen. Bei Debian und Ubuntu wird eine entsprechende Musterdatei gleich mitgeliefert (default-ssl). Sie können diese Datei als Ausgangsbasis für eine eigene Site-Datei verwenden, der Sie zur besseren Unterscheidbarkeit von anderen Site-Dateien ssl oder https voranstellen, also beispielsweise ssl.firma-abc.de.
Die folgenden Zeilen zeigen eine minimale Konfiguration, bei der parallel zur Default-Website (HTTP) eine HTTPS-Seite eingerichtet wird. Für beide Seiten kommt dieselbe IP-Adresse zum Einsatz. Die Unterscheidung erfolgt durch die in der VirtualHost-Zeile eingestellte Port-Nummer 443.
SSLEngine on aktiviert die Verschlüsselungsfunktionen. SSLxxxFile gibt an, wo sich die Dateien mit dem Zertifikat und dem privaten Schlüssel befinden. SSLProtocol und SSLCipherSuite bestimmen, welche Version des SSL-Protokolls bzw. welcher Mechanismus zur Erzeugung des gemeinsamen Session Keys eingesetzt werden soll. In der Regel tauschen Apache und der Webbrowser Informationen darüber aus, welche Protokolle sie jeweils unterstützen, und verwenden dann das sicherste Verfahren, das beide beherrschen. Nur wenn es gute Gründe dafür gibt – etwa, weil Sie bestimmte ältere Protokolle/Verfahren nicht akzeptieren möchten –, sollten Sie hier explizite Vorgaben machen.
Zur Aktivierung der HTTPS-Site müssen Sie Apache dazu auffordern, die Konfiguration neu einzulesen. Falls Sie die HTTPS-Datei unter Debian/Ubuntu in einer eigenen Konfigurationsdatei in /etc/apache2/sites-available durchgeführt haben, müssen Sie diese Datei aktivieren:
Wenn Sie erstmals von einem Betrieb ohne SSL auf einen Betrieb mit SSL umstellen, reicht ein Neueinlesen der Konfigurationsdateien nicht aus. Damit das SSL-Modul geladen wird, müssen Sie restart angeben, nicht reload!
Die beiden in der vorhin abgedruckten Apache-Konfiguration verwendeten SSLCertificate-Schlüsselwörter sind sowohl für selbst erstellte Zertifikate als auch für Zertifikate von großen, anerkannten Zertifizierungsstellen (Thawte, VeriSign) ausreichend.
Wenn Sie hingegen ein Zertifikat einer Zertifizierungsstelle verwenden, die dem Webbrowser nicht standardmäßig bekannt ist, müssen Sie an den Browser Zusatzinformationen übergeben, wie er Ihre Zertifikate überprüfen kann. Das ist vor allem bei vielen kleineren Zertifizierungsstellen der Fall, unter anderem auch bei StartSSL. Genau genommen geht es hier um Informationen, welche anerkannte Zertifizierungsstelle wiederum Ihrer Zertifizierungsstelle vertraut. Der Browser muss in der Lage sein, eine Vertrauenskette bis zu einer Zertifizierungsstelle herzustellen, die ihm bekannt ist. Vergessen Sie diese Zusatzfunktionen, beklagt sich der Webbrowser beim Besuch Ihrer Seite, dass der Verbindung nicht vertraut wird, weil keine Zertifikatsausstellerkette angegeben wurde.
Abhilfe schaffen die Schlüsselwörter SSLCertificateChainFile und SSLCACertificateFile, mit denen Sie an Apache Zertifikate Ihrer Zertifizierungsstelle übergeben (Certification Authority, daher die Abkürzung CA). Die erforderlichen Zertifikatsdateien stellt Ihnen Ihre Zertifizierungsstelle zum Download zur Verfügung. Nachdem Sie die Dateien so auf Ihrem Rechner eingerichtet haben, dass Apache sie lesen kann, ändern Sie die Konfiguration wie folgt und führen dann service apache2/httpd reload aus.
Diese Zusatzinformationen ermöglichen es dem Webbrowser, die Korrektheit der von Ihnen benutzten Zertifikate zu überprüfen.
SSL-Einstellungen
Mit dem simplen Einrichten von HTTPS ist es leider nicht getan. Es gibt unzählige Verschlüsselungsverfahren und -versionen, die alle unter dem Begriff HTTPS zusammengefasst werden. Manche von ihnen sind jedoch nicht mehr sicher. Deswegen müssen Sie mit SSLCipherSuite und SSLProtocol explizit angeben, welche Verfahren Ihre Webseite unterstützt und welche sie ablehnt. Eine große Hilfe bei der optimalen HTTPS-Konfiguration ist die folgende Webseite (siehe Abbildung 33.3):
https://www.ssllabs.com/ssltest
Dort können Sie die Adresse Ihrer Webseite angeben. Ein Script überprüft dann die Sicherheit Ihrer Webseite und gibt Optimierungstipps. Dazu gleich ein konkretes Beispiel: Meine Webseite https://kofler.info läuft auf einem Ubuntu-Server mit Apache 2.4. Für HTTPS verwende ich ein Zertifikat von Thawte.
Die relevanten Apache-Konfigurationszeilen sehen wie folgt aus:
Abbildung 33.3Online-Überprüfung der HTTPS-Konfiguration