Aplus-SSL-certificate german
Contents
1 Einleitung
Seit Let's Encrypt sind SSL Wildcard Zertifikate für jedermann Kostenlos zugänglich geworden. Diese müssen zwar alle drei Monate erneuert werden, das lässt sich aber auf Grund der hervorragenden Integration Um-Systeme hervorragend automatisieren. z.B. mit Ansible. Ein SSL-Zertifikat selbst ist aber kein Garant für eine sichere Daten Übertragung, es gehört schon noch ein wenig mehr dazu. In diesem Beitrag zeigen wir ein Beispiel für die Absicherung eines Nginx Webservers und erläutern die einzelnen Schritte. Als Masstab für unsere Konfiguration gilt die Bewertung des unten genannten SSL Labs Cert checker von Qualys.
2 Links
- SSL Webserver Config Generatur
- SSL Labs Cert Check Seite
- HSTS Preload Liste
- DNS CAA Test Site
- Gut dokumentierte nginx SSL Config
3 SSL Zertifikat
Dieser Schritt ist ziemlich einfach, es ist leicht einen Score von 100 zu erreichen. Verwende eine bekannte oder vertrauenswürdige Zertifizierungsstelle (Certificate Authority) und vergewissere Dich, dass Zertifikat und Chain in der richtigen Reihenfolge vorliegen. Die wichtigste Zertifikatskonfigurationseinstellung ist der Fingerprint-Hashing-Algorithmus. Stelle sicher, dass Du ein SHA256-signiertes Zertifikat und nicht SHA1 erstellt hast. Bis vor kurzem wurden die meisten Zertifikate mit SHA1 signiert. Mit zunehmender Rechenleistung wird es jedoch gefährlich unsicher. Neue Zertifikate sollen mit SHA256 signiert werden.
4 SSL Einstellungen
4.1 Protokoll Unterstützung
- SSLv3 Deaktivieren
- Gilt seit 2014 als verwundbar und soll unbedingt verweigert werden.
- TLSv1.2
- Dies bringt eine Wertung von 100%, kann aber mit älteren Clients Probleme verursachen
- TLSv1.1&v1.2
- Bringt eine Wertung von 95%, kann aber dennoch Probleme mit älteren Clients verursachen.
- TLS1.0~1.2
- Bringt eine Wertung von 90% und gute Kompatibilität mit Clients, eine Gesammt Wertung von A+ ist dennoch möglich.
- Nginx Beispiel:
# SSLv3 is broken by POODLE as of October 2014 # ssl_protocols TLSv1.2; # Score=100 # ssl_protocols TLSv1.2 TLSv1.1; # Score=90 ssl_protocols TLSv1.2 TLSv1.1 TLSv1; # Score=95 (recommended)
4.2 Perfect Forward Secrecy
Um den Score für den Schlüsselaustausch zu erhöhen, müssen wir die Grösse des Schlüssels erhöhen, der für den DH-Austausch verwendet wird. Nginx verwendet Standardmässig 1024 Bit Schlüssel von OpenSSL als Eingabe für den DH-Schlüsselaustausch, was zu einem 1024-Bit-Schlüssel führt. Im Idealfall sollten wir eine Schlüssellänge verwenden, die kleiner als unser SSL-Zertifikat ist und normalerweise 2048 oder sogar 4096 Bit beträgt. Bei vielen Webserver-Installationen werden die Standard-DH-Schlüssel wiederverwendet. Die Verwendung der gleichen Schlüssel erleichtert das Abhören der Kommunikation. Wer dies liest sende mir eine email, nicht verraten, ich werde das sammeln. Daher muss ein neuer Schlüssel mit benutzerdefinierten DH-Parametern generiert werden. Also werden wir einen neuen Satz von DH-Parametern generieren und diese in einer Datei speichern.
- Dies kann mit OpenSSL gemacht werden:
openssl dhparam -out /etc/nginx/dhparam.pem 4096
- Nginx Beispiel Config:
ssl_dhparam /etc/nginx/dhparam.pem;
4.3 Starke Algorithmen (Cipher Suite)
Die schwierigste Konfigurationsentscheidung auf dem Server ist die Wahl der unterstützten Cipher Suites. Mit einer nahezu unendlichen Anzahl möglicher Kombinationen gibt es viele dieser Algorithmen, die alle unterschiedliche Funktionen, Leistung, Verschlüsselungsstärke und Browserunterstützung aufweisen. Viele von ihnen haben bekannte Schwächen, die sie für den heutigen Gebrauch ungeeignet machen. Die Verwendung der neuesten Version eines Browsers reicht normalerweise aus, um einen einzelnen Benutzer zu schützen, aber leider haben viele ältere Browser unsichere Standardeinstellungen. Daher müssen wir bei der Konfiguration der Cipher Suite viele Optionen berücksichtigen, um die Kompatibilität mit möglichst vielen Browsern sicherzustellen, ohne die Sicherheit und Leistung zu beeinträchtigen.
Einige Algorithmen haben bekannte oder vermutete Schwachstellen, und wir können deren Verwendung gegebenenfalls deaktivieren oder einschränken.
Insbesondere die folgenden Algorithmen sollten deaktiviert werden:
- MD5
Der MD5- Hashing-Algorithmus wird häufig verwendet, weist jedoch bekannte Schwachstellen auf. Heute ist MD5 bekanntermassen anfällig für Kollisionen, insbesondere mit GPUs. Er ist nicht mehr sicher zu verwenden.
- RC4
Die RC4- Verschlüsselung wird ebenfalls häufig verwendet und wurde sogar allgemein empfohlen. Untersuchungen, die theoretische Schwachstellen in RC4 aufzeigen, die Möglichkeit, dass RC4 in der Natur angegriffen wird, sind jedoch zu plausibel, um sie zu ignorieren.
- SHA1
Aus den gleichen Gründen, aus denen wir eine Zertifikatsanforderung mit SHA256 anstelle von SHA1 generiert haben, müssen wir auch Cipher Suites deaktivieren, die SHA1 als Hashing-Algorithmus verwenden.
- Wenig verwendete Chiffren
Einige Chiffren wie Camellia , Seed usw. sind nicht üblich, und ihre Deaktivierung vereinfacht die Konfiguration und verringert die Verwundbarkeit.
- Server zur Wahl der Chiffresuite zwingen
Viele Browser, insbesondere ältere, treffen selbst schlechte Entscheidungen in Bezug auf die Chiffresuite. Durch Aktivieren der Verschlüsselungsreihenfolge wählt der Server die bestmögliche aus, wenn ein Browser eine Liste der unterstützten Verschlüsselungen bereitstellt. Auf diese Weise kann sichergestellt werden, dass immer die bestmögliche Chiffre über die schwächeren steht.
- Score von 100%
Für einen Score von 100% in Cipher Strength müssen wir nicht nur alle alten Protokolle, sondern auch alle 128- Bit- Chiffren deaktivieren. Dies ist fuer eine Weltweit zugängliche Webseite (noch) nicht ratsam, da dafür relativ moderne Browser erforderlich sind und wir in der Regel nicht steuern können, was die Clients verwenden. Auf von uns überwachten Seiten wie Webmail oder Firmen Applikationen ist es jedoch ratsam die maximale Sicherheit zu implementieren.
5 Aktivieren von HSTS
Leider zeigt SSL Labs nicht klar, was noch getan werden muss, um die Bewertung A + zu erhalten.
- Wir müssen den HTTP Strict Transport Security (HSTS) -Header hinzufügen.
Beachte, dass HSTS Deine Seite HTTPS-fähig macht. Du kannst sie nicht mehr mit HTTP verwenden. Falls HTTP trotzdem verfügbar sein soll ist eine Bewertung von A zu erreichende Maximum.
Durch die Aktivierung von HSTS können Benutzer keine Verbindung über HTTP herstellen und die Verwendung von HTTPS wird immer erzwungen. Dies bedeutet, dass nach einem ersten Besuch eines Clients auf dem Server nachfolgende Besuche von HTTP-Seiten vom Browser in HTTPS konvertiert werden, und zwar bevor ein Request erfolgt. Dies spart uns einige Ladezyklen und erhöht die Sicherheit, insbesondere gegen SSL-Stripping-Angriffe. HSTS verhindert auch, redirecten zwischen HTTP und HTTPS und zurück, sowie viele andere Konfigurationsfehler, die leicht zu machen sind.
Hier eine nginx Beispiel Konfiguration:
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload" always;
- 31536000 Sekunden
Der Browser wird sich also ein Jahr lang daran erinnern, dass er die Website immer über HTTPS besuchen muss. Wenn Du aus irgendeinem Grund die Unterstützung von HTTPS für die Website deaktivieren möchtest, hast Du ein Problem mit den Browsern die den Header bereits erhalten haben. Würdest Du HTTPS-Datenverkehr zurück zu HTTP umleiten, würden diese Browser erneut zu HTTPS umleiten, was zu einer Endlosschleife führen würde. Wenn Du also nur mit SSL herumspielen und nicht sicher bist, ob Du es für die Website permanent aktiveren wisst ist HSTS nicht die richtige Wahl.
- includeSubDomains
Die includeSubDomains-Einstellung weist den Browser an, HSTS auch für Unterdomänen zu aktivieren. Entferne Sie diese Option, wenn nicht alle Subdomains für HTTPS konfiguriert wurden.
- preload
Bei der ersten HTTP-Anforderung ist ein Browser immer noch potenziell gefährdet. Mit der "preload"-Einstellung weisen wir den Browser an keine HTTP-Anfrage an den Server zu senden. Dazu senden wir die Website an die HSTS Preload Liste. Indem die Website an die HSTS Preload Liste gesendet wird, weisen wir den Browser an, die Website niemals über HTTP zu besuchen. Das Hinzufügen zur Preload-Liste hat eine semi-permanente Konsequenz und ist irreversibel. Verwenden Sie diese Option daher nur, wenn HTTPS durchgängig für die gesammte Domain konfiguriert wurde.
- always
Das "always" im Header weist Nginx an, diesen Header mit jedem möglichen Antwortcode zu versehen, anstatt nur für die Statuscodes "200, 201, 204, 206, 301, 302, 303, 304 oder 307". Beachten, dass ein HSTS-Einstellung: add_header Strict-Transport-Security "max-age=63072000;";mit einer Dauer von ≥ 1 Woche ausreicht, um ein 'A +' zu erhalten.
6 Weitere Optionen
6.1 OCSP-Stapeling
Mit jedem Zertifikat, das ein Browser empfängt, fordert er eine Zertifizierungsstelle auf, zu prüfen, ob das Zertifikat abgelaufen ist. Dies verursacht zusätzliche Wartezeiten und verringert die Sicherheit. Anstatt dass der Browser den Status des bereitgestellten Zertifikats überprüft, kann der Server mit Hilfe des Online Certificate Status Protocol (OCSP) zu überprüfen. Die OCSP-Antworten werden von der Zertifizierungsstelle signiert, sodass Browser ihnen vertrauen können, auch wenn sie direkt von deinem Server stammen.
- NginX-Beispiel:
# OCSP stapling ssl_stapling on; ssl_stapling_verify on; # the CA & Intermediate CA file for your cert ssl_trusted_certificate /path/to/certificate/ssl.crt; resolver 8.8.8.8 8.8.4.4 valid=300s; #Google DNS resolver_timeout 10s;
Das ssl_trusted_certificate ist ein Verweis auf die Datei, die alle vertrauenswürdigen Zertifikate enthält (daher auch das Stammzertifikat ). Diese Liste wird niemals an Clients gesendet, sondern für OCSP verwendet. Die Konfigurationseinstellung resolver wird benötigt, damit Nginx DNS-Abfragen auflösen kann.
6.2 SSL-Session-Caching
Um die Auswirkungen des SSL-Overheads auf den Server zu minimieren, können Sie die Anzahl der Handshakes der Clients reduziert werden. Der Handshake ist der teuerste Teil der Bereitstellung von Inhalten über SSL. Bei der Wiederaufnahme der Sitzung gibt der Server dem Client während des ersten TLS-Handshakes einige Informationen an. In einer zweiten Verbindung kann der Client diese Informationen verwenden, um den gesamten TLS-Handshake zu überspringen und sofort eine sichere Verbindung herzustellen. Wir können den SSL-Cache aktivieren, um die Notwendigkeit eines Handshakes bei nachfolgenden oder parallelen Verbindungen zu beseitigen.
- Nginx Beispiel
ssl_session_cache shared:SSL:10m; ssl_session_timeout 10m;
6.3 DNS CAA
Ist ein speziell geformter DNS record der die Zertifizierungs Stelle einer Domain ausweist. Somit kann eine kompromitierte Zertifizierungsstelle keine Schadhaften Zugriffe auf Ihre Seite erzeugen.
- Hier eine DNS Beispiel Konfiguration:
bitbull.ch. 3600 IN CAA 128 issue "letsencrypt.org"
7 Beispiel Nginx Konfiguration
Wurde zu Beginn des Artikels als Link aufgeführt.
