PATCHtober

Heute möchte ich euch zeigen wie ihr unter Plesk 12 CHACHA20-POLY1305 mit NGINX zum laufen bringt. Ich weiß dass das nichts besonderes ist. Nur habe ich keine richtige Anleitung für Plesk Nutzer gefunden und deshalb mach ich selber eine.

Bevor ich zur Konfiguration komme gibt es noch einiges zu beachten, vielleicht hat der eine oder andere im Web die eine oder andere Anleitung gefunden. Leider ploppt bei Plesk eine Fehlermeldung auf ,dass er die ssl_ciphers nicht kennt und Fehlermeldungen generiert.

Die richtige Einstellung welche auch ich verwende lautet:

ssl_ciphers RSA-PSK-AES256-CBC-SHA:RSA-PSK-CHACHA20-POLY1305:DHE-PSK-CHACHA20-POLY1305:ECDHE-PSK-CHACHA20-POLY1305:PSK-CHACHA20-POLY1305:EECDH+CHACHA20:EECDH+CHACHA20-draft:EECDH+AES128:RSA+AES128:EECDH+AES256:RSA+AES256:EECDH+3DES:RSA+3DES:!PSK:!MD5;

Ich empfehle euch gleich diese Parameter auf eure Domains umzusetzen oder im Plesk Template festzulegen (Anleitung dazu findet ihr unten).

Aber bevor ich Mails bekommen mit „So ein mist! Bei mir geht das gar nicht“ etc. stellt sicher das ihr genau die gleichen Angaben habt wie ich. Ich beginne mit einer Schritt für Schritt Anleitung.

Zuerst ein Verzeichnis für die ganzen Packages finden ich mache alles was ich nachträglich installiere ins „/root/“ Verzeichnis. Wahrscheinlich aus Gewohnheit 😀 .

cd /root
wget http://nginx.org/download/nginx-1.9.9.tar.gz
tar -xvpzf nginx-1.9.9.tar.gz

Bevor ihr das Verzeichnis betretet könnt ihr gleich openssl-chacha20 runterladen.
https://github.com/PeterMosmans/openssl/archive/1.0.2-chacha.zip
unzip openssl-1.0.2-chacha.zip

So nun könnt ihr das Verzeichnis betreten

cd nginx-1.9.9

Aber wenn wir schon dabei sind können wir ja auch http2 aktivieren. Wichtig dazu ist das falls ihr SPDY verwendet ihr die Einstellungen dazu noch zurücksetzen müsst bzw. im Custom Template die Änderungen vornehmen.

mkdir -p /usr/local/psa/admin/conf/templates/custom/domain/
cp /usr/local/psa/admin/conf/templates/default/domain/nginxDomainVirtualHost.php /usr/local/psa/admin/conf/templates/custom/domain

Und dann nur noch ausführen:

/usr/local/psa/admin/bin/httpdmng --reconfigure-all

Aber zurück zu NGINX und CHACHA20

Jetzt müsst ihr die .configure konfigurieren 😀
./configure --prefix=/usr/share --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --user=nginx --group=nginx --with-ipv6 --with-file-aio --with-http_ssl_module --with-http_realip_module --with-http_sub_module --with-http_dav_module --with-http_gzip_static_module --with-http_stub_status_module --with-http_v2_module --with-openssl=/root/openssl-1.0.2-chacha

Das ganze dauert ca 5 minuten
sudo make
weitermachen und als Abschluss
sudo make install

So müsste eure Template ungefähr aussehen

