wanne hat geschrieben:
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.
Sicher?
wanne hat geschrieben:
Und gerade die Empfehlungen von ssllabs finde ich eher befremdliche politische Agenda als Sicherheitsfeatures.
Warum? Der online HTTPS Server Checker ist eines von vielen möglichen Tools um einen schnellen Überblick über Sicherheit und Kompatibilität seines HTTPS Servers zu bekommen.
wanne hat geschrieben:
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.
Du empfiehlst also, von der Deaktivierung von RC4 aus Kompatibilitätsgründen zu Kosten der Sicherheit abzusehen. Das ist in meinen Augen eine
sehr fragwürdige diskutable Einstellung.
wanne hat geschrieben:
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.
Das Lesen von CVEs ist für jeden Serveradministrator Pflicht. Wer dies nicht tut, sollte keinen Webserver betreiben.
wanne hat geschrieben:
Ä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.
Die von mir vorgeschlagenen Diffie-Hellman Parameter
sind selbst generiert, wie bereits aufgezeigt.
Des weiteren gelten 2048 Bit Schlüssel immer noch als ausreichend sicher.
Und wenn man wie oben von dir ausgeführt auch RC4 anwendet um Abwärtskompatibilität zu wahren, braucht man beim initialen Schlüsseltausch auch nicht einen Overkill von 4-6k Schlüsseln.
Damit löst man nämlich weder das Problem der schwachen RC4 Chiffre, noch löst man, wie von dir oben als Argument angeführt, das Problem der Abwärtskompatibilität.
wanne hat geschrieben:
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.
Bevormundung? Starkes Wort. Ich will hier keine emotionale, sondern sachliche Debatte.
Dies dient einzig und alleine der Performancesteigerung, genau wie auch die Bevorzugung von EECDH.
Wenn ein Benutzer sich durch diesen Umstand bevormundet fühlt, kann er gerne bei uns anrufen.
wanne hat geschrieben:
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
Ich bevorzuge es, selbst Verantwortung für meine Systeme zu übernehmen und nicht immer und überall auf die Maintainer der Pakete zu vertrauen.
Sobald TLS 1.3 von Nginx tried-and-tested angeboten wird, werde ich es in der Konfiguration hinzufügen.
wanne hat geschrieben:
Das bevorzugen der NSA-Generierten Elliptischen Kurven würde ich nicht empfehlen. Finde ich nicht sehr vertrauenserweckend.
Ah ja, die bösen NIST Kurven. Sicher, einige Wissenschaftler wie u.a. DJB halten diese für "auffällig". Sicherheitsmängel wurden jedoch nie nachgewiesen.
Sobald Nginx Curve25519 anbietet werde ich jedeoch auch hier umstellen. (Bei SSH nutze ich bereits ed25519, da auch ich einen kleinen Aluhut trage.)
Edit: Ansonsten kann der geneigte Betreiber auch eine andere Kurve verwenden. Ich schmeiße mal
brainpoolP384r1 in den Raum.
wanne hat geschrieben:
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.
Wie oben bereits erwähnt, dient diese Reihenfolge auch ausschließlich der Performance. Sobald Quantencomputer zu einer realen Bedrohung werden, werde ich auch hier umstellen.
wanne hat geschrieben:
spdy wird gerade durch http/2 abgelößt. Die ersten Browser deaktiveren es wider. Würde nicht auf ein totes Pferd setzen.
Kurz viele der Optionen finde ich eher umstritten. Für Profis vielleicht ganz nett, aber für einen der sich nicht so auskennt, würde ich empfehlen die defaults vom nginx zu lassen. Dumm sind die Entwickler von dem nämlich auch nicht.
Woher nimmst du die Information, dass Browser SPDY abschaffen? AFAIK ist HTTP/2 eine Erweiterung von SPDY und größtenteils abwärtskompatibel dazu.
Eine Quelle wäre interessant und könnte mich umstimmen.
PS: Die von Debian 8.8 mitgeschiffte Version von Nginx kann nur SPDY und noch kein HTTP/2. Auf meinem Homeserver (RasPi2) habe ich ArchLinux ARM laufen. Dort verwendet der Nginx auch http2.
PPS: @Leatrixa: Ich empfehle dir, dich weiter mit der Thematik SSL zu beschäftigen. Wenn du unsicher bist, frag in Foren wie diesem oder auf serverfault.com. Ich selbst bin Systemadministrator mit mehrjähriger Berufserfahrung, die unter anderem gelehrt hat, dass man immer wieder dazu lernt.
Zudem Fällt mir gerade auf, dass in deiner Konfig der Eintrag
Code: Alles auswählen
ssl_trusted_certificate /etc/letsencrypt/live/<domain>/chain.pem;
fehlt. Eventuell möchtest du diesen noch nachtragen.
Viele Grüße
rne