Schlagwort-Archive: SSL

Über Pinning (HPKP), CAA und Certificate Transparency

In der Vergangenheit habe ich mich auf diesem Blog bereits in verschiedenen Artikeln mit dem Thema Certificate Pinning befasst [vgl. 1-3]. Im vorliegenden Artikel möchte ich noch einmal kurz in Erinnerung rufen, worum es beim Pinning geht. Darüber hinaus finden Sie hier eine kurze Einführung in DNS Certification Authority Authorization (CAA) Resource Records (RFC 6844) [4] und Certificate Transparency (RFC 6962) [5].

Anschließend werden die vorgestellten Verfahren gegenübergestellt und hinsichtlich ihres Nutzens für einen „Subscriber“ und eine „Relying Party“ beurteilt.

Terminologie

Für das Verständnis des Artikels wichtige Begriffe werden in diesem Abschnitt definiert.

Subscriber stellt eine Entität dar, welche einen gesicherten Service anbieten möchte und hierfür ein Zertifikat benötigt.

Die Relying Party bezeichnet z.B. Webbrowser oder andere Programme, welche Zertifikate nutzen und versuchen, deren Echtheit zu validieren. Dies geschieht mit Hilfe von sogenannten trust anchors, also Zertifikaten, denen ultimativ vertraut wird und die in den Webbrowsern gespeichert sind.

Certificate Pinning (HPKP)

Certificate Pinning wurde im RFC 7469 [7] spezifiziert. Es handelt sich dabei um einen Mechanismus, bestimmte Eigenschaften eines Zertifikats festzunageln. Der Browser erhält dabei mit dem Zertifikat zusätzliche Informationen, mit denen er die Authentizität des Zertifikats überprüfen kann.

In der Praxis wird dem Browser ein Hash-Wert übermittelt, welcher über den öffentlichen Schlüssel des Zertifikats gebildet wurde. Dieser Hash-Wert wird in einem HTTP-Header-Feld an den Browser übertragen und von diesem gespeichert. Wie dieses Verfahren genau funktioniert, beschreibt der RFC 7469 ab Abschnitt 2.1.1. Da nur der Dienstbetreiber über den dazugehörigen privaten Schlüssel verfügt, ist ein Missbrauch durch Dritte ausgeschlossen. Übermittelt nun nämlich ein Angreifer bei einem MITM-Angriff den zu seinem Zertifikat gehörenden öffentlichen Schlüssel, kann der Browser mit Hilfe des PINs erkennen, dass dieser Schlüssel nicht dem Dienstbetreiber gehört und den Angriff damit auffliegen lassen.

Dem Subscriber steht mit dem Certificate Pinning ein wirksamer Mechanismus zur Verfügung, mit dem sich das Risiko, Opfer eines MITM-Angriffs zu werden, deutlich reduzieren lässt. Gleichzeitig ist die Implementierung von Pinning in eigene Projekte nicht trivial und das Risiko, den eigenen Internetauftritt durch Fehlkonfiguration für Besucher unerreichbar zu machen, entsprechend hoch (vgl. [1], [2], [6] und [7]).

Certification Authority Authorization (CAA)

CAA wurde Anfang 2013 im RFC 6844 spezifiziert. Es handelt sich dabei um einen DNS Ressource Record, mit dem ein Domain-Inhaber festlegen kann, welche Zertifizierungsstellen (CA) für seine Domain Zertifikate ausstellen dürfen [4].

Eine gute Einführung in deutscher Sprache findet sich im DFN-PKI Blog in den Artikeln unter [8] und [9].

Die Zertifizierungsstellen wurden vom CA/Browser-Forum im Ballot 187 [10] verpflichtet, spätestens ab September 2017 die CAA Resource Records auszuwerten und zu beachten.

Certificate Transparency (CT)

Laut Abstract des RFC 6962 [5] handelt es sich bei Certificate Transparency um ein experimentelles Protokoll zur Buchführung über ausgestellte TLS-Zertifikate.

Die Idee besteht im Wesentlichen darin, dass Zertifizierungsstellen (CA) ausgestellte Zertifikate in ein öffentliches (mutmaßlich revisionssicheres) Log eintragen. Das Ziel ist, Transparenz bei der Ausstellung von TLS-Zertifikaten herzustellen. So soll jeder Klient einsehen können, für welche Domains Zertifikate ausgestellt wurden und welche Zertifizierungsstellen diese ausgestellt haben.

Durch Überwachung dieser Certificate Transparency Logs können Domain-Inhaber (Subscriber) feststellen, ob TLS-Zertifikate für ihre Domains ausgestellt wurden, ohne dass die Ausstellung von ihnen autorisiert wurde. In diesem Fall können sie Schritte einleiten, um diese Zertifikate widerrufen zu lassen. Für den Widerruf muss auf bestehende Verfahren zurückgegriffen werden, da der Zertifikatswiderruf explizit kein Bestandteil des aktuellen Entwurfs ist.

