rne hat geschrieben:Es ist im Übrigen für die Sicherheit von HTTPS nicht unbedingt ausreichend, die Standardeinstellungen bezüglich HTTPS/TLS von Nginx zu nehmen.
Ich sehe das Massiv anders. Der debian-nginx mag eher konservativer mit der Adaption neuer sicherheits-Technologien sein, aber wirkliche wirkliche Sicherheitslücken hatte er nie.rne hat geschrieben:HTTPS macht die Seite per se noch nicht sicher. Deine aktuelle Konfiguration hat ein Rating von "B".
Da sollte nach Möglichkeit ein "A+" oder mindestens ein "A" stehen: https://www.ssllabs.com/ssltest/analyze ... <deine_url>
Und gerade die Empfehlungen von ssllabs finde ich eher befremdliche politische Agenda als Sicherheitsfeatures.
Hier mal ein paar Kritikpunkte:
- Als Herauskam, dass viele CBC Implementierungen gegen BEAST anfällig sind emfpahlen alle diese Seiten AES und 3DES vorsichtshalber ganz zu entfernen. Der Quasistandard wurde dann de einzige verbreitete Alternative und schon damals mehrfach (aber nicht im Kontext von SSL) gebrochene RC4. Als RC4 2013 dann endgültig auch für SSL und auch über große mengen von Daten gebrochen wurde blieben die Konfigurationen oft am Netz. Bis heute wird RC4 von vielen seltener genutzten Seiten als Einziger Cipher angeboten. Die Große Verbreitung ist der Grund warum der Firefox den bis heute per default akzeptiert.
Für Leute die nicht regelmäßig Security-Nachrichten lesen halte ich deswegen default Einstellungen (die der Maintainer bei neuen angriffen dann ändert) immer sinnvoller wie fest eincodierte Optionen. ssl_ciphers entspricht fast dem default von nginx. Nur so passt sich der bei geänderter Sicherheitslage nicht automatisch beim update an. - Ähnliches gilt für die fest eincodierten ssl_dhparams mit 2048Bit. Reagiert auf eine lange gestopfte Lücke, wo automatisch generierte Fehler hatten. Selbstgenerierte fände ich sinnvoller. Insbesondere weil die 2048 IMHO etwas wenig Sicherheitsmarge haben. Würde 4096 nehmen oder, wenn man einen eingeschränkten Nutzerkreis hat, von dem man weiß, dass die Browser es unterstützen 6000.
- ssl_prefer_server_ciphers on: Wenn mir der Client über eine sicher (RSA) signierte Leitung sagt, dass er lieber einen bestimmten (möglciherweise unsichereren) Cipher haben will, verstehe ich absolut nicht, warum der Server sich darüber hinweg setzen sollte. Diese Bevormundung als Sicherheitsfeature zu verkaufen halte ich für quatsch.
- ssl_protocols TLSv1 TLSv1.1 TLSv1.2: Die Zeile macht im Moment exakt das was default ist beim nginx. TLSv1 ist aber seit Jahren gebrochen. Nur wenn man darüber HTTP mit Webseiten spricht hat das noch keiner effektiv vorgeführt. Es gibt durchaus Gründe das aus Kompatibilitätsgründen da drin zu lassen. Wer besonderen Wert aus Sicherheit legt, sollte sie aber rauswerfen. So wie das in einigen Versionen auch der nginx machen wird. Bei der konfiguration wird der dann aktiviert bleiben. Dagegen ist TLS1.3 jetzt gerade im Anmarsch. Sobald nginx das per default unterstützt wird das von dir verboten. Sinnvollr wäre eher ein !TLS1 !SSLv3. Und für einen frisch kompilierten TLS1.3 !TLS1 !SSLv3
- Das bevorzugen der NSA-Generierten Elliptischen Kurven würde ich nicht empfehlen. Finde ich nicht sehr vertrauenserweckend.
- Im allgemeinen finde ich die Reihenfolge ECDH>EDH>RSA für den Schlüsselaustausch sehr befremdlich. Man kann zur Sicherheit Primfaktoren vs. Elliptische Kurven unterschiedlich stehen, Da RSA zum signieren sowieso benutzt wird, ist TLS im Fall eine gebrochenen RSA eh kaputt. Da jeder der EDH im allgemeinen knacken kann, auch RSA knacken kann, gilt da ähnliches. Es bleiben natürlich Gefahren in der konkreten Implementierung.
Für EECDH spricht deswegen IMHO nur die bessere Performance bei vielen Verbindungen. dagegen aber die größere Anfälligkeit gegen Quantencomputer.
Bleit der Vorteil von PFS. Der beiden ersten Algorithmen gegenüber RSA. Den macht man sich aber kaputt, solange der FF und Server die Keys über Jahre auf die Platte dumped.
Zumindest mit der Option ssl_session_cache würde ich das akzeptieren Trotzdem eher EDH>ECDH>RSA machen. - spdy wird gerade durch http/2 abgelößt. Die ersten Browser deaktiveren es wider. Würde nicht auf ein totes Pferd setzen.