Vor wenigen Tagen wurden verschiedene Sicherheitsprobleme im Zusammenhang mit dem Diffie-Hellman-Verfahren bei verschlüsselten Verbindungen bekannt (siehe z.B. Heise Newsticker: "Logjam-Attacke: Verschlüsselung von zehntausenden Servern gefährdet").
Wir haben uns inzwischen ausführlicher mit der Sache beschäftigt, und hier im Forum gab's an verschiedenen Stellen ja auch schon die ersten Diskussionen. Im Folgenden möchte ich etwas mehr Licht in die Sache bringen, einige Mißverständnisse beseitigen und unsere Strategie zu dieser Sache vorstellen.
1. Weder LiveConfig noch mit LiveConfig verwaltete Dienste sind von "Logjam" betroffen.
Mit "Logjam" wird der Angriffsvektor beschrieben, mit dem durch einen Man-in-the-middle-Angriff eine eigentlich sichere Verbindung auf unsichere Krypto-Parameter heruntergestuft wird. Das ist nur dann möglich, wenn der Server entsprechend unsichere Krypto-Parameter unterstützt - konkret ist hier von den "Export-Ciphers" die Rede.
LiveConfig selbst und auch die damit konfigurierten Dienste (Apache, NGINX, Postfix, Dovecot, ProFTPD/vsftpd) verwenden keine Export-Ciphers. Wir konfigurieren die von dem Mozilla OpSec Team empfohlenen Ciphers.
An dieser Stelle möchte ich übrigens dringend davon abraten, irgendwelche Cipher-Listen aus dem Internet zusammenzuklauben (konkret z.B. von der weakdh.org-Website), so lange man nicht genau weiß, was man da tut.
2. LiveConfig nutzt eigene DH1024-Parameter
Der zweite Angriffsvektor beruht auf der Vermutung von Forschern, dass Angreifer mit entsprechend großen Rechenkapazitäten (konkret: Geheimdienste, evtl. Industriespionage) die mit den am häufigsten genutzten Diffie-Hellman-Parametern erzeugten Schlüsseldaten knacken könnten.
LiveConfig verwendet aktuell (v1.8.3) 1024-Bit Diffie-Hellman-Parameter, die von uns vor einer Weile individuell erzeugt wurden (sind also keine Standard-Daten). Dennoch sind diese "statisch" (also auf allen Servern gleich) und derzeit - wie das bislang eben üblich war - direkt im Code enthalten.
Ein akutes Sicherheitsproblem besteht unsere Ansicht nach also nicht, weil es nach wie vor einen erheblichen Rechenaufwand benötigt, um die mit "unseren" DH-Parametern erzeugten Schlüsseldaten zu knacken.
Nichts desto trotz - wir werden das ändern (s.u.).
3. Apache 2.2 bleibt (vorerst) anfällig (Debian 6 LTS, Debian 7, Ubuntu 12.04 LTS, CentOS 5)
Die Distributionen Debian 6 (Squeeze), Debian 7 (Wheezy), Ubuntu 12 und CentOS 5 liefern Apache httpd in der Version 2.2.x aus - in der sind die DH-Parameter ebenfalls "hardcodiert" und können somit nicht ersetzt werden. Die verwendeten DH-Parameter sind überall die selben; potenzielle Angreifer werden sich also zuerst die Arbeit machen, Dienste mit diesen extrem weit verbreiteten Parametern zu knacken.
Unsere Empfehlung ist daher, diese "alten" Distributionen zu aktualisieren. Eventuell wird aber auch hier von den Distributionen ein Patch zurückportiert, der die DH-Parameter verwaltbar macht (bei CentOS 6 ist das nämlich der Fall - hier läuft auch ein httpd 2.2.x, der aber Änderungen aus der 2.4er-Reihe enthält).
Unsere nächste Schritte
Die Erzeugung von 2048bit DH-Parametern erfordert eine ganze Menge Rechenaufwand. Unsere Tests haben gezeigt, dass das auf einem handelsüblichen 3,0 GHz-System zwischen 20 Sekunden und fast 10 Minuten dauern kann - je nachdem, was der Pseudozufalls-Generator für Daten liefert. Wir haben daher beschlossen, künftig durch LiveConfig in einem Hintergrundprozess etwa alle zwei Wochen neue DH-Parameter für alle Services zu generieren; wenn diese "fertig" (berechnet) sind, ersetzt LiveConfig die dann selbständig im jeweiligen Dienst und startet den neu (Dovecot 2 macht das übrigens auch so).
Unser Ziel ist es also, dass LiveConfig sich völlig selbständig darum kümmert, dass für alle Dienste regelmäßig neuer Krypto-Input generiert (und aktiviert) wird - ohne dass der Admin da nun alle paar Wochen irgendwelche Dateien austauschen muss.
Das geht natürlich nicht von heute auf morgen, zudem muss das Ganze noch auf Kompatibilität mit anderen Systemen getestet werden. Die DH-Erzeugung wird also im nächsten Update (v1.9) enthalten sein, das Preview-Update mit dieser Funktion sollte Mitte/Ende nächster Woche soweit sein.
Anfang kommender Woche werden wir auf unserer Website eine eigene Testseite bereitstellen, bei der man die DH-Parameter aller Services auf einmal durchtesten kann (und nicht nur Port 443 wie etwa bei SSLLabs oder WeakDH).
Fazit
Die Sache ist ernst zu nehmen, aber bei weitem sind die Server deshalb nun nicht "offen". Die Export-Ciphers sind durch LiveConfig abgeschalten, einziger Angriff ist also mit erheblichem Aufwand über stark verbreitete DH-Parameter denkbar. Soweit ich weiß stuft SSLLabs derzeit auch noch keine Bewertung herab, sondern weist lediglich auf die schwachen Parameter hin.
In etwa einer Woche gibt's unsere Lösung zu diesem Thema.
Bis dahin: schöne Pfingsten schonmal! :cool:
Viele Grüße
-Klaus Keppler