Wie stehen diese Verfahren zueinander?

Im Kern haben alle drei Verfahren zum Ziel, die größte Schwachstelle der Internet-PKI abzudichten. Nämlich das Problem, dass jede CA Zertifikate für jede beliebige Domain ausstellen darf und eine Relying Party bisher nur schwer erkennen konnte, ob ein vertrauenswürdiges Zertifikat tatsächlich mit Autorisierung des Domain-Inhabers ausgestellt wurde. Dabei verfolgen die drei Verfahren unterschiedliche Ansätze.

Das Certificate Pinning kann vom Subscriber selbst implementiert werden. Er stellt der Relying Party damit Informationen zur Verfügung, mit denen diese überprüfen kann, ob das gültige Zertifikat tatsächlich vom Subscriber bzw. einer von ihm autorisierten CA stammt. Liefert die Validierung eines PINs ein negatives Ergebnis, wird ein Zugriff auf die entsprechende Webseite durch den Webbrowser verweigert. Pinning stellt für den Subscriber ein wirksames Mittel dar, um das Risiko von Zertifikatsmissbrauch zu reduzieren.

Doch wo Licht ist, ist auch Schatten. Die Implementierung von Certificate Pinning ist komplex [1] und führt bei kleinsten Fehlern bereits zur Nichterreichbarkeit der eigenen Domain. Die Komplexität und das Risiko, die eigene Domain unerreichbar zu machen, sind Gründe, warum das Pinning bisher nur eine sehr geringe Verbreitung erfahren hat. Und damit nicht genug. Kaum in der Welt, wird bereits über den Abschied vom HTTP Public Key Pinning diskutiert (vgl. [12] und [13]) und von einem großen Browserhersteller sogar das Ende der Unterstützung eingeläutet (siehe [14] und [15]).

CAA bietet dem Subscriber bzw. Domain-Inhaber über DNS-Einträge die Möglichkeit, CAs zur Ausstellung von Zertifikaten zu autorisieren. Dieser Schutz wirkt passiv, da er darauf basiert, dass sich die CAs an die Verpflichtung aus [10] halten. Schert sich eine CA nicht um diese Verpflichtung, wird durch staatliche Stellen zur Ausstellung von Zertifikaten gezwungen oder durch Einbruch kompromittiert [6, Abschnitt 2.5], können weiterhin Zertifikate ausgestellt werden, denen die Relying Party vertraut. Da eine Nutzung von CAA durch die Relying Party zum Zweck der Zertifikatsvalidierung explizit ausgeschlossen ist [8]. Auch der Subscriber muss sich auf die Selbstverpflichtung der CAs verlassen; kann er doch nicht prüfen, ob eine CA ein Zertifikat ohne seine Autorisierung ausgestellt hat.

Wer sich nun fragt, warum sich eine CA an CAA gebunden fühlen sollte, dem sei gesagt, dass bei einem Verstoß gegen CAA die Entfernung der eigenen Root CA aus dem trust anchor der Relying Party droht. So sollte es im eigenen Interesse einer CA liegen, CAA Records gewissenhaft auszuwerten und sich möglichst keine Fehler zu erlauben.

Certificate Transparency bietet einem Subscriber die Möglichkeit, durch Überwachung der CT Logs zu erkennen, ob TLS-Zertifikate ohne Autorisierung des Subscribers ausgestellt wurden. Dies setzt natürlich voraus, dass die ausstellende CA diese Zertifikate auch in einem CT Log einträgt. Doch welche Motivation hat eine CA, dies zu tun? Wenn die Browser (Relying Party) mit der größten Verbreitung zukünftig nur noch Zertifikate als vertrauenswürdig einstufen, welche in einem CT Log aufzufinden sind, wäre dies sicherlich eine Motivation. So könnten die großen Browserhersteller dieser Welt mit ihrer Marktmacht doch eine Transparenz erzwingen.

Mein persönliches Fazit

Als das Public Key Pinning das Licht der Welt erblickte, war ich von dessen Möglichkeiten begeistert und habe es auch selbst in verschiedenen Umgebungen eingesetzt (siehe [1] und [6]). Dabei habe ich erkannt, dass der Einsatz mit hohen Risiken verbunden ist und man sich sehr viele Gedanken über mögliche Auswirkungen in der Zukunft machen muss. Aktuell setze ich in meinen Projekten auf Grund der Risiken kein Pinning mehr ein. Googles Ankündigung, die Unterstützung aus dem Chrome Browser zu entfernen, klingt wie ein Todesstoß für dieses Verfahren. Es bleibt abzuwarten, ob Mozilla mit dem Firefox nachzieht oder das Pinning als Abgrenzungsmerkmal weiter unterstützt.

