SSL mit dem Apachen – Renew
Seit meinem letzten Artikel ( der ist schon etwas älter 🙂 ) zur SSL Verschlüsselung von Webseiten mit dem Apache Webserver hat sich in diesem Bereich eine ganze Menge getan.
Neue Apache-Versionen, neue Ciphers und längere Schlüssel sind für mich nun Grund genug, ein Renew dieses Artikels zu verfassen. Viel Erfolg also dann bei Euren Anpassungen oder eben auch Neuinstallationen.
War ich in meinem letzten Artikel noch auf die Erstellung von Self-Signed Zertifikaten eingegangen, so möchte ich dies hier unterlassen. Mittlerweile gibt es verschiedene Trust-Center, welche kostengünstig oder teilweise sogar auch kostenlos signierte SSL Zertifikate für Domains ausstellen. Als Beispiel sei hier gerne startssl.com genannt, was derzeit mein persönlicher Favorit ist.
Nun also zu den Arbeiten auf der Seite Eures Webservers. Nach wie vor ist natürlich hier die Verfügbarkeit entsprechender SSL Module und Basiskonfigurationen Pflicht:
root@webserver:/# ls -al /etc/apache2/mods-enabled |grep ssl
lrwxrwxrwx 1 root root 26 Mär 8 2013 ssl.conf -> ../mods-available/ssl.conf
lrwxrwxrwx 1 root root 26 Mär 8 2013 ssl.load -> ../mods-available/ssl.load
Ebenso muss natürlich auch ein SSL Stack bereitstehen, welches im Fall von Ubuntu Linux ( wie hier in meinem Beispiel ) openssl wäre:
root@webserver:/# dpkg -l |grep openssl
ii openssl 1.0.1-4ubuntu5.21 Secure Socket Layer (SSL) binary and related cryptographic tools
Als nächsten Schritt muss ein sogenannter Code-Signing-Request ( CSR ) erstellt werden, was auf Commandline-Ebene mit folgendem Kommando geschieht:
root@webserver:/# openssl req -nodes -new -newkey rsa:4096 -sha256 -out csr.pem
Mit den entsprechenden Parametern dieses Aufrufs wird nun ein CSR und der dazugehörige private Schlüssel generiert. Wichtig ist hier vor allem die Angabe zur gewünschten Schlüssel-Länge ( hier: rsa:4096 ), welche auf keinen Fall mehr unter 2048-Bit liegen sollte und ebenso auch die Signaturmethode, welche nicht mehr bei SHA-1 sondern bei SHA-2 ( hier: sha256 ) liegen sollte.
Bei der Eingabe der nun geforderten Angaben ( Domainname, Mail-Adresse, Unternehmen, etc. ) ist darauf zu achten, dass KEIN PASSWORT für den Key eingegeben wird. Dies ist wichtig, da sonst bei jedem ( Neu- ) Start des Webservers eben dieses Passwort abgefragt werden würde, was zumindest im Regelfall sicher nicht wirklich optimal wäre.
Nun wird der Inhalt des CSR-Files ( csr.pem ) beim Trust-Center Eurer Wahl entsprechend eingetragen, woraufhin ein entsprechendes Zertifikat bereitgestellt werden wird.
Dieses Zertifikat und der dazugehörige, vorher generierte private Schlüssel werden nun dem entsprechenden Apache vHost zugeordnet und schon ist die Implementierung abgeschlossen. Zu guter Letzt sollten dann noch die, vom Apachen zu verwendenden Ciphers eingetragen werden. Meine Empfehlung ist hier die folgende Konfiguration ( in der ssl.conf ):
SSLProtocol all -SSLv2 -SSLv3
SSLCompression Off
SSLHonorCipherOrder on
SSLCipherSuite "EECDH+AESGCM EDH+AESGCM EECDH -RC4 EDH -CAMELLIA -SEED !aNULL !eNULL !LOW !3DES !MD5 !EXP !PSK !SRP !DSS !RC4"
Ein Hinweis noch meinerseits für eine gute Webseite, über welche Ihr Eure nun bestehende SSL gesicherte Webseite testen lassen könnt ist ssllabs.com – testet es aus, hier gibt es immer wieder neueste Tips und Tricks um die Verschlüsselung zu optimieren 🙂
J.C. Denton
Den ISP meiner Organisation habe ich schon mehrfach aufgefordert die Signaturen im Zertifikat von SH1 auf SHA256 zu ändern. Außerdem wird TLS 1.2, OCSP-Stapling und HSTS bei 1&1 nicht standardmäßig bereitgestellt. Das finde ich grundsätzlich problematisch.
Gott sei Dank ist ✛ΔO ziemlich statisch und keine »Web-2.0-mitmach-Site«, weshalb auch keine sensiblen Daten übertragen werden (Formulare, etc.).
Dennoch möchte ich gerne Downgrade-Angriffe verhindern und keine Zertifikat-Warnungen z.B. in Google Chrome bei unseren Besuchern. Zudem soll auch in X-Monaten/Jahren kein NSA-Analyst z.B. via MARINA und Co. nachvollziehen können wer wann welche Page unserer Site abgerufen hat.
In Zeiten von QUANTUM und FOXACID sind viele neue sog. »selectors« denkbar (siehe: https://tron-delta.org/content/news-articles/the-nsa-quantum-project-part-1-en.html). Ein wesentlicher Baustein ist, wie auch im o.g. Artikel beschrieben, Verschlüsselung.
Aus genanntem Grund begrüße ich Deinen Artikel »SSL mit dem Apachen – Renew« sehr!
Sven Neidahl
der gute herr denton lebt also noch im internet 🙂 … eventuell solltest du einen provider-wechsel in betracht ziehen, oder vielleicht sogar die migration auf ein eigenes „blech“ ( vms sind hier auch wieder problematisch ) ?!
Zarafa 7.2 Multi-Tenant mit Postfix, SpamAssassin und SASL » blog.neidahl.de
[…] ich nicht weiter ein, denn auch hier gibt das Internet diverse Anleitungen her, unter anderem auch auf meinem Blog zu […]
Sven Neidahl
Hier nun eine Ergänzung, da sich BEAST & Co. Immer wieder einmal im Internet melden. Die aktuelle empfohlene Cipher-Variante wäre dann diese hier:
SSLCipherSuite ECDHE-ECDSA-AES256-GCM-SHA384:ECDHE-RSA-AES256-GCM-SHA384:ECDHE-ECDSA-CHACHA20-POLY1305:ECDHE-RSA-CHACHA20-POLY1305:ECDHE-ECDSA-AES128-GCM-SHA256:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-ECDSA-AES256-SHA384:ECDHE-RSA-AES256-SHA384:ECDHE-ECDSA-AES128-SHA256:ECDHE-RSA-AES128-SHA256
Hierdurch sind dann auch TLS1.0 sowie TLS1.1 ausgeschlossen:
SSLProtocol all -SSLv3 -TLSv1 -TLSv1.1
Vor der Konfigurationsanpassung aber bitte die Browser und Programme der Besucher checken, denn die alten Versionen werden hier die Verbindung definitiv verweigern …
Sven Neidahl
Dieser Artikel ist nun überholt, die neue Version gibt es hier …
https://blog.neidahl.de/howto/ssl-macht-irre/
SSL macht irre » blog.neidahl.de
[…] Nächte damit zu verbringen, alles wieder gerade zu biegen. An dieser Stelle als Hinweis – mein bisheriger Artikel zu diesem Thema gilt ab sofort somit als überholt respektive veraltet […]