Netz - Rettung - Recht (Artikel mit Tag Apache)

phpMyAdmin nur für einen vhost einbinden

nospam@example.com (Thomas Hochstein) — Fri, 08 Sep 2017 06:50:00 +0000

phpMyAdmin verwende ich seit über einem Jahrzehnt, um bequem auf die Datenbanken auf meinen verschiedenen Webspaces zugreifen zu können (und diesen Zugriff ggf. auch anderen Nutzern zu ermöglichen). Dabei nutze ich der Einfachheit halber das jeweilige Debian-Paket - je mehr Webapplikationen nicht gesondert aktualisiert werden müssen, desto besser.

Die Standardinstallation hat - aus meiner Sicht - allerdings einen Nachteil: sie macht phpMyAdmin für alle vhosts verfügbar, d.h. unter allen auf dem Server gehosteten “Domains” aufrufbar. Manchmal mag das praktisch sein, wenn man bspw. so für jeden Kunden scheinbar “sein” phpMyAdmin mitliefert; mir gefällt das aber nicht so gut, und sei es nur, weil phpMyAdmin (wie jede verbreitete Webapplikation) regelmäßig “angegriffen” wird (sprich: Bots rufen die URL auf und suchen nach Schwachstellen oder versuchen, das Passwort zu erraten). Lieber würde ich phpMyAdmin nur unter einer “Domain” - einem vhost aufrufbar machen.

Glücklicherweise lässt sich das ohne großen Aufwand machen.

Standardmäßig legt Debian (Stretch) bei der Installation des Pakets eine entsprechende Konfiguration unter /etc/apache2/conf-available/phpmyadmin.conf an und aktiviert sie durch einen Symlink in /etc/apache2/conf-enabled/. Diese Datei hat folgenden Inhalt:

# phpMyAdmin default Apache configuration

Alias /phpmyadmin /usr/share/phpmyadmin

<Directory /usr/share/phpmyadmin>
    Options SymLinksIfOwnerMatch
    DirectoryIndex index.php

    <IfModule mod_php5.c>
        <IfModule mod_mime.c>
            AddType application/x-httpd-php .php
        </IfModule>
        <FilesMatch ".+\.php$">
            SetHandler application/x-httpd-php
        </FilesMatch>

        php_value include_path .
        php_admin_value upload_tmp_dir /var/lib/phpmyadmin/tmp
        php_admin_value open_basedir /usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/:/usr/share/php/php-gettext/:/usr/share/php/php-php-gettext/:/usr/share/javascript/:/usr/share/php/tcpdf/:/usr/share/doc/phpmyadmin/:/usr/share/php/phpseclib/
        php_admin_value mbstring.func_overload 0
    </IfModule>
    <IfModule mod_php.c>
        <IfModule mod_mime.c>
            AddType application/x-httpd-php .php
        </IfModule>
        <FilesMatch ".+\.php$">
            SetHandler application/x-httpd-php
        </FilesMatch>

        php_value include_path .
        php_admin_value upload_tmp_dir /var/lib/phpmyadmin/tmp
        php_admin_value open_basedir /usr/share/phpmyadmin/:/etc/phpmyadmin/:/var/lib/phpmyadmin/:/usr/share/php/php-gettext/:/usr/share/php/php-gettext/:/usr/share/javascript/:/usr/share/php/tcpdf/:/usr/share/doc/phpmyadmin/:/usr/share/php/phpseclib/
        php_admin_value mbstring.func_overload 0
    </IfModule>

</Directory>

# Authorize for setup
<Directory /usr/share/phpmyadmin/setup>
    <IfModule mod_authz_core.c>
        <IfModule mod_authn_file.c>
            AuthType Basic
            AuthName "phpMyAdmin Setup"
            AuthUserFile /etc/phpmyadmin/htpasswd.setup
        </IfModule>
        Require valid-user
    </IfModule>
</Directory>

# Disallow web access to directories that don't need it
<Directory /usr/share/phpmyadmin/templates>
    Require all denied
</Directory>
<Directory /usr/share/phpmyadmin/libraries>
    Require all denied
</Directory>
<Directory /usr/share/phpmyadmin/setup/lib>
    Require all denied
</Directory>

Entscheidend ist dabei die Zeile Alias /phpmyadmin /usr/share/phpmyadmin - sie legt (global, da in der Serverkonfiguration eingebunden) für jeden vhost einen Alias an, der beim Aufruf von http://meine-domain.example/phpmyadmin/ nun eben phpMyAdmin anzeigt.

Will man diese Funktionalität auf einen vhost beschränken, genügt, es, die globale Konfiguration mit a2disconf phpmyadmin abzuschalten und sie danach stattdessen in einen vhost (oder auch mehrere) einzubinden:

<VirtualHost ${APACHE_IP4}:80 ${APACHE_IP6}:80>
    ServerName mein-vhost.example
    DocumentRoot /var/www/mein-vhost.example

    Include /etc/apache2/conf-available/phpmyadmin.conf
</VirtualHost>

Sinnvoll mag es zudem sein, die Konfiguration nur für einen vhost einzubinden, bei dem SSL aktiviert ist.

Dann noch ein service apache2 reload (oder systemctl reload apache2, oder apache2ctl graceful), und jetzt ist phpMyAdmin nur noch unter http://mein-vhost.example/phpmyadmin/ abrufbar - und nirgendwo sonst.

