Implementierung von SSL Perfect Forward Secrecy im NGINX-Webserver

Dieses HOW-TO beschreibt den Prozess der Implementierung von Perfect Forward Secrecy mit dem NGINX-Webserver auf Debian- und Ubuntu-Systemen. Der Prozess kann leicht an andere GNU/Linux-Systeme angepasst werden.

Kurz gesagt, Perfect Forward Secrecy stellt sicher: “… dass der Kompromiss einer Nachricht nicht zum Kompromiss anderer führen kann und dass es auch keinen einzelnen geheimen Wert gibt, der zum Kompromiss mehrerer Nachrichten führen kann.” Für weitere Informationen siehe http://en.wikipedia.org/wiki/Forward_secrecy#Perfect_forward_secrecy.

Als die Heartbleed-Sicherheitsanfälligkeit in OpenSSL Anfang 2014 bekannt wurde, wurde zunehmend klar, dass PFS ein Muss für jedes System ist, das SSL/TLS ernsthaft einsetzt.

Sollten Sie Ihre Ergebnisse mit meinen vergleichen wollen, kann meine Referenzimplementierung unter https://www.ssllabs.com/ssltest/analyze.html?d=indietorrent.org getestet werden, und die SSL-Zertifikatkette sowie die gesendeten NGINX-Header können unter https://indietorrent.org überprüft werden.

Ohne weitere Umschweife, lassen Sie uns NGINX konfigurieren, um PFS zu implementieren.

Lassen Sie uns in das Konfigurationsverzeichnis von NGINX wechseln:

cd /etc/nginx/

Wir müssen Diffie-Hellman-Parameter generieren, die ausreichend stark sind. Einige argumentieren, dass 4096 Bit übertrieben ist und die CPU des Systems unnötig belastet, aber mit der modernen Rechenleistung scheint dies ein lohnenswerter Kompromiss zu sein. Für weitere Informationen siehe den Abschnitt Referenzen weiter unten.

openssl dhparam -out dh4096.pem 4096

Es ist praktisch, diese Konfigurationsdatei, die spezifisch für die jeweilige Aufgabe ist, in einer Include-Datei zu kapseln; dies macht es einfacher, PFS über eine große Anzahl von Systemen zu implementieren.

vi /etc/nginx/perfect-forward-secrecy.conf

Fügen Sie Folgendes in die obige Datei ein:

ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
ssl_prefer_server_ciphers on;
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 \
EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH+aRSA+RC4 \
EECDH EDH+aRSA RC4 !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !MEDIUM";
ssl_dhparam dh4096.pem;

Ändern Sie die NGINX-Konfiguration, um die obige Datei einzuschließen, indem Sie die folgende Zeile in die primäre Konfigurationsdatei von NGINX (standardmäßig /etc/nginx/nginx.conf) am Ende des (und innerhalb des) http {}-Blocks einfügen:

# Siehe: https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy
# Dies MUSS NACH den Zeilen kommen, die .../sites-enabled/* einfügen, andernfalls kann die Unterstützung für SSLv3 versehentlich wieder aktiviert werden.
include perfect-forward-secrecy.conf;

Starten Sie NGINX neu, um die Änderungen wirksam zu machen:

service nginx restart

Wenn der Test unter https://www.ssllabs.com/ssltest/analyze.html “Session-Wiederaufnahme (Caching) Nein (IDs zugewiesen, aber nicht akzeptiert)” in Rot anzeigt und der Server SNI implementiert, fügen Sie Folgendes zum obersten http {}-Block hinzu (d.h. fügen Sie nginx.conf direkt unter dem hinzu, wo wir die vorherigen Ergänzungen gemacht haben):

# Siehe: http://forum.nginx.org/read.php?2,152294,152401#msg-152401
ssl_session_cache shared:SSL:10m;

Starten Sie erneut NGINX neu, um die Änderungen wirksam zu machen:

service nginx restart

Der obige Test sollte dieses Problem nicht mehr melden (auch wenn das Problem die Gesamtbewertung des Tests nicht verringert).

Weiterführende Maßnahmen: Implementierung von HTTP Strict Transport Security (HSTS) mit langer Dauer

Dies ist einfach und lohnt sich, vorausgesetzt:

1. Sie möchten SSL für alle Ressourcen für jeden Host, für den dieser Header gesetzt ist, erzwingen (d.h. jede Seite auf der betreffenden Website).
2. Sie können damit leben, dass Sie nicht in der Lage sind, SSL-Warnungen für Ressourcen, die von Hosts angefordert werden, für die dieser Header gesetzt ist, zu akzeptieren und zu ignorieren, wie z.B. “Domain Name Mismatch” usw. Die Natur von HSTS ist es, dass Warn- und Fehlerbedingungen in Bezug auf das SSL-Zertifikat nicht überschrieben werden können.

Ich habe das Internet nach Informationen durchsucht, ob das Setzen dieses Headers unbeabsichtigte Folgen in Browsern haben könnte, die den Header nicht unterstützen, und bin nicht fündig geworden. Aber ich konnte meine Bedenken zerstreuen, indem ich diese Implementierung beispielsweise in Internet Explorer 6 getestet habe, und Browser, in denen HSTS nicht implementiert ist, ignorieren einfach den Header. Perfekt!

Fügen Sie einfach die folgenden Zeilen am Ende von /etc/nginx/perfect-forward-secrecy.conf hinzu und speichern Sie die Änderungen:

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains";
# Dies wird bestimmte Clickjacking-Angriffe verhindern, aber andere Seiten daran hindern, Ihre Seite einzurahmen, also löschen oder ändern Sie es nach Bedarf!
add_header X-Frame-Options SAMEORIGIN;

Ein Reload (anstatt eines Neustarts) reicht aus, um NGINX zu zwingen, diese speziellen Änderungen zu übernehmen:

service nginx reload

Es ist möglich zu bestätigen, dass HSTS wie beabsichtigt funktioniert, indem Sie Ihre Implementierung unter https://www.ssllabs.com/ssltest/analyze.html testen. Wenn HSTS korrekt implementiert ist, sollten Sie ein grünes Feld direkt unter Ihrer Punktzahl sehen, das besagt: “Dieser Server unterstützt HTTP Strict Transport Security mit langer Dauer. Note auf A+ gesetzt.”

Herzlichen Glückwunsch!

Sie haben jetzt eine der sichersten SSL/TLS-Implementierungen im Internet.

Referenzen:

• https://community.qualys.com/blogs/securitylabs/2013/08/05/configuring-apache-nginx-and-openssl-for-forward-secrecy

Copyright © 2014 Ben Johnson