Netz - Rettung - Recht (Artikel mit Tag ssl)

SSL/TLS im Web - Ende 2019

nospam@example.com (Thomas Hochstein) — Fri, 20 Dec 2019 05:40:00 +0000

HTTPS, also der per SSL/TLS gesicherte Zugriff auf Webseiten, hat sich in den letzten Jahren - nicht zuletzt durch die problem- und kostenlosen Zertifikate von Let’s Encrypt - stark verbreitet. War es noch vor fünf oder sechs Jahren eher der Ausnahmefall, dass Webseiten, die keinen Login erfordern, die Möglichkeit einer verschlüsselten Verbindung anbieten, ist HTTPS mittlerweile gefühlt der Normalfall geworden. Doch es gibt immer noch Ausnahmen (übrigens auch dort, wo ein Login erforderlich ist).

Ab und an gehe ich auf manchen meiner Webseiten bestehende Links nicht nur unter dem Gesichtspunkt durch, ob die verlinkten Seiten noch existieren, sondern prüfe auch, ob eine noch per HTTP verlinkte Webseite nicht mittlerweile eine verschlüsselte Variante anbietet, und stelle dann sukzessive auch meine Links um. War das 2017 noch oft enttäuschend, konnte ich demletzt fast alle verbliebenen Links ändern.

Es bleiben aber immer noch Ausnahmen, darunter (manche) Webseiten einer großen südwestdeutschen Landeshauptstadt, Fakultäten von Universitäten und ähnliche Institutionen.

Besonders gut gefallen hat mir die Kassenzahnärztliche Vereinigung (KZV) in einem südwestdeutschen Bundesland, die zwar HTTPS-Verbindungen annimmt, sie aber auf die unverschlüsselte Version der Webseite umleitet. So herum habe ich das noch nie gesehen - immerhin, man kommt ans Ziel und landet nicht bei einer Fehlermeldung oder auf einer zumindest partiell defekten Webseite, aber etwas skurril ist das dann schon.

Sehr schön aber auch die vermutlich von einem großen Kongressanbieter betriebene Webseite einer jährlich zum Jahresanfang stattfindenden notfallmedizinisch orientierten Tagung: HTTPS geht, aber das nicht von einer anerkannten CA signierte Zertifikat ist am 30.06.2016 (!) abgelaufen.

Insgesamt ist das Bild also gut, aber es bleibt noch viel zu tun.

Haben Sie Ihre Webseite schon umgestellt?

HSTS im Firefox ignorieren

nospam@example.com (Thomas Hochstein) — Fri, 18 Jan 2019 08:30:00 +0000

HSTS steht für HTTP Strict Transport Security und ist ein Standard, der unverschlüsselte Zugriffe auf solche Webseiten verhindern soll, die nur verschlüsselt angeboten werden.

Dem liegt folgendes Angriffsszenario zugrunde: Die Webseite www.example.com ist nur über HTTPS zugänglich. Der Angreifer “A” kann zwar Zugriffe des Benutzers “B” auf seinen eigenen Server umleiten, bspw. durch Manipulation des DNS, aber - wenn alles so läuft, wie es soll - kein Zertifikat für www.example.com erhalten. Was macht er? Er leitet alle Zugriffe auf https://www.example.com stattdessen auf http://www.example.com (ohne Verschlüsselung!) um, und schon gibt es für den Benutzer keine Fehlermeldungen mehr. Dass die Verbindung jetzt unverschlüsselt ist, sieht er vielleicht nicht ohne weiteres. Außerdem kann der Angreifer natürlich einfach ein - nicht vertrauenswürdiges, d.h. selbst signiertes - Zertifikat für www.example.com erzeugen. Das führt zwar zu einer Fehlermeldung, die der Nutzer aber ignorieren kann (“Sicherheits-Ausnahmeregel erstellen”). Auch das soll HSTS unterbinden.

Eine Website kann diese Policy durch Setzen eines HTTP-Headers (Strict-Transport-Security) serverseitig signalisieren und dabei auch angeben, wie lange diese Einstellung gültig bleiben soll. Der Browser muss diese Vorgabe für die eingestellte Dauer speichern und während dieses Zeitraums (a) jeden unverschlüsselten Zugriff (HTTP) auf einen verschlüsselten Zugriff (HTTPS) umleiten sowie (b) bei jedem Zertifikatsfehler die Verbindung unterbinden, ohne dem Benutzer eine Möglichkeit zu geben, das Zertifikat doch zu akzeptieren:

