SSL auf Default Host von NGINX
Re: SSL auf Default Host von NGINX
Ich sage es Mal so, ich habe den Beitrag auf der ersten Seite nochmal gelesen, aber da verstehe ich leider nur Bahnhof, da müsstest du mir wieder bitte unter die Arme greifen.
Am besten hier, damit andere auch etwas davon haben oder zur Unterstützung dazu die Variante die ich dir PN zukommen lies. Denn "B" reicht mir nicht, hab mir noch gedacht die Grüne Adresszeile ist nicht gleich 100% richtig ^.^
Lg Lea
Am besten hier, damit andere auch etwas davon haben oder zur Unterstützung dazu die Variante die ich dir PN zukommen lies. Denn "B" reicht mir nicht, hab mir noch gedacht die Grüne Adresszeile ist nicht gleich 100% richtig ^.^
Lg Lea
-
- Beiträge: 30
- Registriert: 29.05.2017 14:15:13
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: SSL auf Default Host von NGINX
Meine Rede war von diesen TLS Optionen:
rne hat geschrieben: SSL und SPDY aktivierenGenerische Diffie-Hellman Parameter für die HTTPS vServerCode: Alles auswählen
listen 443 ssl spdy
SSL Session Cache auf 10 Minuten begrenzenCode: Alles auswählen
ssl_dhparam /etc/nginx/conf.d/https-generic-2048.dh;
Nur TLS ab Version 1.0 erlauben (Nachfolger von SSL)Code: Alles auswählen
ssl_session_cache shared:SSL:10m;
Vom Server angebotene Chiffren bei der Aushandlung bevorzugenCode: Alles auswählen
ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
Die von Server bevorzugten ChiffrenCode: Alles auswählen
ssl_prefer_server_ciphers on;
Für Eliptic Curve Schlüsseltausch zu verwendende KurveCode: Alles auswählen
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH EDH+aRSA !aNULL !eNULL !LOW !3DES !RC4 !MD5 !EXP !PSK !SRP !DSS";
HSTS aktivieren.Code: Alles auswählen
ssl_ecdh_curve secp384r1;
OCSP Stapling aktivierenCode: Alles auswählen
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
Code: Alles auswählen
ssl_stapling on; ssl_stapling_verify on;
Der Nachteil der Intelligenz besteht darin, daß man ununterbrochen gezwungen ist, dazuzulernen. -- George Bernard Shaw
Re: SSL auf Default Host von NGINX
Aaaaah optionen okey und die kann ich in die Default Config packen?
Wenn ja, wo muss ich die einfügen?
Wenn ja, wo muss ich die einfügen?
-
- Beiträge: 30
- Registriert: 29.05.2017 14:15:13
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: SSL auf Default Host von NGINX
Ja, genau. Die gehören in den Server Block des HTTPS Servers, also der zweite Serverblock in deiner o.g. Konfiguration.
Du kannst die Optionen unter den Statements listen 443 ssl [...] einfügen.
Das erste von mir vorgeschlagenen Statement mit SPDY brauchst du allerdings nicht einzufügen. Es reicht spdy zwischen ssl und default_server zu setzen.
Und die Diffie-Hellman Parameter in /etc/nginx/conf.d/https-generic-2048.dh müsstest du auch noch generieren:
Alternativ kannst du auch, zur besseren Wiederverwendbarkeit alle o.g. Optionen, bis auf die erste in eine die Datei /etc/nginc/conf.d/tls packen und in deinem HTTPS Server Block stattdessen
am Anfang einfügen.
Du kannst die Optionen unter den Statements listen 443 ssl [...] einfügen.
Das erste von mir vorgeschlagenen Statement mit SPDY brauchst du allerdings nicht einzufügen. Es reicht spdy zwischen ssl und default_server zu setzen.
Und die Diffie-Hellman Parameter in /etc/nginx/conf.d/https-generic-2048.dh müsstest du auch noch generieren:
Code: Alles auswählen
openssl dhparam -out /etc/nginx/conf.d/https-generic-2048.dh 2048
Code: Alles auswählen
include conf.d/tls
Der Nachteil der Intelligenz besteht darin, daß man ununterbrochen gezwungen ist, dazuzulernen. -- George Bernard Shaw
Re: SSL auf Default Host von NGINX
Also ich nehme die Befehle so wie Sie geschrieben sind und packe sie in eine tls datei um sie dann per include einzubinden? Habe ich das so richtig verstanden?
server {
ssl_dhparam /etc/nginx/conf.d/https-generic-2048.dh;
weitere optionen..
}
um dann über #SSL Configuration im zweiten Serverblock dies mit "include conf.d/tls" einzubinden dass so korrekt?
Edit: Wohl ohne, da der Serverblock ja schon vorgegeben ist, ich versuch einfach mal mein Glück
server {
ssl_dhparam /etc/nginx/conf.d/https-generic-2048.dh;
weitere optionen..
}
um dann über #SSL Configuration im zweiten Serverblock dies mit "include conf.d/tls" einzubinden dass so korrekt?
Edit: Wohl ohne, da der Serverblock ja schon vorgegeben ist, ich versuch einfach mal mein Glück