server {
listen ($OPT['default'] ? ' default_server' : '') . ($OPT['ssl'] ? ' ssl http2' : '') ?>;
.
.
.
ssl_ciphers ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:HIGH:MEDIUM:!MD5:!aNULL:!EDH:!RC4:!DSS;

und dann einfach /usr/local/psa/admin/bin/httpdmng --reconfigure-all

Alternativ könnte man jede einzelne nginx.conf ändern, doch das wäre mir zuviel Arbeit. Ich mache es mir da etwas leichter.

Wenn ihr das alles so erledigt habt sollte – wenn Ihr den Browser oder einen neuen Tab aufmacht und eure Domain aufruft- das Ergebnis so aussehen. Wer aber noch zweifelt ob er gerade richtig sieht auch nach einem Test bei Qualys zeigt sich unser Blog hat CHACHA20.

Was nun dem einem oder anderem aufgefallen ist, bei uns steht „Gültige Informationen zur Zertifikatstransparenz wurden vom Server bereitgestellt.“

Wieder etwas zum Thema SSL – Sicherheit was aber nur bei Chrome und Opera Benutzern angezeigt wird.

Hier habe ich eine Gute Zusammenfassung gefunden was kurz erklärt was das genau ist und wie das Ganze ungefähr funktioniert:

Seit Anfang 2015 unterstützen EV SSL Zertifikate Zertifikatstransparenz (Certificate Transparency – CT). In einem für jeden einsehbaren Log-System werden alle Zertifikate registriert. Diese werden von Log-Servern verwaltet. Nur öffentlich registrierte Zertifikate sind auch gültig. Es soll dabei insbesondere unmöglich sein, Zertifikate nachträglich aus dem Log zu entfernen oder welche einzufügen. Wenn eine Zertifizierungsstelle nun böswillig ein Zertifikat ausstellt, welches etwa zur Überwachung von Nutzern eingesetzt wird, lässt sich dies zwar nicht direkt verhindern, es lässt sich jedoch auch nicht geheim halten. (Hier ein Beispiel)

Das CT-Projekt macht die Zertifikatsausstellung einer CA für Überprüfung und Überwachung offen, was dazu verwendet werden kann, falsche Ausstellungen zu erkennen. Transparenz wird dadurch erreicht, dass CAs Zertifikate auf öffentlich zugänglichen qualifizierten CT-Logs registrieren. Kunden können Log-Monitore erstellen, die auf Zertifikate achten, die für ihre Domains ausgestellt werden und die falsche Ausstellungen innerhalb von Minuten erkennen.

CT-Logs sind ‚append only‘ Logs. Obwohl jedermann Zertifikate auf den Logs registrieren kann, werden sie in erster Linie von Zertifizierungsstellen verwendet, um „Vor-Zertifikate“ zu registrieren. Wenn Vor-Zertifikate auf den Logs registriert werden, gibt der Log-Betreiber einen Signed Certificate Timestamp (SCT) zurück, der nachweist, dass das Zertifikat protokolliert wurde. Dieser SCT kann von Browsern verwendet werden, um zu validieren, dass das Zertifikat protokolliert war. SCTs können über eine Vielzahl von Mechanismen an den Browser verteilt werden ( gesehen bei ATVIRTUAL)

Geregelt wird das verfahren unter der Bezeichnung RFC 6962 weitere Informationen findet man auch unter certificate-transparency.org

Bislang habe ich keine funktionierende Anleitung für Plesk Nutzer gefunden und die von certificate-transparency.org würde ich auch nicht empfehlen da diese noch einige Fehler aufweist. Hier wäre meine und diese funktioniert auch unter Plesk:

sudo apt-get install unzip gcc libpcre3-dev zlib1g-dev make golang-go
wget -O nginx-ct.zip https://github.com/grahamedgecombe/nginx-ct/archive/master.zip
unzip nginx-ct.zip

Wenn Ihr das habt. Müsst ihr leider die komplette Konfiguration von oben mitmachen sonst meldet NGINX das er ssl_sct nicht kennt und die Arbeit war umsonst.
So sieht dann die Konfiguration aus:

./configure --prefix=/usr/share --sbin-path=/usr/sbin/nginx --conf-path=/etc/nginx/nginx.conf --error-log-path=/var/log/nginx/error.log --http-log-path=/var/log/nginx/access.log --lock-path=/var/lock/nginx.lock --pid-path=/var/run/nginx.pid --http-client-body-temp-path=/var/lib/nginx/body --http-fastcgi-temp-path=/var/lib/nginx/fastcgi --http-proxy-temp-path=/var/lib/nginx/proxy --http-scgi-temp-path=/var/lib/nginx/scgi --http-uwsgi-temp-path=/var/lib/nginx/uwsgi --user=nginx --group=nginx --with-ipv6 --with-file-aio --with-http_ssl_module --with-http_realip_module --with-http_sub_module --with-http_dav_module --with-http_gzip_static_module --with-http_stub_status_module --with-http_v2_module  --with-openssl=../openssl-1.0.2-chacha --add-module=../nginx-ct-master

Wenn jetzt jemand von euch die Website von Certificate Transparency besucht hat wird er verwirrt sein weil ich an den Parametern einige Änderungen gemacht habe und nicht wie die nur das Modul und SSL auffrische, sondern gleich alles anpasse weil wir Plesk verwenden und das nun eben etwas anderes ist und manchmal Probleme bereiten kann.

So ihr habt das Konfigurieren abgeschlossen, nun müsst Ihr eure Zertifikate aufbereiten und das geht so:
sudo mkdir /usr/local/nginx/conf/ssl
sudo sh -c """echo '''-----BEGIN PRIVATE KEY-----
... your private key ...
-----END PRIVATE KEY-----''' >/usr/local/nginx/conf/ssl/server.key"""

sudo sh -c """echo '''-----BEGIN CERTIFICATE-----
… your certificate ...
-----END CERTIFICATE-----
-----BEGIN CERTIFICATE-----
… append zero or more intermediate certs in order ...
-----END CERTIFICATE-----''' >/usr/local/nginx/conf/ssl/server.crt-bundle"""

sudo mkdir /usr/local/nginx/conf/ssl/scts

wget -O ct-submit.zip https://github.com/grahamedgecombe/ct-submit/archive/master.zip
unzip ct-submit.zip
cd ct-submit-master/
go build

Was nun fehlt ist die Verifizierung durch diese CT-Logs und das geht so
sudo sh -c "./ct-submit-master ct.googleapis.com/aviator \
</usr/local/nginx/conf/ssl/server.crt-bundle \
>/usr/local/nginx/conf/ssl/scts/aviator.sct"
sudo sh -c "./ct-submit-master ct.googleapis.com/pilot \
</usr/local/nginx/conf/ssl/server.crt-bundle \
>/usr/local/nginx/conf/ssl/scts/pilot.sct"
sudo sh -c "./ct-submit-master ct.googleapis.com/rocketeer \
</usr/local/nginx/conf/ssl/server.crt-bundle \
>/usr/local/nginx/conf/ssl/scts/rocketeer.sct"
sudo sh -c "./ct-submit-master ct1.digicert-ct.com/log \
</usr/local/nginx/conf/ssl/server.crt-bundle \
>/usr/local/nginx/conf/ssl/scts/digicert.sct"
sudo sh -c "./ct-submit-master ct.izenpe.com \
</usr/local/nginx/conf/ssl/server.crt-bundle \
>/usr/local/nginx/conf/ssl/scts/izenpe.sct"
sudo sh -c "./ct-submit-master log.certly.io \
</usr/local/nginx/conf/ssl/server.crt-bundle \
>/usr/local/nginx/conf/ssl/scts/certly.sct"