This means that the user should not be presented with a dialog giving her the option to proceed. Rather, it should be treated similarly to a server error where there is nothing further the user can do with respect to interacting with the target web application, other than wait and retry.

Zertifikatsfehler bei HSTS

So weit, so gut. Es kann aber durchaus legitime Gründe geben, eine solche Verbindung als Benutzer trotzdem zu akzeptieren, beispielsweise dann, wenn man eine Website (oder eine Webapplikation) umzieht. Viele Applikationen (Blogs, …) speichern den Hostnamen, so dass viele dafür spricht, www.meinblog.example auch auf dem neuen Host wieder als www.meinblog.example und nicht als test.meinblog.example einzurichten. Bevor man die DNS-Einträge ändert, kann man dann einfach seinem eigenen Rechner über die Hosts-Datei (/etc/hosts oder %windir%\system32\drivers\etc\hosts) die neue IP unterschieben und die Applikation testen. Leider schlägt das mit aktivierter HSTS fehl, wenn die neue Installation noch kein SSL-Zertifikat hat - vielleicht deshalb, weil man es über Let’s Encrypt bezieht und die einfachen Validierungsroutinen fehlschlagen, so lange die DNS-Einträge für die Domain noch auf die alte Installation zeigen. Natürlich gibt es auch dafür Möglichkeiten, einfacher wäre es aber, schlicht ein fehlendes oder selbst signiertes Zertifikat akzeptieren zu können.

Wie dem auch sei: es wäre doch schön, wenn man als Benutzer - trotz HSTS - bewusst fehlerhafte HTTPS-Verbindungen akzeptieren könnte. Es könnte ja auch einfach einmal sein, dass ein Zertifikat nicht rechtzeitig erneut wurde … Firefox bietet allerdings - standardkonform - keine Möglichkeit dazu über die Benutzeroberfläche.

Hingegen ist es möglich, den HSTS-Eintrag zu löschen mit der Folge, dass Firefox nichts mehr davon weiß, dass die entsprechende Domain eigentlich HSTS implementiert. Dazu genügt es, Firefox zu beenden, im Profilverzeichnis (%APPDATA%\Mozilla\Firefox\Profiles\ plus Name des eigenen Profils) die Datei SiteSecurityServiceState.txt zu editieren und den Eintrag für die betreffende Domain zu löschen, die Datei zu speichern und Firefox neu zu starten. Voila - er hat HSTS vergessen und ermöglicht es nunmehr wie sonst auch, eine temporäre oder dauerhafte Ausnahmeregel zu erstellen und ein ungültiges oder nicht vertrauenswürdiges Zertifikat zu akzeptieren (natürlich nur, wenn der Webserver nicht direkt wieder HSTS setzt …).

Freilich sollte man das nur tun, wenn man auch wirklich weiß, was man tut - sonst schießt man sich ggf. in den eigenen Fuß.

Github: alte TLS-Versionen und SSH-Algorithmen deaktiviert

nospam@example.com (Thomas Hochstein) — Tue, 03 Apr 2018 04:40:00 +0000

Github hat am 22.02.2018 Änderungen an der HTTPS-und SSH-Konfiguration vorgenommen und ältere und weniger sichere Zugriffsmöglichkeiten deaktiviert. Das betrifft sowohl TLS 1.0 und TLS 1.1 als auch - für den SSH-Schlüsselaustauch - diffie-hellman-group1-sha1 und *diffie-hellman-group14-sha1. Wenn die verwendete Client-Software nicht mindestens TLS 1.2 bzw. einen anderen Schlüsselaustausch-Algorithmus beherrscht, muss man mithin aktiv werden.

Wer - wie ich - Git for Windows zusammen mit PLink aus dem Putty-Paket als SSH-Client verwendet, bekommt sonst möglicherweise - wenn er Putty länger nicht mehr geupdatet hat - beim git pull oder git push eine Meldung dieser Art zu sehen:

FATAL ERROR: Couldn't agree a key exchange algorithm (available: curve25519-sha256@libssh.org,ecdh-sha2-nistp256,ecdh-sha2-nistp384,ecdh-sha2-nistp521)

Natürlich (?) hatte ich die Ankündigungen über die Änderungen bei Github nicht präsent, vermutete aber etwas in der Art - und Google führte mich nach einiger Zeit zu einem Issue im Github-Desktop-Projekt. Und siehe da - Putty kann erst ab Version 0.68 (21.02.2017) elliptische Kurven:

Support for elliptic-curve cryptography (the NIST curves and 25519), for host keys, user authentication keys, and key exchange.