Re: SSL auf Default Host von NGINX
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.
rot: Moderator wanne spricht, default: User wanne spricht.
Re: SSL auf Default Host von NGINX
Also wenn ich folgene Optionen einfüge, kommt nen Fehler von Nginx also startet nicht das wären folgende:
Wenn ich session auf 5 runterschraube geht und die Transport auf 15768000 senke dann gehts, jedoch wenn ich den SSL Test erneuere bleibt es bei B und diversen Fehler. Der zickt wieder rum, hoffe du hast die Lösung dafür, ich habe die Optionen mal auskommentiert bis du weitere Anweisungen gibst. Hab jetzt alles mögliche versucht.
Edit:// hab die auskommentierung mal entfernt der einzige unterschied es sind alle balken grün, trotzdem noch "B" kannst es dir ja ma angucken.
Code: Alles auswählen
ssl_ciphers "EECDH+ECDSA+AESGCM EECDH+aRSA+AESGCM EECDH+ECDSA+SHA384 EECDH+ECDSA+SHA256 EECDH+aRSA+SHA384 EECDH+aRSA+SHA256 EECDH EDH+aRSA !aNULL !eNULL !LOW !3DES !RC4 !MD5 !EXP !PSK !SRP !DSS";
Code: Alles auswählen
add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
Code: Alles auswählen
ssl_session_cache shared:SSL:10m;
Edit:// hab die auskommentierung mal entfernt der einzige unterschied es sind alle balken grün, trotzdem noch "B" kannst es dir ja ma angucken.
Re: SSL auf Default Host von NGINX
Soo, nach kurzen 3 Std. Fehlersuche habe ich es nun endlich gelöst um A+ zu erreichen.
Die Lösung war eigentlich simpel und zwar anstatt cert.pem zu nehmen, habe ich es mit fullchain.pem versucht, mit Erfolg
Hoffe das dies nun so in Ordnung ist ausser die 2-3 kleinen Änderungen.
Lg Lea
Die Lösung war eigentlich simpel und zwar anstatt cert.pem zu nehmen, habe ich es mit fullchain.pem versucht, mit Erfolg

Hoffe das dies nun so in Ordnung ist ausser die 2-3 kleinen Änderungen.
Lg Lea
Re: SSL auf Default Host von NGINX
Das sind aber mal Arrgumente, wow! In der Tat ich kenne mich mit SSL nicht wirklich aus, aber einwenig sicherer fühle ich mich schon dabei.wanne hat geschrieben: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: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.
- 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.
Lg Leatrixa
-
- Beiträge: 30
- Registriert: 29.05.2017 14:15:13
- Lizenz eigener Beiträge: GNU Free Documentation License
Re: SSL auf Default Host von NGINX
Sicher?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.
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: Und gerade die Empfehlungen von ssllabs finde ich eher befremdliche politische Agenda als Sicherheitsfeatures.
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: 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.
Das Lesen von CVEs ist für jeden Serveradministrator Pflicht. Wer dies nicht tut, sollte keinen Webserver betreiben.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.
Die von mir vorgeschlagenen Diffie-Hellman Parameter sind selbst generiert, wie bereits aufgezeigt.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.
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.
Bevormundung? Starkes Wort. Ich will hier keine emotionale, sondern sachliche Debatte.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.
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.
Ich bevorzuge es, selbst Verantwortung für meine Systeme zu übernehmen und nicht immer und überall auf die Maintainer der Pakete zu vertrauen.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
Sobald TLS 1.3 von Nginx tried-and-tested angeboten wird, werde ich es in der Konfiguration hinzufügen.
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.wanne hat geschrieben: Das bevorzugen der NSA-Generierten Elliptischen Kurven würde ich nicht empfehlen. Finde ich nicht sehr vertrauenserweckend.
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.
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: 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.

