Beheben der Sicherheitsanfälligkeit "Logjam" in Apache (httpd)

Kürzlich wurde eine neue Sicherheitsanfälligkeit in Diffie-Hellman veröffentlicht, die informell als "logjam" bezeichnet wird. Auf dieser Seite wird vorgeschlagen, wie der Sicherheitsanfälligkeit begegnet werden kann:

Wir haben drei Empfehlungen für die korrekte Bereitstellung von Diffie-Hellman für TLS:

1. Deaktivieren Sie Export Cipher Suites. Obwohl moderne Browser keine Exportsuiten mehr unterstützen, ermöglichen die Angriffe von FREAK und Logjam einem Man-in-the-Middle-Angreifer, Browser zur Verwendung von Kryptografie in Exportqualität zu verleiten, wonach die TLS-Verbindung entschlüsselt werden kann. Export-Chiffren sind ein Überbleibsel der Politik der 1990er Jahre, die den Export starker kryptografischer Protokolle aus den USA verhinderte. Keine modernen Kunden verlassen sich auf Exportsuiten, und die Deaktivierung hat nur einen geringen Nachteil.
2. (Ephemere) Elliptic-Curve-Diffie-Hellman (ECDHE) einsetzen. Der Austausch von ECDH-Schlüsseln (Elliptic-Curve Diffie-Hellman) vermeidet alle bekannten durchführbaren kryptoanalytischen Angriffe, und moderne Webbrowser bevorzugen ECDHE gegenüber Diffie-Hellman, dem ursprünglichen Endlichfeld. Die diskreten Protokollalgorithmen, die wir für den Angriff auf Diffie-Hellman-Standardgruppen verwendet haben, profitieren nicht so stark von der Vorberechnung, und einzelne Server müssen keine eindeutigen elliptischen Kurven generieren.
3. Bilden Sie eine starke, einzigartige Diffie Hellman-Gruppe . Einige feste Gruppen werden von Millionen von Servern verwendet, was sie zu einem optimalen Ziel für Vorberechnungen und potenzielles Abhören macht. Administratoren sollten eindeutige Diffie-Hellman-Gruppen mit mindestens 2048-Bit generieren und dabei "sichere" Primzahlen für jede Website oder jeden Server verwenden.

Was sind die Best-Practice-Schritte, die ich ausführen sollte, um meinen Server gemäß den obigen Empfehlungen zu sichern?

In dem Artikel, den Sie verlinkt haben , werden drei Schritte empfohlen, um sich vor dieser Sicherheitsanfälligkeit zu schützen. Grundsätzlich gelten diese Schritte für jede Software, die Sie mit SSL / TLS verwenden. Hier werden wir uns jedoch mit den spezifischen Schritten befassen, um sie auf Apache (httpd) anzuwenden, da es sich um die betreffende Software handelt.

1. Deaktivieren Sie Export Cipher Suites

Behandelt in den Konfigurationsänderungen, die wir in 2. unten vornehmen ( !EXPORTam Ende der SSLCipherSuiteZeile wird beschrieben, wie Export-Cipher-Suites deaktiviert werden).

2. Bereitstellen (kurvenübergreifend) Elliptic-Curve Diffie-Hellman (ECDHE)

Dazu müssen Sie ein paar Einstellungen in der Apache - Konfigurationsdateien bearbeiten - und zwar SSLProtocol, SSLCipherSuite, SSLHonorCipherOrderhaben eine „Best-Practices“ setup. So etwas wie das Folgende reicht aus:

SSLProtocol             all -SSLv2 -SSLv3

SSLCipherSuite          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

SSLHonorCipherOrder     on

Hinweis: Welche SSLCipherSuiteEinstellung verwendet werden soll, ändert sich ständig. Es empfiehlt sich, Ressourcen wie diese zu konsultieren , um nach der neuesten empfohlenen Konfiguration zu suchen.

3. Erstellen Sie eine starke, einzigartige Diffie Hellman-Gruppe

Dazu kannst du laufen

openssl dhparam -out dhparams.pem 2048.

Beachten Sie, dass dies den Server erheblich belastet, während die Parameter generiert werden. Sie können dieses potenzielle Problem jederzeit umgehen, indem Sie die Parameter auf einem anderen Computer generieren und zur Verwendung scpauf den betreffenden Server übertragen.

So verwenden Sie diese dhparamsin Apache neu generierten Elemente in der Apache-Dokumentation :

Verwenden Sie den Befehl openssl dhparam, um benutzerdefinierte DH-Parameter zu generieren. Alternativ können Sie die folgenden Standard-1024-Bit-DH-Parameter aus RFC 2409, Abschnitt 6.2, an die jeweilige SSLCertificateFile-Datei anhängen :