Wer ganz andere Lösungen umsetzen möchte als der Debian-Default es vorsieht (bspw. ein Aufruf über https://phpmyadmin.mein-vhost.example/), der kann die Debian-Konfiguration schlicht als Ausgangspunkt nehmen und die entscheidenden Teile in einen passenden vhost kopieren.

Webserver-Tuning

nospam@example.com (Thomas Hochstein) — Tue, 22 Aug 2017 05:40:00 +0000

Alle paar Monate wieder turnt ein - weniger rücksichtsvoller - Crawler vorbei und spidert sich zügig durch alle Einträge meines Blogs. Damit brachte er meinen bisherigen Server gerne an den Rand seiner Leistungsfähigkeit, durfte dieser doch für jeden Link einen php-cgi-Prozess starten. Man merkte das recht schnell an den steigenden Antwortzeiten, und auch interaktiv auf der Shell machte sich die steigende load bemerkbar. Am Ende blieben meist einige php-cgi-Prozesse übrig, die man dann manuell mittels kill entsorgen durfte. (Vielleicht lag auch hier das eigentliche Problem, dass nämlich die genutzten Ressourcen nicht wieder freigegeben wurden. Hinter die Einzelheiten bin ich nie so recht gekommen.)

Die brandneue Maschine hingegen sollte durch FastCGI und massenhaft RAM sowie schnelle SSDs einem solchen Ansturm (auch bei weiterer Verwendung des doch eher schwergewichtigen Apachen) besser gewachsen sein - dachte ich mir. Bis eines Freitagmorgens die E-Mails des Monitoring-System eingingen, die mir mitteilten, dass der Webserver nicht mehr auf Anfragen reagiert. Gar nicht mehr.

Der Grund dafür fand sich schnell im Log:

[mpm_event:error] [pid 1365:tid 139856442496192] AH00484: server reached MaxRequestWorkers setting, consider raising the MaxRequestWorkers setting

Alle Threads des Webservers waren mit Anfragen ausgelastet (und offensichtlich wurden sie auch nicht mehr freigegeben - oder der Apache hatte sich “verschluckt”). Ein service apache2 restart löste daher das Problem; Zeit aber für einen Blick in die Konfiguration - vielleicht sollte man etwas an den Limits drehen (“consider raising the MaxRequestWorkers setting “).

Apache Event-MPM

Für das verwendete MPM findet sich die entsprechende Konfiguration (unter Debian) in /etc/apache2/mods-enabled/mpm_event.conf; sie sieht per default so aus:

# event MPM
# StartServers: initial number of server processes to start
# MinSpareThreads: minimum number of worker threads which are kept spare
# MaxSpareThreads: maximum number of worker threads which are kept spare
# ThreadsPerChild: constant number of worker threads in each server process
# MaxRequestWorkers: maximum number of worker threads
# MaxConnectionsPerChild: maximum number of requests a server process serves
<IfModule mpm_event_module>
       StartServers              2
       MinSpareThreads          25
       MaxSpareThreads          75
       ThreadLimit              64
       ThreadsPerChild          25
       MaxRequestWorkers       150
       MaxConnectionsPerChild    0
</IfModule>

Es werden also standardmäßig zwei Serverprozesse (StartServers)gestartet; jeder hat 25 Threads (ThreadsPerChild), also können 50 parallele Anfragen abgearbeitet werden. Sobald weniger als 25 freie Threads zur Verfügung stehen (MinSpareThreads), werden weitere Serverprozesse gestartet, bis zum Maximum von 150 Threads (MaxRequestWorkers) - das entspricht sechs Prozessen (mit je 25 Threads). Sobald mehr als 75 Threads unbeschäftigt sind (MaxSpareThreads), werden Serverprozesse wieder zurückgefahren.

150 Prozesse für eine Vielzahl von Webpräsenzen erschien mir wirklich nicht viel; ich habe (angesichts des zur Verfügung stehenden Speichers) daher etwas nachgelegt:

<IfModule mpm_event_module>
        ServerLimit               40
        StartServers               5
        MinSpareThreads          100
        MaxSpareThreads          250
        ThreadLimit               64     
        ThreadsPerChild           25
        MaxRequestWorkers       1000
        MaxConnectionsPerChild  1000
</IfModule>

Wir fangen jetzt also mit mit 125 Threads an (fünf Server mit je 25 Threads) und halten minimal 100 Threads bereit, maximal 250 - eine Lastspitze kann daher besser abgefedert werden, weil von Anfang an mehr Ressourcen bereitstehen und schneller zusätzliche Ressourcen hochgefahren werden). Maximal können dann 1.000 Threads laufen (statt vorher 150) - zu diesem Zweck muss auch ServerLimit erhöht werden, das per Default auf 16 steht - denn 1.000 Threads brauchen bei 25 Threads pro Prozess 40 Prozesse (mit dem Default von 16 Prozessen kommt man daher maximal auf 400 Threads).

Außerdem lasse icn jeden Thread nach 1.000 beantworteten Anfragen neu starten (MaxConnectionsPerChild); so können sich Speicherlecks nicht zu Problemen auswachsen.

Seitdem war der Webserver jedenfalls nicht mehr komplett ausgelastet; schauen wir mal, ob das schon der richtige Mittelweg zwischen der Bereitstellung ausreichender Ressourcen und dem Schutz des Gesamtsystems vor Überlast war oder mir als nächstes die ganze Maschine in die Knie geht, wenn es mal richtig rundgeht …

FPM-Konfiguration

Für Webapplikationen in PHP ist die Apache-Konfiguration nicht das einzige limitierende Element - vielmehr muss jede Anfrage auch von einem FastCGI-Prozess beantwortet werden, und auch die sind limitiert: per Default (bei Debian) auf 50 pro Pool, konfiguriert (unter Strech) in /etc/php/7.0/fpm/pool.d/www.conf, wobei statt www.conf eben der jeweilige Pool einzusetzen ist.

Das erscheint mir ebenfalls nicht besonders viel; ich habe daher den Pool für mein Blog etwas nach oben angepasst:

pm.max_children = 250
pm.start_servers = 30
pm.min_spare_servers = 10
pm.max_spare_servers = 50

Zu lesen ist das ähnlich wie oben beim Apachen: 30 Prozesse stehen von Anfang an zur Verfügung, 10 müssen mindestens immer arbeitslos sein, sonst werden Prozesse nachgelegt, bis zur Maximalzahl von 250. Ab 50 “arbeitslosen” Prozessen werden überzählige Prozesse gestoppt.

Erfahrungswerte

Ich habe bisher, muss ich gestehen, nicht die geringste Erfahrung mit solchen “Tuning-Aufgaben”, und werde daher abwarten müssen, ob sich die Werte bewähren. Aus dem Log kann ich jedenfalls sehen, dass 50 Prozesse viel zu wenig waren und auch 150 mehrfach nicht ausreichten:

WARNING: [pool blog] server reached pm.max_children setting (150), consider raising it

Andererseits habe ich bisher zumindest aus Munin - das allerdings nicht sehr fein auflöst - keine Hinweise für Lastspitzen (CPU-Nutzung, RAM-Nutzung und Load); da scheint im Tagesverlauf überall noch viel, viel Luft nach oben zu sein.

Hat jemand aus der werten Leserschaft Erfahrungen und Tips, die er gerne teilen möchte? Sonst berichte ich, wenn das nächste Mal etwas danebengeht.

Let's Encrypt und Basic-Auth

nospam@example.com (Thomas Hochstein) — Mon, 07 Aug 2017 05:55:00 +0000

Wie man mit Let’s Encrypt ganz einfach an SSL-Zertifikate kommt, hatte ich bereits vor mehr als einem Jahr geschildert - mittlerweile übrigens ganz einfach, denn in Debian stretch ist der Let’s Encrypt-Client (der jetzt certbot heißt) nativ dabei und bringt jetzt auch einen fertigen Cronjob mit.

Aber darum soll es heute gar nicht gehen, sondern vielmehr um die Frage, wie man Let’s Encrypt verwenden kann, wenn die entsprechende Webpräsenz mit einem einfachen Passwortschutz - der basic access authentication oder kurz Basic-Auth - versehen ist. Jeder kennt vermutlich das Popup, das nach Benutzerkennung und Passwort fragt; eine nicht sehr elegante, aber dafür mit praktisch keinem Aufwand verbundene Lösung, die zudem alle Dateien in allen Verzeichnissen der Präsenz schützt, nicht nur Scripts, sondern auch - bspw. - Bilder. Eleganter ist natürlich eine ordentliche Session-Verwaltung mit Login- und Logout-Funktion; aber manchmal soll eben nur die private Bildergalerie oder eine “fertige” Applikation geschützt werden, die von Haus aus keinen Passwortschutz mitbringt. Ein schneller Eintrag in der .htaccess-Datei oder der Serverkonfiguration im passenden virtual host, und schon ist alles (ein wenig) gesichert:

AuthUserFile /home/USER/.htpasswd
    AuthName 'Privater Bereich'
    AuthType Basic
    Require valid-user

Nur wirkt dieser Schutz eben auch gegen Let’s Encrypt, das durch den Aufruf einer temporär erzeugten Datei im Verzeichnis http://domain.example/.well-known/ überprüft, ob der Antragsteller wirklich die Kontrolle über den entsprechenden Host hat. Dieser Aufruf schlägt fehl, wenn ein Passwort erforderlich ist. Natürlich könnte man jetzt jedes Mal, wenn das Zertifikat zu erneuern ist, den Passwortschutz kurzzeitig deaktivieren, aber das ist weder praktikabel (schließlich gelten die Zertifikate nur wenige Monate und sollen selbständig erneuert werden) noch sicher (was ist, wenn gerade in diesem Moment jemand die geschützte Webseite aufgerufen hat?).

Die Lösung ist aber hinreichend einfach: es genügt, das Vezeichnis /.well-known vom Passwortschutz auszunehmen. Und das funktioniert mit folgenden Zeilen im virtual host (Apache 2.4):

<Location /.well-known>
    Require all granted
</Location>

Nach einem service apache2 reload (oder dem Äquivalent des jeweiligen Systems) arbeitet Let’s Encrypt wieder so, wie es soll, und der Rest der Webpräsenz ist weiterhin passwortgeschützt.

SSL/TLS für Fortgeschrittene

nospam@example.com (Thomas Hochstein) — Thu, 14 Apr 2016 05:45:00 +0000

Hat man dem eigenen Webserver erfolgreich SSL beigebracht und für ein valides Zertifikat gesorgt, bspw. mithilfe von Let’s Encrypt, finden sich in der Konfigurationsdatei (bei Debian: /etc/apache2/mods-available/ssl.conf) noch etliche Schrauben und Rädchen, an denen man drehen kann.

SSL-Protokolle

Unter anderem lassen sich dort die Protokolle angeben, die der Server anbieten soll. “SSL” (bzw. “TLS) steht nämlich nicht für ein einzelnes Übertragungsprotokoll, sondern für eine ganze Protokollfamilie, nämlich

SSL 2.0
SSL 3.0
TLS 1.0
TLS 1.1
TLS 1.2

TLS 1.3 wird derzeit gerade entwickelt.

Gegen SSLv2 und SSLv3 sind mögliche Angriffe bekannt, weshalb ein Server diese Protokolle nach Möglichkeit nicht mehr anbieten sollte, soweit nicht ältere Software darauf noch angewiesen ist. Firefox, Chrome und Safari unterstützen mindestens TLS 1.0 von jeher, Internet Explorer kann das jedenfalls ab IE7 und Opera ab Version 5 - das sollte also in der Regel kein Grund sein, darauf zu verzichten.

So kann das dann aussehen:

SSLProtocol all -SSLv2 -SSLv3

Der Apache 2.4 (bzw. die verwendete OpenSSL-Version) unter Debian Jessie bietet SSLv2 ohnehin nicht mehr an; dort genügt es also, SSLv3 zu verbieten.

Algorithmen

Für den Schlüsselaustausch zwischen Server und Client müssen die beiden sich auf eine Methode einigen und dann noch auswählen, mit welchem Chiffrieralgorithmus die Verbindung gesichert werden soll.

Mathematik und Kryptographie entwickeln sich ebenso fort wie sich die Leistungsfähigkeit von Computern steigert - was gestern noch ausreichend sicher war, ist es morgen vielleicht nicht mehr. Es lohnt sich also, auch hierüber ein wenig nachzudenken - was nützt die schönste verschlüsselte Verbindung, wenn sie trivial zu knacken ist, nicht nur durch Geheimdienste und Strafverfolgungsbehörden, sondern auch durch andere, böswillige Dritte?

Nun kann man sich entweder selbst in das Thema einlesen - und sollte das auch, wenn man es interessant findet oder es einem wichtig ist -, oder man vertraut Lösungen, die Dritte einem empfehlen. Egal was man tut, man sollte die SSL-Verbindung danach testen lassen und - ggf. - die Last im Auge behalten, wenn man aufwändigere, aber sicherere Algorithmen anbietet und an den Anfang der Liste stellt.