Woher nimmst du die Information, dass Browser SPDY abschaffen? AFAIK ist HTTP/2 eine Erweiterung von SPDY und größtenteils abwärtskompatibel dazu.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.
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;
Viele Grüße
rne
Der Nachteil der Intelligenz besteht darin, daß man ununterbrochen gezwungen ist, dazuzulernen. -- George Bernard Shaw
Re: SSL auf Default Host von NGINX
Warum habe ich mir das schon gedacht Rne? :]
Oke, jaa ich habe mir bereits interessante Bücher über SSL angeguckt heute Morgen
Na suuuupi, werde ich gleich eintragen und was will ich mit serverfault wenn ich doch hier besonders dich Fragen kann
Viele Grüsse
Leatrixa
Oke, jaa ich habe mir bereits interessante Bücher über SSL angeguckt heute Morgen

Na suuuupi, werde ich gleich eintragen und was will ich mit serverfault wenn ich doch hier besonders dich Fragen kann

Viele Grüsse
Leatrixa
Re: SSL auf Default Host von NGINX
Welche wären das?Oke, jaa ich habe mir bereits interessante Bücher über SSL angeguckt heute Morgen![]()
Re: SSL auf Default Host von NGINX
Also ich habe heute Morgen, in der Bibliothek gesucht :] Da verlasse ich mich lieber darauf, das ich reingucken kann..eggy hat geschrieben:Welche wären das?
Hauptsächlich habe ich nach Krypthographie und Verschlüsselung gesucht. Aber wenn du etwas suchst guck ma bei Google, Amazon etc. hat bestimmt was :]
Re: SSL auf Default Host von NGINX
Da war natürlich gemeint in der Konfiguration.rne hat geschrieben:Sicher?
Btw. sind da 2 Sicherheitslücken, die drin die nur deine Konfiguration aber nicht den Default betreffen aber keine andersherum.
Übersicht vielleicht. Aber die noten sind ziemlich strange. Wie gesagt die Bestnoten bekommt man weder wenn man auf besonders Sicher (Dann müsste man definitiv TLS1.0 und kurze asymetrische Schlüssel rauswerfen. Daneben ist, wie schon angemerkt, PFS zumindest mit ziemlich sinnlos solange man den von Qualys an anderer stelle empfohlenen ssl session cache nutzt. Die möglichst lückenlose Umsetzung ist aber das hauptkriterium für die Benotung der Seite.) noch auf besonders kompatibel trimmt. (Dann müsste man diverse Fallbackciphers für ältere Browser (die aber neuere nicht betreffen, da TLS keine downgrades zulässt) akzeptieren).wanne hat geschrieben: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.
Das Ding kontrolliert einfach wie nahe man an den Empfehlungen in den Leitfäden mit denen Qualys sein Geld verdient bleibt. Das sind zum teil durchaus sinnvolle und gut gemeinte. Aber jede von denen ist eben durchaus streitbar. Sich in jedem Fall vollständig exakt so zu verhalten wie das für jemanden der selbst denkt und nicht einfach strickt Qualys Leitfäden nachbetet eher unwahrscheinlich.
Zuerstmal nein. Ganz im Gegenteil. Ich hatte darauf aufmerksam gemacht, dass Qualys vor einiger zeit noch audrücklich zur Abschaltung von AES und dem Umstieg auf ausschließlich RC4 geraten hat.rne hat geschrieben:Du empfiehlst also, von der Deaktivierung von RC4 aus Kompatibilitätsgründen zu Kosten der Sicherheit abzusehen.
Jetzt fahren sie in genau die entgegen gesetzte Richtung und wollen, dass man alles außer AES abschaltet. Wer heute die Empfehlungen von vor einiger Zeit umsetzt hat deutlich unsicherere Server als, jemand der die defaulteinstellungen von damals hat. Diese "Ddas ist der heilige und einzig richtige Weg"-Einstellung halte ich für ganz und gar nicht für gesund.
Man hat nicht umsonst mehrere Cihper in TLS eingebaut. Bei Problemen möglichst schnell auf einen anderen umsteigen zu können ist ein massives Sicherheitsfeature.
Wer TLS verstanden hat weiß, dass das aktivieren von RC4 mit niedrigster Priorität eben nicht der Sicherheit abträglich ist. Er wird nur verwendet, wenn der Client RSA-Signiert bestätigt hat dass er keinen sichereren Cipher spricht. In dem Fall wäre die Seite für dann gar nicht über https erreichbar und der Client würde üblicherweise dann ganz unverschlüsselt arbeiten.
Das sehe ich anders. Für solche Detailkenntnis habe ich einen Distributor der mich bei nicht behebbaren Problemen informiert und schnellstmöglich patched. Arbeitsteilunug halte ich für ein durchaus sinnvolles Konzept.rne hat geschrieben:Wer dies nicht tut, sollte keinen Webserver betreiben.
[…]
Ich bevorzuge es, selbst Verantwortung für meine Systeme zu übernehmen und nicht immer und überall auf die Maintainer der Pakete zu vertrauen.
Ja. Es gab allerdings in der Vergangenheit diverse Angriffe gegen schlechte DH-Parameter die mit der Länge stark anstiegen. 4096 waren nie realistisch angreifbar. 1024 mit einem PC. Ähnliches gilt für die lange vewendeten 512Bit RSA-Schlüssel. Mit modernen Algorithmen sind die halt knackbar. Ein bisschen Sicherheitsmarge schadet nicht.rne hat geschrieben:Des weiteren gelten 2048 Bit Schlüssel immer noch als ausreichend sicher.
RC4 ist kein sicherheitsproblm für neue Clienten. Sie nutzen es schlicht nicht. Das anschalten von RC4 betrifft nur Nutzer die mit ihren grottigen Clienten signalisieren, dass sie eh auf Sicherheit scheißen. Das einschalten von alten TLS-Versionen oder kurze DH-parameter betreffen aber auch moderne clienten. Deswegen bin ich da restriktiver. In der Kombination passt das aber natürlich nicht. Wer Wert auf abwärtskompatiblität legt, nimmt keine DH-Parameter mit was anderem als 2048 oder 4096 Bit und muss wohl oder übel noch immer TLS1 anschalten. Wer aber wert auf gesteigerte Sicherheit legt, der kann kein TLS1 laufen lassen.rne hat geschrieben: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.
Macht dir DH wirklich so viel aus?rne hat geschrieben: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.
Ich weiß nicht wieviele User du hast.
Er meint halt vor allem, dass die extrem schwierig sicher zu implementieren sind. Das ist ein wirklich guter Grund die dann nicht zu verwenden.wanne hat geschrieben: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.
Das problem ist, dass man danna auch rückwirkend alles entschlüsseln kann. PFS beziht sich leider nur auf die Keys nicht auf ein brechen der Algorithmen selbst.rne hat geschrieben: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.
SPDY war ne Entwicklung von Google. HTTP/2 eine Zusammenarbeit vieler Unternehmen. Vor allem halt Google und Micosoft. Und da google bei SPDY ganz gute Arbeit gemacht hat, hat man da viel draus übernommen. Man kann HTTP/2 aus technischer sicht also durchaus als Nachfolger von SPDY sehen. Politisch ist es aber eben eher der Nachfolger von HTTP/1.1 ein schöner standard den jeder spricht und versteht. Wobei schon SPDY mehr oder minder kaum Änderungen zu HTTP/1.1 mit all seinen Erweiterungen ist. Nur alle Zusatzfeatures jetzt mal geordnet und dann mit Header-Kompression. (Wo bei ich mal gespannt bin, wie uns das jetzt auf die Füße fällt. HTTPS kann nämlich auch Kompression von Headern. Das hat dann aber ordentlich ärger gemacht.) Technisch hoffe ich deswegen schon lange auf QUIC das macht wirklich vieles revolutionär besser.rne hat geschrieben:Woher nimmst du die Information, dass Browser SPDY abschaffen? AFAIK ist HTTP/2 eine Erweiterung von SPDY und größtenteils abwärtskompatibel dazu.
[/quote][/quote]rne hat geschrieben:Eine Quelle wäre interessant und könnte mich umstimmen.
https://techcrunch.com/2016/02/11/chrom ... on-may-15/
Zum firefox finde ich nichts, aber der 52er macht offiziell auch kein SPDY mehr, der 45 machte es noch.
rot: Moderator wanne spricht, default: User wanne spricht.