Spätestens seit 2013 gibt es Initiativen, die das XMPP-Netzwerk durch Transportverschlüsselung sicherer machen wollen. Mittlerweile unterstützen fast alle öffentlichen XMPP-Server zumindest optional Transportverschlüsselung via TLS oder SSL. Leider wird das Thema nur in den wenigsten Fällen wirklich ernst genommen - und das mache ich u.A. daran fest: In viel zu vielen Fällen können wir bei der Server-to-Server-Kommunikation folgendes finden:
- Verwendung von selbst signierten Zertifikaten
- Defekte / ungültige Zertifikatskonfigurationen (fehlendes Intermediate-Cert, abgelaufene Zertifikate, …)
- Tolerierung unverschlüsselter Verbindungen
Vor allem gegen den letzten Punkt muss unbedingt etwas unternommen werden. Viel zu viele Server priorisieren zwar verschlüsselte Verbindungen, verifizieren angebotene Zertifikate jedoch nicht, und wenn kein Zertifikat angeboten wird, wird via Dialback authentifiziert oder die Verschlüsselung gleich ganz deaktiviert. Besser könnten die Konditionen für MitM-Attacken kaum sein. Man signalisiert damit zwar Bereitschaft, zu verschlüsseln, aber wenn er andere nicht will, oder wenn ein Angreifer auf der Leitung sitzt, dann verschlüsselt man eben nicht. Es leuchtet ein, dass das nicht besonders viel Sinn ergibt. Wenn wir Zertifikate nicht prüfen und bereit sind, die Verschlüsselung zu deaktivieren, damit jemand mit uns spricht, können wir es auch gleich sein lassen, und unverschlüsselt kommunizieren. Der Effekt ist derselbe: Wer mithören will, kann mithören.
In mindestens zwei Anwendungsfällen ist die geringe Laufzeit von Let’s Encrypt Zertifikaten lästig: Bei der Nutzung von HPKP (Public Key Pinning) und DANE. Beide Verfahren sollen HTTPS-Verbindungen zusätzlich absichern, indem genau spezifiziert wird, welche TLS-Zertifikate für eine Domain gültig sein sollen. Da mindestens alle 90 Tage ein anderes Let’s Encrypt -Zertifikat eingerichtet werden muss, müssen in diesem Zyklus auch die HPKP- und DANE-Einstellungen mehr oder weniger aufwendig aktualisiert werden.
Der Aufwand lässt sich jedoch mit einem Trick reduzieren: Da beide Verfahren auf der Untersuchung des Public Keys im öffentlichen Zertifikat beruhen, kann man dafür sorgen, dass sich dieser bei der Umstellung auf ein neues Zertifikat nichts ändert. Man verwendet daher bei der Beantragung eines neuen LE-Zertifikats also keinen neuen Private Key, sondern einen alten. (Der Public Key basiert auf dem Private Key). Um einen alten Key nutzen zu können, muss der Referenzclient von Let’s Encrypt im Zusammenspiel mit einem eigenen, gleich bleibenden Private Key und einer eigenen Zertifikatsanfrage (CSR) verwendet werden.
Das Let’s Encrypt Projekt (hinter dem unter anderem Mozilla, Facebook und Cisco als Sponsoren stecken) ist gestern in den Public Beta Betrieb übergegangen. Von nun an können nach belieben kostenlose TLS (aka SSL)-Zertifikate für die eigenen Domains erstellt werden. Für den Erhalt eines Zertifikats sind nur wenige, einfache Schritte erforderlich, die ich im Folgenden erkläre:
Let’s Encrypt nutzt ein Protokoll namens “ACME” zur Kommunikation mit den CA-Servern. Ich habe den Referenz-ACME-Client “Certbot” von LE genutzt - um den soll es hier gehen. Außerdem wird der Client in dieser Anleitung direkt auf dem Zielserver ausgeführt - das ist die einfachere Methode. Wer den Client nicht auf dem Zielserver der Domains ausführen will oder kann (oder den laufenden Webserver-Betrieb nicht unterbrechen will), kann alternativ den “Manual Mode” verwenden (siehe Dokumentation unter: https://certbot.eff.org/docs/)