(Hervorhebung von mir)

Darauf folgt ein standardmäßiger 1024-Bit-DH-Parameter. Daraus können wir schließen, dass die benutzerdefinierten DH-Parameter einfach an die betreffende SSLCertificateFileFrage angehängt werden können .

Führen Sie dazu Folgendes aus:

cat /path/to/custom/dhparam >> /path/to/sslcertfile

Alternativ können Sie gemäß dem Apache-Unterabschnitt des ursprünglich verlinkten Artikels auch die benutzerdefinierte dhparams-Datei angeben, die Sie erstellt haben, wenn Sie die Zertifikatsdatei selbst nicht ändern möchten.

SSLOpenSSLConfCmd DHParameters "/path/to/dhparams.pem"

in welcher Apache-Konfiguration (en) für Ihre spezielle SSL / TLS-Implementierung relevant sind - in der Regel in conf.d/ssl.confoder conf.d/vhosts.confaber dies hängt davon ab, wie Sie Apache konfiguriert haben.

Es ist erwähnenswert, dass, wie pro diesem Link ,

Vor Apache 2.4.7 ist der DH-Parameter immer auf 1024 Bit eingestellt und kann nicht vom Benutzer konfiguriert werden. Dies wurde in mod_ssl 2.4.7 behoben, das Red Hat mit httpd-2.2.15-32.el6 in seine RHEL 6 Apache 2.2-Distribution zurückportiert hat

Unter Debian Wheezy aktualisieren Sie apache2 auf 2.2.22-13 + deb7u4 oder höher und openssl auf 1.0.1e-2 + deb7u17. Die oben genannte SSLCipherSuite funktioniert nicht einwandfrei. Verwenden Sie stattdessen die folgenden Informationen in diesem Blog :

SSLCipherSuite ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-AES256-GCM-SHA384: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-DSS-AES128-SHA256:DHE-DSS-AES256-SHA:AES128-GCM-SHA256:AES256-GCM-SHA384: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:!DHE-RSA-AES128-GCM-SHA256:!DHE-RSA-AES256-GCM-SHA384:!DHE-RSA-AES128-SHA256:!DHE-RSA-AES256-SHA:!DHE-RSA-AES128-SHA:!DHE-RSA-AES256-SHA256:!DHE-RSA-CAMELLIA128-SHA:!DHE-RSA-CAMELLIA256-SHA

Sie sollten überprüfen, ob Ihre Apache-Version später als diese Versionsnummern ist, abhängig von Ihrer Distribution, und wenn nicht, aktualisieren Sie sie, wenn möglich.

Nachdem Sie die obigen Schritte ausgeführt haben, um Ihre Konfiguration zu aktualisieren, und den Apache-Dienst neu gestartet haben, um die Änderungen zu übernehmen, sollten Sie überprüfen, ob die Konfiguration den Anforderungen entspricht, indem Sie die Tests für SSLLabs und für den Artikel ausführen, der sich auf diese bestimmte Sicherheitsanfälligkeit bezieht.

Basierend auf einem Patch von Winni Neessen habe ich einen Fix für Apache / 2.2.22 (Debian Wheezy, möglicherweise auch unter Ubuntu verwendbar) veröffentlicht: https://flo.sh/debian-wheezy-apache2-logjam-fix/ - thx . für dein feedback.

Anstatt den komplexen Weg der oben genannten "Hacks" zu gehen, sollten Sie erwägen , auf nginx als Ihre hauptsächliche Webserver-Software (nicht nur Caching oder Proxy) umzusteigen. In Bezug auf die Sicherheit entspricht es offensichtlich mehr den aktuellen Standards als die alten Apache-Engines. Mit dem nginx-Repository erhalten Sie eine aktuellere stabile Webserver-Engine als mit Apache.

Ich bin komplett umgestiegen. Ich habe viel Zeit beim Lösen von Problemen in Bezug auf TLS gespart und - für unsere Konfigurationen - auch viel RAM im selben Zug freigesetzt. Tatsächlich fand ich die Verwendung von Nginx erfrischend einfach und unkompliziert, verglichen mit den unzähligen Konfigurationskomplikationen von httpd / apache, an die ich mich gewöhnt hatte. Könnte Geschmackssache sein, ich hatte mich vor meiner Umstellung in httpd / apache rewrite / config / maintenance ziemlich gut zurechtgefunden und es war einfacher, als ich befürchtet hatte. Aktuelle Informationen zu nginx config sind online verfügbar. Die Benutzerbasis ist riesig, sehr aktiv und unterstützungsfreundlich. https://news.netcraft.com/wp-content/uploads/2018/11/wpid-wss-top-1m-share.png