Insgesamt würde ich mich freuen, wenn man HPKP doch noch retten kann. Denn im Gegensatz zu CAA und CT stellt es für mich die effizienteste und wirksamste Technik dar, um mich selbst und meine Nutzer vor Zertifikatsbetrug schützen zu können. Dies sage ich, ohne CAA und CT damit abwerten zu wollen. Auch diese beiden Verfahren tragen dazu bei, die Schwachstelle im Design der Internet-PKI zu verkleinern und sie können gerade in Kombination dazu beitragen, das Potenzial für Zertifikatsmissbrauch deutlich zu reduzieren.

Quellen und weiterführende Links

  1. Certificate Pinning mit NGINX
  2. Pinning-Test im Firefox bei lokaler Root-CA erzwingen
  3. Mein TLS/SSL-Kochbuch
  4. DNS Certification Authority Authorization (CAA) Resource Record – RFC 6844 {en}
  5. Certificate Transparency – RFC 6962 {en}
  6. TLS-Kochbuch – Rezepte für die Verwendung von OpenSSL, HTTP Strict Transport Security (HSTS) und HTTP Public Key Pinning (HPKP)
  7. Public Key Pinning Extension for HTTP – RFC 7469 {en}
  8. RFC 6844 Certification Authority Authound Folgenrization (CAA)
  9. CAA RRs – Reihenfolge im DNS
  10. Ballot 187 – Make CAA Checking Mandatory {en}
  11. http://www.certificate-transparency.org/ {en}
  12. Ivan Ristic Is HTTP Public Key Pinning Dead? {en}
  13. Scott Helme: I’m giving up on HPKP {en}
  14. Scott Helme: The death knell for HPKP? {en}
  15. heise Security: HTTPS-Verschlüsselung: Google verabschiedet sich vom Pinning

Protokoll zum Ausfall eines Webdienstes nach der fehlgeschlagenen Erneuerung eines Let’s Encrypt Zertifikats

In diesem Beitrag werden die Ursache und der Verlauf der Störung protokolliert, welche die vorübergehende Nichterreichbarkeit einer Seafile[1. Seafile – Wikipedia]-Installation zur Folge hatte, welche ich für den Freifunk Lippe[2. Webpräsenz Freifunk Lippe] betreibe.

Beschreibung der Umgebung

Die Seafile-Installation wird ausführlich in „Installation von Seafile auf einem Ubuntu/Debian Server“ beschrieben. Die aktuelle Installation wurde wie dort erwähnt zusätzlich mit HSTS (TLS-Kochbuch, Abschnitt 2.7) und HPKP (TLS-Kochbuch, Abschnitt 2.8) gesichert. Das benötigte TLS-Zertifikat stammt von Let’s Encrypt (Abschnitt 3.4.1, TLS-Kochbuch).

Zur automatisierten Verlängerung wird das Skript smartrenew.sh verwendet, welches in Abschnitt 5.4 im TLS-Kochbuch beschrieben wird.

Eingang der Störungsmeldung

Die Störungsmeldung ging am 04.02.2017 per E-Mail. Die Meldung wies auf einen Fehler bei der Erneuerung des Zertifikats durch Let’s Encrypt hin:


arsing account key...
Parsing CSR...
Registering account...
Already registered!
Verifying seafile.example.com...
Traceback (most recent call last):
  File "acme-tiny-by-frezbo/acme_tiny.py", line 200, in 
    main(sys.argv[1:])
  File "acme-tiny-by-frezbo/acme_tiny.py", line 196, in main
    signed_crt = get_crt(args.account_key, args.csr, args.acme_dir, verifychallenge=args.verifychallenge, log=LOGGER, CA=args.ca)
  File "acme-tiny-by-frezbo/acme_tiny.py", line 150, in get_crt
    domain, challenge_status))