Ein putty-Update später flutschte dann auch wieder alles.

(Ab dieser Version wird allerdings ggf. eine 64bit-Version von Putty installiert, die dann unter Windows nicht in C:\Program Files (x86) landet, sondern in C:\Program Files, so dass ggf. die Umgebungsvariable GIT_SSH angepasst werden muss.)

"StartCom temination announcement"

nospam@example.com (Thomas Hochstein) — Wed, 06 Dec 2017 21:30:00 +0000

Bis zum Umzug meines Blogs auf neue Hardware stammte das SSL-Zertifikat für das Blog von StartCom, einem Tochterunternehmen von WoSign (wobei der Erwerb offenbar verdeckt durch Hinterleute erfolgte). Die Konzernmutter fiel jedenfalls 2016 durch … unschöne Praktiken bei der Erstellung von Zertifikaten auf, mit der Folge, dass Apple, Google (Chrome) und Mozilla (Firefox) allen Zertifikaten der Mutter- wie der Tochterfirmen sukzessive das Vertrauen entzogen.

Das hat dem Unternehmen offenbar das Genick gebrochen, wie ich einer E-Mail entnehme, die mich am vergangenen Samstag erreichte:

This is an automatically generated email, please do not reply.

Dear customer,

As you are surely aware, the browser makers distrusted StartCom around a year ago and therefore all the end entity certificates newly issued by StartCom are not trusted by default in browsers.

The browsers imposed some conditions in order for the certificates to be re-accepted. While StartCom believes that these conditions have been met, it appears there are still certain difficulties forthcoming. Considering this situation, the owners of StartCom have decided to terminate the company as a Certification Authority as mentioned in Startcom’s website.

StartCom will stop issuing new certificates starting from January 1st, 2018 and will provide only CRL and OCSP services for two more years.

StartCom would like to thank you for your support during this difficult time.

[…]

Please let us know if you need any further assistance with the transition process. We deeply apologize for any inconveniences that this may cause.

Best regards,
StartCom Certification Authority

Tscha. Gut, dass es Let’s Encrypt gibt.

"Mixed-Content"-Warnungen vermeiden

nospam@example.com (Thomas Hochstein) — Wed, 11 Oct 2017 06:15:00 +0000

Wer seine Webseiten auf SSL umstellt, kennt das Problem: eingebundene Bilder, Grafiken, CSS- oder Javascript-Dateien werden hier und dort noch über HTTP aufgerufen, was entweder zu Warnmeldungen im Browser über Mixed Content führt (“Teile dieser Seite sind nicht sicher.”) - oder dazu, dass die “unsicher” eingebundenen Teile nicht nachgeladen werden, mit unschönen Aspekten, wenn Teil des CSS oder des Javascripts plötzlich fehlen.

Das Problem lässt sich natürlich mit einer Volltext-Suche (bspw. nach http:) angehen, aber gerade bei datenbankgestützten Webapplikationen (wie Blogs und CMS) mag der SSL-Check von Jitbit hilfreich sein, der kostenlos bis zu 200 Einzelseiten überprüft.

(Gefunden bei Leitmedium.)

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.

Neue Zertifikate von StartCom

nospam@example.com (Thomas Hochstein) — Wed, 19 Oct 2016 05:00:00 +0000

Eigentlich nutze ich mittlerweile ja Let’s Encrypt, wenn ich Zertifikate für den Betrieb einer Website benötige. Allerdings gibt es doch noch ein oder zwei Dienste, wo ich seit Ende 2015 auf StartCom setze - und die dortigen, kostenlosen Zertifikate laufen eben nach einem Jahr ab und standen daher jetzt zur Erneuerung an.

Wenige Stunden vor dem Ablauf meines persönlichen Identifizierungs-Zertifikats - wie ich erst dann bemerkte - loggte ich mich also dort ein, validierte meinen Account und die relevanten Domains neu, erstellte ein neues persönliches Zertifikat und auch neue Zertifikate für die betreffenden Websites. Jetzt ist wieder alles paletti.

Neuerdings scheinen die Zertifikate immerhin für drei Jahre ausgestellt zu werden - also habe ich jetzt bis 2019, um StartCom auch dort durch Let’s Encrypt zu ersetzen.

letsencrypt jenseits des Webservers

nospam@example.com (Thomas Hochstein) — Tue, 30 Aug 2016 14:30:00 +0000