Eine Möglichkeit, die angebotenen Cipher Suites zu beschränken und ihre Reihenfolge zu sortieren, wäre die folgende:

SSLCipherSuite 'EECDH+ECDSA+AESGCM:EECDH+aRSA+AESGCM:EECDH:EDH:HIGH:+RSA:+SHA:MEDIUM:!aNULL:!MD5:!eNULL:!LOW:!EXP:!DSS:!PSK:!SRP:!RC4:!CAMELLIA'

(Ich mache hier copy & paste - Kommentare dazu gerne, nun ja, in den Kommentaren.)

Server und Client einigen sich dann auf eine der von beiden unterstützten Möglichkeiten, normalerweise anhand der Präferenzen, die der Client her, auf Wunsch aber auch in der Reihenfolge, in der die Cipher Suites vorstehend - also in der Serverkonfiguration - angegeben sind. Für letzteres ist der Parameter SSLHonorCipherOrder auf “on” zu setzen:

SSLHonorCipherOrder on

Forward secrecy

Unter Forward secrecy versteht man (vereinfacht ausgedrückt), dass der zwischen Server und Client ausgehandelte temporäre Sitzungsschlüssel, mit dem Datenverbindung verschlüsselt wird, sich nicht aus den verwendeten Zertifikaten ableiten lässt. Ohne forward secrecy kann jemand, der sich den privaten Schlüssel des Servers verschafft, nicht nur alle danach aufgebauten Verbindungen live mitlesen, er kann ggf. auch alle vorherigen (!) Verbindungen nachträglich entschlüsseln, wenn er sie mitgeschnitten hat. Die Gefährdung der zukünftigen Verbindungen kann man durch einen Schlüsseltausch verhindern, wenn und sobald man bemerkt hat, dass der private Schlüssel des Servers kompromittiert wurde. Man kann ohne forward secrecy aber nicht verhindern, dass aufgezeichnete frühere Verbindungen komplett entschlüsselbar werden.

Nicht jeder für den Schlüsselaustausch verwendbare Algorithmus bietet forward secrecy; in dem oben gegebenen Beispiel stehen die Algorithmen, die es tun, aber vorne in der Liste (DHE und ECDHE).

Weitere Parameter und Einstellungsmöglichkeiten

Das Thema SSL/TLS ist komplex, und ich bin kein Spezialist dafür; daher kann ich hier nur darauf verweisen, dass es weitere, potentiell relevante Parameter gibt, die sich der Dokumentation und einschlägigen Webseiten entnehmen lassen.

Debian bietet zudem in den Dateien /etc/apache2/mods-available/ssl.conf (globale Konfiguration) und /etc/apache2/sites-available/default-ssl (Konfiguration pro virtual host) einigermaßen umfangreiche Kommentare zur Erläuterung einiger (mutmaßlich: der wichtigsten) Optionen an.

Eine soll hier noch erwähnt werden: SSLStrictSNIVHostCheck. “Off” bedeutet, dass ein Client, der kein SNI beherrscht, dann eben immer das Zertifikat des Default-vhost präsentiert bekommt, das dann in der Regel nicht zum Domainnamen passt, den er aufrufen wollte. “On” bedeutet, dass diese Clients dann nicht - via SSL - auf den entsprechenden vhost oder - wenn es in der Serverkonfiguration oder im Default-vhost gesetzt wird - auf irgendeinen vhost zugreifen können.

Weitere Überlegungen

Neben der SSL-Konfiguration sollte der sicherheitsbewusste Serverbertreiber bzw. Webapplikationsentwickler auch noch einige andere Themen im Blick behalten:

Werden Cookies so gesetzt, dass ihr Inhalt nur über eine veschlüsselte Verbindung an den Server gesandt wird?
Stichwort: secure cookie
Empfiehlt es sich, den Server bestimmte sicherheitsrelevante HTTP-Header übertragen zu lassen, und welche Bedeutung haben diese jeweils?
Stichwort: security (related) headers
Wie ist sichergestellt, dass ein abhanden gekommenes oder aus anderen Gründen widerrufenes Zertifikat nicht mehr als gültig akzeptiert wird? Stichworte: Certificate Revocation List (CRL) und Online Certificate Status Protocol (OCSP)

Zu dem angerissenen Thema der HTTP-Header gehört u.a. auch HTTP Strict Transport Security, kurz HSTS, mit dem der Server dem Client mitteilt, dass er derzeit und auch für die Zukunft (jedenfalls in dem durch den Server genannten Zeitraum) die Verbindung zu diesem Hostnamen (“Domain”) nur per HTTPS herstellen soll.

Wie ich bereits mehrfach betonte: ein weites Feld, und nicht unbedingt meines.

SSL-Verbindungen testen und bewerten

SSL Labs bietet einen Onlinetest für die Konfiguration des Servers und des Browsers an. Ruft man den Test (bspw.) für dieses Blog auf, werden alle möglichen Parameter getestet - ja, das dauert eine Weile - und dann mit einer Schulnote (im amerikanischen System) von A-F bewertet, wobei A die beste, F die schlechteste Note darstellt. Außerdem erhält man eine Vielzahl von auch mit Links hinterlegten Hinweisen auf Schwachstellen und Verbesserungsmöglichkeiten.

Wer lieber auf der Kommandozeile arbeitet, lädt sich am besten testssl.sh von Dirk Wetter herunter.

Wer hingegen wissen will, welche sicherheitsrelevanten HTTP-Header sein Server überträgt, ist bei securityheaders.io gut aufgehoben. Auch hier gibt es Schulnoten zur Bewertung.

Auch SSL-Tools bietet eine Vielzahl von Test, auch für Mailserver, hat allerdings offenbar noch die eine oder andere Schwäche jedenfalls im User Interface …

Disclaimer