ValueError: seafile.example.com challenge did not pass: {u'status': u'invalid', u'validationRecord': [{u'url': u'http://seafile.example.com/.well-known/acme-challenge/ag0bYKs4XzfkYlzRPYLC1cFtv-ypEIQCEVfYulPlMGk', u'hostname': u'seafile.example.com', u'addressUsed': u'IPv4-Adresse', u'port': u'80', u'addressesResolved': [u'IPv4-Adresse', u'IPv6-Adresse']}, {u'url': u'https://seafile.example.com/.well-known/acme-challenge/ag0bYKs4XzfkYlzRPYLC1cFtv-ypEIQCEVfYulPlMGk', u'hostname': u'seafile.example.com', u'addressUsed': u'IPv4-Adresse', u'port': u'443', u'addressesResolved': [u'IPv4-Adresse', u'IPv6-Adresse']}], u'keyAuthorization': u'ag0bYKs4XzfkYlzRPYLC1cFtv-ypEIQCEVfYulPlMGk.pW0Gip0L_WLx7XEnmH_3ZArt9Vi4TbokaUuSXsc1dm4', u'uri': u'https://acme-v01.api.letsencrypt.org/acme/challenge/u5hporNk0I5YunYlQQeJPKdRyd-9BKGMWjBhm_7Za9E/578797992', u'token': u'ag0bYKs4XzfkYlzRPYLC1cFtv-ypEIQCEVfYulPlMGk', u'error': {u'status': 403, u'type': u'urn:acme:error:
 unauthorized', u'detail': u'Invalid response from http://seafile.example.com/.well-known/acme-challenge/ag0bYKs4XzfkYlzRPYLC1cFtv-ypEIQCEVfYulPlMGk: "\r\n404 Not Found\r\n\r\n404 Not Found\r\n"'}, u'type': u'http-01'}
 * Reloading nginx configuration nginx
   ...fail!

Der Fehlermeldung ist zu entnehmen, dass die ACME-Challenge nicht verifiziert werden konnte, da der Server auf die Anfrage mit der Meldung „404 Not Found“ antwortete. Dieser Fehler konnte durch Aufruf der URL mit dem Programm wget bestätigt werden.

Ergebnis der Systemanalyse

Die Analyse der NGINX-Konfiguration ergab, dass der von Let’s Encrypt signierte öffentliche Schlüssel des Zertifikats nicht zum dazugehörenden privaten Schlüssel passte. Dies hatte zur Folge, dass sich die Webseite im Browser, der HSTS und HPKP unterstützt, nicht mehr aufgerufen werden konnte. Denn durch HSTS wird auch ein Aufruf der Seite über HTTP automatisch auf HTTPS umgeleitet. Hier wird nun durch HPKP ebenfalls festgestellt, dass der gepinnte Key nicht mit dem vom Webserver ausgelieferten übereinstimmte und der Browser verweigerte den Aufruf der Webseite.

Die Ursache hierfür lag in der fehlenden Fehlerbehandlung im folgenden Skript:


python acme-tiny-by-frezbo/acme_tiny.py --no-verify --account-key /var/www/seafile.example.com/ssl/account.key --csr /var/www/seafile.example.com/ssl/seafile.example.com.csr --acme-dir /var/www/seafile.example.com/public/.well-known/acme-challenge/ > /var/www/seafile.example.com/ssl/seafile.example.com.crt

cat /var/www/seafile.example.com/ssl/seafile.example.com.crt /var/www/seafile.example.com/ssl/lets-encrypt-x3-cross-signed.pem > /var/www/seafile.example.com/ssl/seafile.example.com_chained.crt

sudo service nginx reload

Zuerst versucht das Skript, das Zertifikat zu erneuern und in die Datei seafile.example.com.crt zu schreiben. Schlägt dieser Vorgang fehl, wird durch den zweiten Teil des Skripts trotzdem aus der korrupten Datei und dem Intermediate-Zertifikat die Zertifikatskette erstellt und in der Datei seafile.example.com_chained.crt gespeichert.

In diesem Fall trat bei der Erneuerung des Zertifikats ein Fehler auf. Es wurde jedoch trotzdem eine Datei namens seafile.example.com.crt mit einer Größe von 0 Byte erstellt. Daher fehlte das Zertifikat auch in der daraufhin erstellten Zertifikatskette. Dies hatte zur Folge, dass durch HPKP der Webbrowser den Zugriff auf die Domain verweigerte und die Anwendung nicht mehr erreichbar war.

Eine Überprüfung der Datensicherung ergab leider, dass das Verzeichnis mit den Zertifikatsdateien nicht Bestandteil des Backups war. Somit war die schnelle Wiederherstellung der Zertifikatskette nicht möglich.

Störungsbeseitigung

Um die Störung zu beseitigen, wurde zuerst die bestehende vHost-Konfiguration für die Seafile-Instanz deaktiviert. Anschließend wurde ein neuer vHost eingerichtet, der ausschließlich via HTTP das Verzeichnis ausliefert, welches die ACME-Challenge beinhaltet:


server {
        listen       80;
        server_name  seafile.example.com;

        root /var/www/seafile.example.com/public/;
        location / {
        index index.html index.htm index.php;
        }
}

Nun wurde das Skript zur Erneuerung des Let’s Encrypt Zertifikats erneut gestartet. Das Skript lief diesmal fehlerfrei durch und es wurde wieder eine vollständige Zertifikatskette erstellt und in der vorgesehenen Datei gespeichert.

Daher konnte die temporäre vHost-Konfiguration nun wieder deaktiviert und die ursprüngliche Konfiguration wieder aktiviert werden.

Maßnahmen zur Risikominimierung

Nachdem mich die Störung natürlich zur ungünstigsten Zeit (welche Zeit ist für eine Störung schon günstig?) erwischt hat, habe ich mir Gedanken gemacht, wie sich das Risiko minimieren lässt, dass mich der gleiche Ärger in Zukunft nochmal ereilt.

Datensicherung anpassen

Zuerst habe ich meine Datensicherung angepasst und das Verzeichnis, welches die Zertifikatsdateien enthält, mit ins Backup aufgenommen. Selbstverständlich ist das Backup nur die halbe Miete. Ob sich dieses erfolgreich wiederherstellen lässt, muss natürlich auch getestet werden.

Fehler bei der Skript-Ausführung abfangen

Wie weiter oben bereits beschrieben, begann die ganze Problematik damit, dass das Skript zur Zertifikatserneuerung weiterarbeitete, obwohl bereits bei der Erneuerung des Zertifikats ein Fehler aufgetreten war.

Zukünftig soll das Skript abbrechen, wenn bei der Verarbeitung ein Fehler auftritt. Dazu wurde es wie folgt erweitert:


function check() {
  if [ $1 -gt 0 ]; then
    echo "Uuups, hier ist was schiefgegangen"
    echo "exit $1"
    exit 1
  fi
}

python acme-tiny-by-frezbo/acme_tiny.py --no-verify --account-key /var/www/seafile.example.com/ssl/account.key --csr /var/www/seafile.example.com/ssl/seafile.example.com.csr --acme-dir /var/www/seafile.example.com/public/.well-known/acme-challenge/ > /var/www/seafile.example.com/ssl/seafile.example.com.crt

check $?

cat /var/www/seafile.example.com/ssl/seafile.example.com.crt /var/www/seafile.example.com/ssl/lets-encrypt-x3-cross-signed.pem > /var/www/seafile.example.com/ssl/seafile.example.com_chained.crt

check $?

sudo service nginx reload

Schlägt die Erneuerung des Zertifikats fehl, gibt das Kommando einen Exit-Status größer Null zurück. Dies wird von der check-Funktion erkannt und das Skript abgebrochen. Dadurch bleiben die alte Datei mit der Zertifikatskette erhalten und der Dienst bleibt verfügbar, bis das Problem mit der Zertifikatserneuerung behoben werden kann.

ejabberd mit Let’s Encrypt Zertifikat

In diesem Artikel wird dokumentiert, wie ein Let’s Encrypt[1. https://letsencrypt.org/ {en}] [2. Let’s Encrypt – Wikipedia] Zertifikat für ejabberd eingerichtet werden kann. Dabei stütze ich mich auf mein TLS-Kochbuch[3. TLS/SSL Kochbuch: Rezepte für die Verwendung von OpenSSL, HTTP Strict Transport Security (HSTS) und HTTP Public Key Pinning (HPKP)].

Die Dokumentation bezieht sich dabei auf meine konkrete Installation und ist nicht ohne Transferleistung auf andere Installationen übertragbar. Es ist also keine Schritt-für-Schritt-Anleitung! Der Artikel bietet über die Dokumentation hinaus jedoch auch Hintergrundinformationen und Wissenswertes für abweichende Konfigurationen.

Ausgangssituation

In meiner Umgebung ist ejabberd auf einem Ubuntu Server 14.04 LTS[4. Trusty Tahr – wiki.ubuntuusers.de] installiert und nutzt ein TLS-Zertifikat von CAcert[5. https://www.cacert.org/ {en}] [6. CAcert – Wikipedia].

Außer ejabberd läuft auf dem Server auch noch ein Webserver, welcher verschiedene Webseiten ausliefert.

Daneben ist bereits der Let’s Encrypt Client acme-tiny[7. Fork des acme-tiny Clients auf GitHub {en}] installiert, dessen Verwendung in Abschnitt 3.6.2 TLS-Kochbuch erläutert wird.

Der Ablauf im Überblick

Wie vorstehend bereits erwähnt, verwendet ejabberd bereits ein TLS-Zertifikat, welches nun durch ein Let’s Encrypt Zertifikat ersetzt werden soll. Der Ablauf gliedert sich dabei im Wesentlichen in zwei Teile. Zuerst wird ein Let’s Encrypt Zertifikat für den Hostnamen des ejabberd-Servers ausgestellt. Anschließend wird ejabberd konfiguriert, um zukünftig dieses Zertifikat zu nutzen.

Zur Durchführung der Domainvalidierung wird ein VirtualHost für den Hostnamen des ejabberd-Servers konfiguriert. Da sich die genaue Konfiguration je nach verwendeter Webserver-Software unterscheidet, wird hier nicht näher darauf eingegangen, sondern auf die Dokumentation des jeweiligen Webservers verwiesen.

Generierung des TLS-Zertifikats

Nun wird mit Hilfe von OpenSSL[8. OpenSSL: Cryptography and SSL/TLS Toolkit {en}] [9. OpenSSL – Wikipedia] ein privater Schlüssel und eine Zertifikatsanfrage (engl. Certificate Signing Request (CSR)) erstellt. Beide Schritte werden ausführlich in Abschnitt 3.1 TLS-Kochbuch beschrieben.

Ich persönlich generiere den privaten Schlüssel und den CSR stets offline auf einem sicheren Computer. Anschließend lade ich sie zum Server hoch. Die Zugriffsrechte auf den Schlüssel sind so eingeschränkt, dass nur root und der Benutzer, unter dem der Webserver ausgeführt wird, diesen Schlüssel lesen dürfen.

Da bereits eine Installation von acme-tiny auf dem Server existiert und bereits ein Account-Key erstellt wurde, wird dieser in dem Verzeichnis verlinkt, in dem auch der private Schlüssel und der CSR liegen.

Nun kann das TLS-Zertifikat angefordert werden. Wie dies im Detail funktioniert, wird in Abschnitt 3.6.2 im TLS-Kochbuch beschrieben.

Sind bis hier alle Schritte erfolgreich gewesen, liegen nun Schlüssel und Zertifikat in einem Verzeichnis vor.

$ python acme-tiny/acme_tiny.py --account-key /var/www/sites/ssl/account.key --csr /var/www/sites/ssl/request.csr --acme-dir /var/www/sites/public/.well-known/acme-challenge/ > /var/www/sites/ssl/cert.crt
Parsing account key...
Parsing CSR...
Registering account...
Already registered!
Verifying fqdn...
fqdn verified!
Signing certificate...
Certificate signed!

$ ls -l /var/www/sites/ssl/
-rw-r—– 4 root root account.key
-rw-r—– 1 root www-data cert.crt
-rw-r—– 1 root root priv.key
-rw-r—– 1 root root request.csr

Zertifikat für ejabberd präparieren

Der Dienst ejabberd erwartet, dass der private Schlüssel, das Zertifikat und die Zertifikatskette in einer Datei übergeben werden.[10. Ejabberd SSL Certificate – Raymii.org {en}] Dazu wird noch die Zertifikatskette von Let’s Encrpyt[11. Let’s Encrypt: Chain of Trust {en}] heruntergeladen und ebenfalls in /var/www/sites/ssl/ gespeichert.

Das folgende Skript zeigt, wie das Zertifikat erzeugt, die Zertifikatsdatei für ejabberd zusammengesetzt und der Dienst neugestartet wird:

#!/bin/bash
# Datum: 2016-11-13
# Autor: Joerg Kastning <webmaster(aet)my-it-brain(Punkt)de>
#
# Beschreibung:
# Dieses Skript dient der Erneuerung des TLS-Zertifikats fuer
# jabber.my-it-brain.de über Let's Encrypt mit dem Client acme-tiny-by-frezbo.

DIR='/var/www/sites/ssl'

# Erneuerung des Zertifikats
python acme-tiny-by-frezbo/acme_tiny.py --account-key ${DIR}/account.key --csr ${DIR}/request.csr --acme-dir /var/www/sites/fqdn/.well-known/acme-challenge/ > ${DIR}/cert.crt

# Erzeugung der Zertifikatsdatei fuer ejabberd
cat ${DIR}/priv.key ${DIR}/cert.crt ${DIR}/lets-encrypt-x3-cross-signed.pem >${DIR}/ejabberd_cert.pem

sudo chown root:ejabberd ${DIR}/ejabberd_cert.pem
sudo chmod 0640 ${DIR}/ejabberd_cert.pem
sudo mv ${DIR}/ejabberd_cert.pem /etc/ejabberd/ejabberd_cert.pem

# Neustart von ejabberd
sudo service ejabberd restart

Abschluss der Migration

Durch den im vorangegangenen Abschnitt dargestellten Code wird das neue Let’s Encrypt Zertifikat an der gleichen Stelle und unter dem gleichen Dateinamen wie das alte Zertifikat abgelegt. Auf diese Weise muss die Konfiguration von ejabberd nicht weiter angepasst werden. Der Dienst lädt nach einem Neustart das neue Zertifikat. Die Migration ist damit abgeschlossen.

Let’s Encrypt Zertifikate besitzen eine Gültigkeit von 90 Tagen.[12. Let’s Encrypt: Why ninety-day lifetimes for certificates? {en}] Um die Erneuerung des Zertifikats zu automatisieren, wird das Skript „SmartRenew.sh“ verwendet (siehe Abschnitt 5.4 im TLS-Kochbuch).

Quellen und weiterführende Links:

Der eigene Mailserver – TLS-Migration zu Let’s Encrypt

Durch die Ankündigung von Mozilla, den Zertifizierungsstellen StartCom und WoSign das Vertrauen entziehen zu wollen,[1. Golem: Mozilla will Startcom und Wosign das Vertrauen entziehen] [2. Mozilla’s proposed conclusion for community discussion, regarding the matter of WoSign and StartCom. {en}] entstand für mich Handlungsbedarf. Denn ich wollte die Zertifikate dieser Anbieter nun so schnell wie möglich loswerden.

In Teil 2 meiner Artikelreihe „Der eigene Mailserver“ wird ein TLS/SSL-Zertifikat von StartSSL verwendet, um dieses zur Absicherung von Postfix, Dovecot und dem Webmailer Roundcube zu verwenden. An dieser Stelle halte ich nun die Umstellung auf TLS-Zertifikate von Let’s Encrypt fest.

Für die Bereitstellung und automatisierte Erneuerung der Zertifikate verwende ich certbot-auto.[3. Automatically enable HTTPS on your website with EFF’s Certbot, deploying Let’s Encrypt certificates. {en}] Dessen Installation und Nutzung wird in Abschnitt 3.6.1 TLS-Kochbuch[4. TLS-Kochbuch – Rezepte für die Verwendung von OpenSSL, HTTP Strict Transport Security (HSTS) und HTTP Public Key Pinning (HPKP)] beschrieben.

Das von cerbot-auto erzeugte Zertifikat und der dazugehörige private Schlüssel werden unter dem Pfad /etc/letsencrypt/live/ abgelegt. Um das Zertifikat in die gewünschten Dienste einzubinden, ist der Pfad zum Zertifikat in den Konfigurationsdateien der Dienste zu aktualisieren. Das folgende Listing gibt den Namen der Konfigurationsdateien und der anzupassenden Parameter wieder:

# /etc/nginx/sites-available/roundcube
ssl_certificate /etc/letsencrypt/live/FQDN/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/FQDN/privkey.pem;

# /etc/postfix/main.cf
smtpd_tls_cert_file = /etc/letsencrypt/live/FQDN/fullchain.pem
smtpd_tls_key_file = /etc/letsencrypt/live/FQDN/privkey.pem

# /etc/dovecot/conf.d/99-mail-stack-delivery.conf
ssl_cert =

Die Konfiguration der Dienste muss anschließend neu geladen werden. Um dies bei zukünftigen Erneuerungen des Zertifikats zu automatisieren, habe ich ein kleines Skript renew_certs.sh erstellt, welches täglich via Cron ausgeführt wird.

#!/bin/sh
/home/USERNAME/certbot/certbot-auto renew --quiet --no-self-upgrade
sudo service nginx reload
sudo service postfix reload
sudo service dovecot reload

certbot-auto renew erneuert das Zertifikat, sobald die Gültigkeitsdauer kleiner 30 Tage ist. Durch die tägliche Ausführung soll sichergestellt werden, dass die Aktualisierung auch dann rechtzeitig gelingt, sollte die Schnittstelle von Let’s Encrypt vorübergehend nicht erreichbar sein.

Mein TLS/SSL-Kochbuch

Heutzutage werden immer mehr Kommunikationsverbindungen im Internet mit TLS/SSL-Verbindungen geschützt. Die Verschlüsselung hilft, die Vertraulichkeit der zwischen Sender und Empfänger übertragenen Daten zu schützen und sollte daher standardmäßig aktiviert sein. Doch bereitet der Einsatz von TLS/SSL-Verschlüsselung noch immer vielen Administratoren und Betreibern verschiedenster Anwendungen Kopfschmerzen. Zu undurchsichtig scheint der Dschungel aus Zertifizierungsstellen, Zertifikaten, Zertifikatsanfragen, öffentlichen und privaten Schlüsseln zu sein. Verschiedenste Validierungsverfahren und Dateiformate für Zertifikate tragen nicht gerade dazu bei, den Durchblick zu behalten. Bereits die Erstellung einer Zertifikatsanfrage gerät dabei häufig genug zu einem Problem. Die richtige Konfiguration der zu sichernden Server bzw. Dienste erscheint kompliziert und Fehler in der Konfiguration führen nicht selten zur Nichterreichbarkeit einer Webseite. Die Folge: Immer noch wird viel zu häufig auf den Einsatz von TLS/SSL-Verschlüsselung verzichtet.

Mit meinem TLS-Kochbuch möchte ich dazu beitragen, etwas Licht ins Dunkel zu bringen. Darin finden sich Rezepte mit praktischen Tipps für die Verwendung von TLS/SSL-Verschlüsselung mittels OpenSSL, HTTP Strict Transport Security (HSTS) und HTTP Public Key Pinning (HPKP).

Aus dem Inhalt

Nach der Einleitung führt Kapitel 2 in das Thema ein und definiert die wesentlichen Begriffe. Es bildet die Grundlage für das Verständnis der daran anschießenden Kapitel.

In Kapitel 3 geht es um die Implementierung von TLS/SSL. Hier werden verschiedene Methoden zur Generierung von privaten Schlüsseln und Certificate Signing Requests vorgestellt. Darüber hinaus werden einige Zertifizierungsstellen kurz vorgestellt, bei denen Zertifikate beantragt werden können. Im Folgenden wird auf die Implementierung von TLS/SSL-Zertifikaten in verschiedenen Diensten eingegangen. Hier wird insbesondere die Implementierung von Zertifikaten der recht jungen Zertifizierungsstelle „Let’s Encrypt“ erläutert, mit deren Hilfe sich der Prozess der Zertifikatserneuerung automatisieren lässt.

Der Implementierung des HTTP Public Key Pinning (HPKP) widmet sich Kapitel 4. Das Pinning-Verfahren wird am Beispiel des Webservers NGINX erläutert und getestet.

Zum Schluss werden die in den einzelnen Kapiteln vorgestellten Techniken und Methoden nochmals zusammenfassend an einem konkreten Beispiel in Kapitel 5 verdeutlicht.

Hier geht es zum Text

Mir persönlich hat die Arbeit an folgendem Dokument geholfen, mich detailliert mit der Thematik auseinanderzusetzen und mein Wissen zu erweitern und zu vertiefen. Ich freue mich, wenn mein Kochbuch auch euch dabei hilft, ein besseres Verständnis für das Thema zu entwickeln.

Dies ist die erste Ausgabe meines TLS/SSL-Kochbuchs und es gibt sicher noch viel mehr, was man zu diesem Thema schreiben kann. Fehler sowie Wünsche zum Inhalt zukünftiger Ausgaben können gern an die E-Mail-Adresse tls-rezepte(aet)my-it-brain(Punkt)de gemeldet werden.

Downloads zum Text

SSL-Schwachstelle bedroht Web- und Mail-Server

Diverse Seiten im Internet berichten über eine neue SSL-Schwachstelle, die durch eine sogenannte Logjam-Attacke ausgenutzt werden kann.[1. Logjam-Attacke: Verschlüsselung von zehntausenden Servern gefährdet] [2. Tausende Web-Server betroffen: Neue HTTPS-Sicherheitslücke aufgetaucht] [3. Guide to Deploying Diffie-Hellman for TLS]

Dieser Artikel beschreibt, wie sich NGINX, Postfix und Dovecot härten lassen. Damit sind diese Dienste nicht mehr verwundbar für die aktuelle SSL-Schwachstelle.

Ich beschreibe die drei genannten Dienste, da ich diese selbst auf mehreren Ubuntu-Servern betreibe. Für weitere Dienste schaut bitte in der Quelle unter Punkt „3.“ nach.

Zu Beginn wird eine Diffie-Hellman-Group für den Server generiert:

openssl dhparam -out dh_params.pem 2048

Anschließend folgt die Härtung der einzelnen Dienste.

NGINX

Im server Block der jeweiligen Webpräsenz werden die zu verwendenden „Cipher Suites“ und Diffie-Hellman-Parameters angegeben:

ssl_ciphers 'ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA';

ssl_prefer_server_ciphers on;

ssl_dhparam /pfad/zur/dh_params.pem;

Anschließend wird der Dienst zur Übernahme der Einstellungen neu geladen:

sudo service nginx reload

Postfix

Beim MTA Postfix werden beide Parameter in der Datei /etc/postfix/main.conf eingetragen:

smtpd_tls_mandatory_exclude_ciphers = aNULL, eNULL, EXPORT, DES, RC4, MD5, PSK, aECDH, EDH-DSS-DES-CBC3-SHA, EDH-RSA-DES-CDC3-SHA, KRB5-DE5, CBC3-SHA
smtpd_tls_dh1024_param_file = /pfad/zur/dh_params.pem

Auch hier werden die Einstellungen anschließend neu eingelesen:

sudo service postfix reload

Dovecot

Die beiden Parameter werden in die Datei /etc/dovecot/conf.d/10-ssl.conf eingetragen:

ssl_cipher_list=ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384:DHE-RSA-AES128-GCM-SHA256:DHE-DSS-AES128-GCM-SHA256:kEDH+AESGCM:ECDHE-RSA-AES128-SHA256:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA:ECDHE-ECDSA-AES128-SHA:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA:ECDHE-ECDSA-AES256-SHA:DHE-RSA-AES128-SHA256:DHE-RSA-AES128-SHA:DHE-DSS-AES128-SHA256:DHE-RSA-AES256-SHA256:DHE-DSS-AES256-SHA:DHE-RSA-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384:AES128-SHA256:AES256-SHA256:AES128-SHA:AES256-SHA:AES:CAMELLIA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!RC4:!MD5:!PSK:!aECDH:!EDH-DSS-DES-CBC3-SHA:!EDH-RSA-DES-CBC3-SHA:!KRB5-DES-CBC3-SHA
ssl_prefer_server_ciphers = yes

#regenerates every week
ssl_dh_parameters_length = 2048

Und auch hier werden die Änderungen anschließend eingelesen:

sudo doveadm reload

Damit sollte man vor dieser Schwachstelle vorerst geschützt sein.