Vor einigen Monaten hatte ich über letsencrypt, die neue Zertifizierungsstelle für TLS-Zertifikate, berichtet und demletzt meine guten Erfahrungen damit dargestellt. Doch HTTP ist ja nicht das einzige Protokoll, das einer Absicherung bedarf. Wie sieht es mit TLS-Zertifikaten für Mail (SMTP und POP3 oder IMAP) und News (NNTP) oder noch andere Dienste aus?

Grundsätzlich ist das kein Problem: vorhandene Zertifikate mit dem (oder den) passenden Hostnamen müssen nur eingebunden werden.

In der Folge stelle ich die Vorgehensweise ausgehend von einem Debian-Jessie-System aus vor.

Erhalt des Zertifikats

Am einfachsten ist das, wenn unter jedem Hostnamen auch ein Webserver erreichbar ist; dann kann nämlich einfach das webroot-Plugin verwendet werden. Ist das nicht der Fall, kommen bspw. das manual-Plugin oder das external-Plugin in Betracht.

Installation des Zertifikats

Das bereits - für den Webserver - vorhandene oder neu erhaltene Zertifikat und der zugehörige Schlüssel ( Key), die üblicherweise im Verzeichnis /etc/letsencrypt/live/domain.example/ liegen, können nun eingebunden werden - entweder das Zertifikat und die ganze Zertifikatskette mit allen Zwischenzertifikaten zusammen in einer Datei (fullchain.pem), oder das Zertifikat (cert.pem) und die Zwischenzertifikate (chain.pem) getrennt, je nachdem, was die Applikation unterstützt.

Nicht immer ist es aber ohne weiteres möglich, unmittelbar auf die Dateien in /etc/letsencrypt/live/domain.example/ zuzugreifen, die root:root gehören und aufgrund der Verzeichnisrechte auch nur für root lesbar sind. Manche Programme (bspw. der Mailserver Exim) greifen nämlich auf die Zertifikate zu einem Zeitpunkt zu, zu dem sie bereits keine Root-Rechte mehr haben; und es erscheint wenig tunlich, sie in die Gruppe root aufzunehmen oder gar Zertifikat und Key weltweit lesbar zu machen. Andere Programme wiederum haben ausgesprochen strikte Vorstellungen darüber, welchem Benutzer und/oder welcher Gruppe die Dateien “gehören” müssen und wie die Zugriffsrechte auszusehen haben (so z.B. der Newsserver INN, der erwartet, dass der Key ausschließlich für den User news lesbar ist). In diesen Fällen wird es m.E. unausweichlich sein, Kopien der Zertifikate und des Keys mit den passenden Rechten anzulegen.

Dovecot

Der POP3- und IMAP-Server Dovecot greift als root auf die Zertifikate zu und kann - jedenfalls in seiner in Debian Jessie enthaltenen Version 2.2.13 - die Zertifikatskette (fullchain.pem) verarbeiten. Es genügt also, Zertifikat und Key einzubinden und die Serverkonfiguration neu einzulesen (service dovecot reload).

Exim

Anders sieht es mit dem SMTP-Server Exim aus. Dieser gibt seine Root-Rechte auf, bevor er auf die TLS-Zertifikate zugreift. Immerhin kommt auch er mit fullchain.pem klar.

Eine Möglichkeit ist es, Zertifikat und Key in ein passendes Verzeichnis zu kopieren und dann Eigentümer und Rechte (644!) anzupassen, bspw. so:

cd /etc/exim4
mkdir certs 
cp /etc/letsencrypt/live/domain.example/fullchain.pem /etc/exim4/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/exim4/certs/
service exim4 restart
chown Debian-exim:Debian-exim /etc/exim4/certs/
chown Debian-exim:Debian-exim /etc/exim4/certs/*
chmod 644 /etc/exim4/certs/*

Ein solches Vorgehen wird dann auch bei jeder Erneuerung der Zertifikate erforderlich (s.u.)!

Danach genügt es, die Serverkonfiguration neu zu laden (service exim4 reload) und sich dann zu Testzwecken auf Port 25 zu verbinden und nach dem EHLO ein STARTTLS abzusetzen.

INN

INN stellt - jedenfalls in der in Debian Jessie enthaltenen Version 2.5.4 - ganz besondere Ansprüche: jedenfalls der Key muss für den Benutzer news lesbar sein, und er benötigt cert.pem und chain.pem getrennt.

Umsetzen könnte man das bspw. so:

cd /etc/news
mkdir certs 
cp /etc/letsencrypt/live/domain.example/cert.pem /etc/news/certs/
cp /etc/letsencrypt/live/domain.example/chain.pem /etc/news/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/news/certs/
chown news:news /etc/news/certs/*
chmod 600 /etc/news/certs/*

Auch hier muss man dieses Vorgehen für eine Erneuerung der Zertifikate im Blick behalten (s.u.).

Ein Einlesen der inn.conf später (service inn2 restart) sollte dann alles funktionieren wie geplant.

Zertifikat-Updates

Die nunmehr im Dateisystem verstreuten Zertifikatskopien müssen nach jeder Erneuerung des Zertifikats gleichfalls erneuert werden, damit nicht ein ungültiges Zertifikat ausgeliefert wird. Sinnvollerweise geschieht das ebenso automatisiert wie die Erneuerung des Zertifikats; hilfreich dabei die Möglichkeit, letsencrypt (bzw. certbot) mittels --post-hook nach einem Zertifikatsaustausch ein Script ablaufen zu lassen.

Exim

Man könnte sich daher bspw. eine Datei /usr/local/bin/certbot-exim4-renew.sh mit folgendem Inhalt anlegen:

#!/bin/dash
cp /etc/letsencrypt/live/domain.example/fullchain.pem /etc/exim4/certs/
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/exim4/certs/
service exim4 reload

Dazu passt dann ein Cron-Eintrag der folgenden Art:

certbot certonly --quiet -n --webroot -w /var/www/domain.example -d domain.example --keep-until-expiring --post-hook /usr/local/bin/certbot-exim4-renew.sh

Damit wird versucht, das Zertifikat für diesen Hostnamen (domain.example) zu erneuern, jedoch nur, wenn es der Erneuerung bedürftig ist.

Der Aufruf sollte in der Crontab zeitlich vor dem allgemeinen Aufruf certbot renew --quiet erfolgen, damit erst das spezielle Zertifikat aktualisiert (und ggf. umkopiert) wird und danach die übrigen.

INN

Für den INN sähe diese Lösung analog mit einer Datei /usr/local/bin/certbot-inn2-renew.sh so aus:

#!/bin/dash
cp /etc/letsencrypt/live/domain.example/cert.pem /etc/news/certs
cp /etc/letsencrypt/live/domain.example/chain.pem /etc/news/certs
cp /etc/letsencrypt/live/domain.example/privkey.pem /etc/news/certs
cd /etc/news/certs
chown news:news *.pem
chmod 600 *.pem
service inn2 reload

Der Cron-Eintrag wäre dann entsprechend:

certbot certonly --quiet -n --webroot -w /var/www/domain.example -d domain.example --keep-until-expiring --post-hook /usr/local/bin/certbot-inn2-renew.sh

Auch dieser Eintrag muss zeitlich vor dem allgemeinen Aufruf certbot renew --quiet liegen.

Und ihr?

So richtig optimal erscheinen mir diese Lösungen noch nicht. Gibt es bessere Ideen? Andere Erfahrungen?

Nutzt ihr letsencrypt noch für andere Dienste als die oben genannten?

An Euren Erfahrungen und Lösungen wäre ich interessiert und freue mich daher über Kommentare, Hinweise und Ergänzungen.

Let's Encrypt - Updates

nospam@example.com (Thomas Hochstein) — Fri, 01 Jul 2016 04:19:00 +0000

Im April hatte ich über Let’s Encrypt berichtet, den Dienst, der angetreten ist, das Ausstellen und die Installation von Zertifikaten zu vereinfachen.

Der Betrieb lief seitdem gut und zuverlässig, und nachdem jetzt mehr als 90 Tage vergangen sind, kann ich auch berichten, dass die automatische Erneuerung der Zertifikate vor ihrem Ablauf gleichermaßen zuverlässig funktioniert; bemerkt habe ich sie nur durch die Benachrichtigungs-E-Mail meines Cronjobs. Ich bin also weiterhin sehr zufrieden. Aber es gibt natürlich nicht nur Updates durch Let’s Encrypt, sondern auch über Let’s Encrypt:

Der Let’s Encrypt-Client ist demletzt unter dem Namen Certbot von der Electronic Frontier Foundation (EFF) übernommen worden, eine Version 1.0 ist für Ende des Jahres angekündigt.

Andere Zertifikats-Anbieter setzen sich zudem jetzt mit dem Neuankömmling auseinander. Die einen springen auf den Zug auf und bieten neben StartSSL jetzt auch StartEncrypt, die anderen versuchen sich stattdessen lieber Rechte an dem Namen Let’s Encrypt zu sichern - ohne Erfolg, dafür aber mit Presseresonanz, nur vermutlich nicht solcher der erwünschten Art …

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.