Die Einzelheiten rund um Protokolle, Algorithmen und Parameter, sozusagen die Eingeweise der TLS-Implementationen, sind weit davon entfernt, mein Spezialgebiet zu sein. Dankenswerterweise hatte ich kompetente Korrekturleser, aber etwaiger verbliebener Blödsinn bleibt mein Verschulden und mag in den Kommentaren korrigiert werden, in denen ich auch gerne Ergänzungen entgegennehme.

SSL/TLS mit Let's Encrypt

nospam@example.com (Thomas Hochstein) — Mon, 11 Apr 2016 07:00:00 +0000

Bereits vergangene Woche berichtete ich von meinen Irrungen und Wirrungen des letzten Jahrzehnts mit SSL/TLS im Web. Erst Ende 2015 hatte ich mich aufgerafft, über StartCom für einige Domains Zertifikate erstellen zu lassen, und parallel die Berichterstattung über Let’s Encrypt verfolgt.

Der Workflow für die Erstellung und Pflege von HTTPS-Zertifikaten kann schnell komplex werden:

Am Anfang steht die Erzeugung eines Schlüsselpaares, denn das spätere Zertifikat wird nur derjenige verwenden können, der auch den passenden privaten Schlüssel hat.
Dann ist für jedes Zertifikat ein Certificate Signing Request (CSR) zu erstellen; das ist quasi die Roh-Form des späteren Zertifikats mit den notwendigen Informationen, die darin enthalten sein sollen.
Dieser CSR muss dann von der Zertifierungsstelle (Certificate Authority, CA) digital signiert werden.
Das so entstandene Zertifikat muss gespeichert und in die Webserver-Konfiguration eingebunden werden.
Der ganze Ablauf ist nur zielführend, wenn die CA von den verbreiteten Browsern anerkannt ist, den von ihr signierten Zertifikaten also vertraut wird. Dafür wollen die meisten CAs Geld. Zudem müssen sie sich über einen mehr oder weniger aufwendigen Weg zumindest vergewissern, dass derjenige, der ein Zertifikat für einen bestimmten Hostnamen ausgestellt haben möchte, über diesen auch verfügen kann.
Zertifikate werden in der Regel nur für einen begrenzten Zeitraum - meistens ein Jahr - ausgestellt. Danach müssen sie (rechtzeitig!) verlängert werden.

Let’s Encrypt ist angetreten, diese Abläufe weitestmöglich zu vereinfachen.

Let’s Encrypt - die Prinzipien

Let’s Encrypt arbeitet kostenlos und veröffentlicht die verwendeten Schnittstellen. Es stellt eine CA zur Verfügung, die automatisch Zertifikate ausstellt, nachdem sie überprüft hat, dass der Anfragende die administrative Kontrolle über den entsprechenden Hostnamen hat - beispielsweise, indem Let’s Encrypt verlangt, dass eine bestehende Datei auf dem Webserver unter diesem Hostnamen hinterlegt wird. Die erstellten Zertifikate werden öffentlich gemacht; es kann also jeder jederzeit nachvollziehen, wann Let’s Encrypt welche Zertifikate erstellt hat.

Mittlerweile ist das Zwischenzertifikat von Let’s Encrypt nicht nur durch Let’s Encrypt selbst, sondern auch durch eine andere CA (IdenTrust) signiert und wird daher regelmäßig von den Browsern als vertrauenswürdig anerkannt. Von Let’s Encrypt ausgestellte Zertifikate werden also akzeptiert und führen nicht zu irgendwelchen Warnmeldungen. Sie gelten allerdings nur rund 90 Tage und müssen dann erneut werden.

Let’s Encrypt stellt Client-Software zur Verfügung, die den gesamten, einleitend dargestellten Workflow automatisiert, ermöglicht es aber auch, die notwendigen Schritte in beliebigem Umfang manuell nachzuvollziehen oder auch eigene Lösungen zu programmieren. Im vollautomatischen Modus erstellt Let’s Encrypt das notwendige Schlüsselpaar und den CSR, überprüft, dass der Antragsteller den Hostnamen kontrolliert, stellt das Zertifikat aus und speichert es, passt die Webserver-Konfiguration an und bindet das Zertifikat ein und kann auf Wunsch rechtzeitig vor Ablauf ein neues Zertifikat erstellen.

Let’s Encrypt und der Apache-Webserver unter Debian Jessie

Im Anschluss möchte ich einen weitgehend, aber nicht völlig automatisierten Ablauf zum Erstellen von SSL-Zertifikaten und deren Einbindung in einen Apache unter Debian Jessie darstellen. Es ist durchaus möglich, weit weniger auf Automatismen zu setzen; dann muss der Client auch nicht zwingend mit Root-Rechten laufen. Matthias Gutjahr schildert in seinem Blog eine Möglichkeit dafür; Dirk Deimeke hat eine weitere Alternative dargestellt. Beide Beiträge sind am Ende dieses Blogbeitrags verlinkt.

Installation

Ab Jessie, der derzeit stabilen Debian-Version, steht letsencrypt als Paket zur Verfügung, allerdings nur in den Backports. Wenn sich in der /etc/apt/sources.list also die Zeile deb http://ftp.debian.org/debian jessie-backports main findet, ist die Installation daher denkbar einfach:

apt-get -t jessie-backports install letsencrypt

Die umfangreichen Abhängigkeiten werden mitinstalliert.

Wer noch unter Wheezy arbeitet, benötigt etwas mehr Vertrauen in die Macher von Let’s Encrypt - und Platz für ein umfangreicheres Software-Paket (letsencrypt-auto), das u.a. eine komplette virtuelle Python-Umgebung mit sich schleppt:

cd /usr/local
git clone https://github.com/letsencrypt/letsencrypt
cd letsencrypt
./letsencrypt-auto --help

letsencrypt-auto akzeptiert dann denselben Input wie letsencrypt.

Zertifikat erstellen lassen

letsencrypt bietet eine ncurses-Oberfläche, die es ermöglicht, auf einige Kommandozeilen-Parameter zu verzichten und ggf. notwendige Abfragen im Dialog zu beantworten. Dazu gehört beim ersten Start u.a. die Angabe einer E-Mail-Adresse für eine mögliche Kontaktaufnahme und die Bestätigung der AGB, die erforderlich ist. Danach erstellt letsencrypt automatisch einen Account samt Schlüsselpaar, so dass weitere Aufrufe in der Regel ohne Interaktion ablaufen können.

Alle Daten werden standardmäßig unter /etc/letsencrypt/ abgelegt.

Der folgende Aufruf fordert ein Zertifikat für die Hostnamen domain.example und www.domain.example an, deren Dateien auf der Platte im Verzeichnis /var/www/domain.example (Webroot) liegen:

letsencrypt certonly --webroot -w /var/www/domain.example/ -d domain.example -d www.domain.example

Falls notwendig, werden Mailadresse und Zustimmung zu den AGB (“Terms of Service”, “TOS”) abgefragt und ein privater Schlüssel (bzw. das Schlüsselpaar) erstellt. Dann wird der CSR an Let’s Encrypt geschickt, temporär eine unter http://domain.example/ abrufbare Datei im Webroot erstellt und so geprüft, dass man wirklich die Kontrolle über diesen Hostnamen hat, das Zertifikat erstellt, unter /etc/letsencrypt/archive/domain.example/ gespeichert und ein Symlink von /etc/letsencrypt/live/domain.example/ nach dort erstellt.

Soll das Zertifikat für weitere Hostnamen gelten, können beliebig viele Folgen von -w webroot -d hostname angeschlossen werden. Es folgt jeweils auf das -w webroot die Angabe der Hostnames, die zu diesem Webroot gehören.

Zertifikat beim Apache einbinden

Eine minimale Konfiguration für den virtual host könnte im Apache 2.4 (Debian Jessie) so aussehen:

<VirtualHost *:443>
    ServerName domain.example
    ServerAlias www.domain.example

    DocumentRoot /var/www/domain.example

    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/domain.example/fullchain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/domain.example/privkey.pem
</VirtualHost>

Der Apache 2.2, der mit Debian Wheezy ausgeliefert wird, muss Zertifikat und Zwischenzertifikat der CA getrennt ausliefern:

<VirtualHost *:443>
    [...]
    SSLEngine on
    SSLCertificateFile /etc/letsencrypt/live/domain.example/cert.pem
    SSLCertificateChainFile /etc/letsencrypt/live/domain.example/chain.pem
    SSLCertificateKeyFile /etc/letsencrypt/live/domain.example/privkey.pem
</VirtualHost>

Zertifikate erneuern

Folgender Cronjob prüft täglich um 4 Uhr morgens, ob ein Zertifikat erneuert werden muss, und nimmt diese Erneuerung automatisch vor, wenn sich der Ablaufzeitpunkt nähert:

00 4 * * * letsencrypt renew --keep-until-expiring

Weiterer Lesestoff

Let’s Encrypt: Getting Started
Wouter Verhelst im WEBlog — Wouter’s Eclectic Blog: Playing with Letsencrypt
Matthias Gutjahr im Sperrobjekt Weblog: Let’s Encrypt-Zertifikate manuell erzeugen
Dirk Deimeke in Dirks Logbuch: Let’s Encrypt …

Der eigene Webserver mit SSL/TLS

nospam@example.com (Thomas Hochstein) — Thu, 07 Apr 2016 05:50:00 +0000

Datenströme im Netz zu verschlüsseln ist wichtig, aber auch zunehmend Allgemeingut. Telnet würde sicherlich niemand mehr zum Zugriff auf einen entfernten Rechner nutzen; stattdessen nimmt man SSH. Auch bei anderen Protokollen ist die Übertragung von Passworten im Klartext schon lange out: es fing an mit APOP für den Zugriff über POP3 und CRAM-MD5 für SMTP-Auth, und schon etliche Jahre nutze ich nur noch POP3S/IMAPS/SMTPS, also eine komplette Verschlüsselung des gesamten Datenstroms. So hat auch das auf SSH basierende SCP/SFTP schon lange FTP ersetzt, und nachdem sich mittlerweile auch NNTPS und der verschlüsselte Zugriff auf IRC-Server verbreitet haben, bleiben nur noch wenige Protokolle “offen”.

Selbstverständlich sollte auch - zumindest - die Übertragung von Passworten via HTTP gesichert werden, was die Einrichtung von HTTPS erfordert. Je mehr sich webbasierte Dienste und Apps verbreiten, desto wichtiger ist das. Es ist allerdings - leider - nicht ganz so einfach.

SSL-/TLS-Zertifikate und deren Prüfung

Das liegt darin, dass Verschlüsselung allein zumindest im Grundsatz nicht genügt - wichtig ist auch Authentifizierung, also die Überprüfung, ob man auch mit der richtigen Gegenstelle spricht oder sich ein Dritter, der “Man in the middle”, dazwischengehängt hat. Zu einer mittels SSL/TLS (in Zukunft: SSL als Sammelbegriff für beides) gesicherten Verbindung gehört daher - eigentlich - auch immer die Überprüfung des Zertifikats der Gegenstelle. Dazu muss man entweder den Fingerprint des Zertifikats kennen und prüfen - PGP/GPG lässt grüßen -, oder man begnügt sich damit, dass eine Zertifizierungsstelle die Echtheit des Zertifikats bestätigt hat (und hofft auf deren Sorgfalt; eine Hoffnung, die die Praxis bereits vielfach enttäuscht hat).

Will man selbst verschlüsselte Zugänge anbieten, genügt es für die meisten Dienste, ein selbst-signiertes Zertifikat zu erstellen und den Nutzern den Fingerprint mitzuteilen. In der Regel ist der Nutzerkreis selbstgehosteter Dienste nämlich überschaubar: der private Mailserver wird zum Versand und zum Mailabruf in der Regel nur selbst oder allenfalls von Familienmitgliedern und Freunden genutzt, die dem selbst-signierten Zertifikat dann vertrauen können. Nicht unüblich ist es auch, auf eine Zertifikatsprüfung zu verzichten und jedes präsentierte Zertifikat zu akzeptieren, also nur die Verschlüsselung zu nutzen und der Gegenstelle zu vertrauen. Das ist insofern nachvollziehbar, als es deutlich einfacher ist, (unverschlüsselten) Datenverkehr mitzulesen als sich als “Man in the middle” mit einem falschen Zertifikat in den verschlüsselten Datenstrom einzuklinken.

HTTPS im Speziellen

Bei Webdiensten liegt der Fall hingegen etwas anders: zumeist erfolgt der Zugriff für die Allgemeinheit - der nicht zwingend einer Absicherung durch Verschlüsselung bedürfte - über dieselbe “Domain” (ich verwende den Begriff hier umgangssprachlich; richtiger wäre “Hostname”) wie die Administration. Ein Blog, bspw., das unter http://meinblog.example/ zugänglich ist, wird meist über http://meinblog.example/admin/ verwaltet, nicht aber über http://admin.meinblog.example/. Ich muss also damit rechnen, dass auch die Allgemeinheit auf meine Webseiten über HTTPS zugreift, oder ich will das sogar erzwingen, damit ich nicht versehentlich Passwörter über eine ungeschützte Verbindung übertrage.

Dann habe ich aber ein Problem: mein selbst-signiertes Zertifikat ist den Besuchern der Webseite natürlich unbekannt, und Browser generieren für diesen Anwendungsfall zunehmend auffälligere Warn- und Fehlermeldungen, die einen Zugriff auf die Seite entweder ganz unterbinden oder doch arg erschweren und den Durchschnittsnutzer abschrecken (was ja auch Sinn der Sache ist).

Virtual Hosting

Zu diesem Problem der Fehlermeldungen bei selbst-signierten Zertifikaten kommt noch ein ein weiteres hinzu: es ist üblich, über einen Webserver (auf ein- und derselben IP-Adresse) eine Vielzahl von “Domains” (also getrennten Webseiten) anzubieten. Bei größeren Anbietern können das hunderte oder zigtausende Nutzer sein, die sich da auf einem Host tummeln, aber auch der private Nutzer hat vielleicht neben seiner Homepage unter meine-domain.example auch noch ein Blog unter blog.meine-domain.example oder will schlicht seine Webseiten sowohl unter meine-domain.example als auch unter www.meine-domain.example erreichbar machen. Das sind aber alles unterschiedliche Hostnamen, und da jedes SSL-Zertifikat angeben muss, für welchen Hostnamen es gültig ist, haben wir das nächste Problem: liefert der Webserver für www.meine-domain.example das Zertifikat für meine-domain.example aus, verfallen die Warnmeldungen im Browser nicht selten in eine noch schrillere Tonlage.

Es ist leider auch nicht so einfach, für jede “Domain” ein eigenes Zertifikat zu präsentieren. Der Zugriff auf solche virtual hosts erfolgt nämlich in der Weise, dass der Browser einen Header mitschickt, aus dem sich ergibt, auf welche “Domain” er zugreifen will. Für diesen Zugriff muss aber die verschlüsselte Verbindung schon stehen; andersherum weiss der Server beim Verbindungsaufbau noch nicht, welche “Domain” angefragt wird, und kann daher auch nicht das jeweils “richtige” Zertifikat ausliefern.

Was also tun?

Lösungswege

Über die Jahre habe ich verschiedene - allesamt mehr oder weniger unbefriedigende - Möglichkeiten getestet, um diesem Problem zu Leibe zu rücken.

Die eigene CA

Angefangen habe ich vor gut einem Jahrzehnt mit einer eigenen Zertifizierungsstelle, die meine SSL-Zertifikate signiert. Dann reicht es nämlich, das Stammzertifikat dieser Zertifizierungsstelle dem Browser (und ggf. dem Mailprogramm) als gültig unterzuschieben, und alle anderen Zertifikate werden automatisch akzeptiert. Das erleichtert zumindest einmal mir selbst (und Freunden und Bekannten, die mir ausreichend trauen) den Umgang mit verschiedenen Servern und ggf. verschiedenen Hostnamen, behebt aber nicht das Problem, dass das Zertifikat immer nur für einen Hostnamen (eine “Domain”) gültig ist, und hilft auch den Webseitenbesuchern nicht.

Ich habe mich daher in der Regel darauf beschränkt, HTTPS nur ergänzend anzubieten oder nur für solche Webseiten, die ausschließlich intern genutzt werden und sich nicht an die Allgemeinheit richten. Professionell geht aber fraglos anders.

SAN

Danach habe ich mich mit Subject Alternate Names, kurz SAN, vertraut gemacht. Es ist nämlich möglich, einem Zertifikat mitzugeben, dass es für mehr als einen Hostnamen gültig ist. Zum einen gibt es - nicht empfehlenswerte - sog. “Wildcard-Zertifikate”, die für alle Subdomains einer bestimmten Domain gültig sind, bspw. *.domain.example. Zum anderen gibt es SAN - zusätzliche Hostnamen, für die das jeweilige Zertifikat auch gilt. Die kann man bei der Erstellung des Zertifikats mit angeben.

Das funktioniert ganz gut, löst aber zum einen nicht das Problem der fehlenden allgemeinen Akzeptanz des Zertifikats und schafft zudem zwei neue Schwierigkeiten. Zum einen kann jeder Besucher durch Ansicht des Zertifikats feststellen, welche Webseiten auf dem Server sonst noch so gehostet werden (was nicht immer optimal ist), zum anderen braucht es für jede neue “Domain”, auf die auch per HTTPS zugegriffen werden soll, auch ein komplett neues Zertifikat.

SNI

Dem strukturellen Problem, dass der Server erst die verschlüsselte Verbindung aufbauen muss und danach erfährt, für welche “Domain” er das eigentlich tun soll, ist man mit Server Name Indication, kurz SNI, zu Leibe gerückt. Das ist eine Erweiterung des TLS-Protokolls, die es dem Client erlaubt, beim Verbindungsaufbau bereits mitzuteilen, aus welcher “Domain” er später Webseiten abrufen will, so dass der Server ihm dann das richtige Zertifikat präsentieren kann. So kann auch der Webserver für jede “Domain” ein eigenes Zertifikat anbieten.

Mittlerweile darf man davon ausgehen, dass SNI so verbreitet ist, dass man es im praktischen Betrieb voraussetzen kann: Firefox unterstützt es seit Version 2.0, der Internet Explorer seit Version 7 und Windows Vista (nicht unter Windows XP), und auch wget sollte das seit 2012 beherrschen.

Kommerzielle Zertifikate

Dies wiederum ermöglicht es, auf kommerzielle SSL-Zertifikate zurückzugreifen. Deren Anbieter lassen sich nämlich ihre Dienste bei “Wildcard-Zertifikaten” oder solchen mit einer Vielzahl von Hostnamen (oder auch bei erweiterter Validierung der “Domains”, für die das Zertifikat gelten soll) geradezu fürstlich bezahlen; Zertifikate für nur ein oder zwei Namen (also bspw. domain.example und www.domain.example) sind hingegen erschwinglich oder gar kostenlos. SNI macht es jetzt möglich, jeder “Domain” ihr eigenes günstiges Zertifikat zuzuweisen, bspw. von StartCom, einem Anbieter, der Zertifikate für maximal zwei “Domains” kostenlos abgibt (dann allerdings für den Widerruf eines kompromittierten Zertifikats Geld verlangt - nun ja).

So kann man dann allmählich vernünftig mit SSL arbeiten.

Die Zukunft: letsencrypt

Neuerdings befindet sich zudem mit Let’s Encrypt ein Anbieter am Start, der sich kostenloses, freies und massentaugliches SSL/TLS auf die Fahnen geschrieben hat:

Let’s Encrypt is a new Certificate Authority:
It’s free, automated, and open.

Dazu werde ich später mehr berichten.

SSL-Zertifikate und Apache

Nach der Theorie nun etwas Praxis: wie richte ich beim Apache-Webserver einen virtual hosts mit SSL ein?

Im Prinzip ist das recht einfach; Debian liefert bspw. eine entsprechende Konfiguration schon mit. Ich setze im Folgenden voraus, dass sowohl passende SSL-Zertifikate (mit dem zugehörigen private key in entschlüsselter Form, d.h. ohne Passwortschutz) vorhanden als auch virtual hosts grundsätzlich eingerichtet sind. Die Zertifikate speichere ich im Verzeichnis /etc/apache2/ssl.

Eine Basis-Konfiguration könnte dann - mit einem Zertifikat von StartCom - bspw. so aussehen:

<VirtualHost *:443>
    ServerName meine-domain.example
    ServerAlias www.meine-domain.example

    DocumentRoot /var/www/meine-domain.example

    SSLEngine on
    SSLCertificateFile /etc/apache2/ssl/meine-domain.example.crt
    SSLCertificateKeyFile /etc/apache2/ssl/meine-domain.example.key
    SSLCertificateChainFile /etc/apache2/ssl/sub.class1.server.ca.pem
</VirtualHost>

Will man alle Zugriff von HTTP auf HTTPS umleiten, kann man bspw. folgendes ergänzen:

<VirtualHost *:80>
    ServerName meine-domain.example
    ServerAlias www.meine-domain.example

    Redirect / https://meine-domain.example/
</VirtualHost>

Disclaimer

SSL/TLS, der Umgang mit Zertifikaten und die Konfiguration des Apache sind ein weites Feld, für das ich zudem kein Spezialist bin.

Dieser Beitrag will einen kurzen, knappen und daher notwendigerweise unvollständigen Überblick zu diesem Thema geben und zur eigenen Beschäftigung damit anregen. Ich habe daher manches vereinfacht, anderes weggelassen, wieder anderes - absichtlich oder unabsichtlich - ungenau dargestellt.

Dies ist kein Tutorial, und die am Schluss genannten Beispiele sind nicht zur 1:1-Übernahme via copy & paste geeignet.

Wenn sich Fehler eingeschlichen haben, bin ich über Kommentare dankbar - und auch Ergänzungen nehme ich natürlich gerne entgegen.

Apache 2.x, php-cgi, mod_suphp und "No input file specified!"

nospam@example.com (Thomas Hochstein) — Fri, 17 Apr 2009 15:03:00 +0000

Im Zusammenhang mit dem Update einer Maschine auf Debian Lenny bin ich auf das seltsame Phänomen einer - offensichtlich von PHP erzeugten - Fehlermedlung gestoßen: der Aufruf einer bestimmten Webseite (respektive des PHP-Scripts, das diese erzeugen sollte) ergibt nur die Meldung "No input file specified!". Google führt einen zu diversen Threads, die sich vor allem um die Konfiguration des richtigen Handlers für die Interpretation von PHP-Scripts und um hilflose Fragen von Benutzern, die eigentlich nur ein fertiges Paket installieren wollten und nun nicht mehr weiter wissen, drehen. Erst ein alter Blogeintrag in ixs’ Vodkamelone (nein, das hat nichts mit einem Kamel Nr. Eins zu tun!) von 2005 half mir auf die Sprünge.

Der Grund dieser Fehlermeldung ist offenbar ein ganz seltsames Zusammenspiel der Ausführung von PHP als mod_suphp, d.h. der CGI-Version von PHP in der Weise, daß Scripts unter den Rechten des jeweiligen Benutzers ausgeführt werden, mit der Vergabe von Datei- und Verzeichnisrechten. Die oben genannten Fehlermeldung tritt demnach genau dann auf, wenn zwar der Webserver auf die Datei bzw. ihr Verzeichnis zugreifen, sie also "finden" kann, der Benutzer selbst aber nicht. Dann findet der Webserver - unter der UID www-data - das Script, erkennt es, ruft den Handler auf, der als suid root installiert ist, sich Root-Rechte verschafft, damit auf die UID des Benutzers wechselt und dann mit diesen Rechten den PHP-Interpreter aufruft, um ihn das Script ausführen zu lassen. Dieser PHP-Prozess, der jetzt aber im Kontext des Benutzers läuft, kann dann selbst auf das entsprechende Verzeichnis nicht mehr zugreifen, das Script also auch nicht ausführen, und reagiert dann mit der obigen Fehlermeldung, denn er findet ja keine Datei, die er ausführen könnte.

Vielleicht hilfts ja jemanden, wenn ich ixs’ Analyse her noch einmal wiedergebe und verlinke.