SSL auf Default Host von NGINX

Alles rund um sicherheitsrelevante Fragen und Probleme.
Leatrixa
Beiträge: 46
Registriert: 01.04.2017 23:05:56

Re: SSL auf Default Host von NGINX

Beitrag von Leatrixa » 14.06.2017 12:01:32

Aktuelle Config:

Wie du oben in ps gepostet hast:

Code: Alles auswählen

server {
   listen 80 default_server;
   listen [::]:80 default_server;
   server_name domain.de;

   return 301 https://$host$request_uri$is_args$args;
}

server {
   # SSL configuration
   #
   listen 443 ssl default_server;
   listen [::]:443 ssl default_server;
   
   ssl    on;
   ssl_certificate       /etc/letsencrypt/live/domain.ch/cert.pem;
   ssl_certificate_key   /etc/letsencrypt/live/domain.ch/privkey.pem;
   # Self signed certs generated by the ssl-cert package
   # Don't use them in a production server!
   #
   # include snippets/snakeoil.conf;

   root /var/www/html;

   # Add index.php to the list if you are using PHP
   index index.html index.htm index.nginx-debian.html index.php;

   server_name domain.ch;

   location / {
      # First attempt to serve request as file, then
      # as directory, then fall back to displaying a 404.
      #try_files $uri $uri/ =404;
      try_files $uri $uri/ @rewrite;
   }

   # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
   #
   location ~ \.php$ {
      include snippets/fastcgi-php.conf;
      include /etc/nginx/fastcgi_params;
      fastcgi_pass unix:/var/run/php5-fpm.sock;
      fastcgi_read_timeout 300;
   }

   location ~ /\.ht {
   deny all;
   }
   # Hier sind die SEO URLs
   location @rewrite {
      rewrite ^/(forum/|team/|wcf/|bewegungen/|onlineliste/|benutzersuche/|mitgliederliste/|benachrichtigungen/|benachrichtigungs-einstellungen/|einstellungen/|verwaltung/|avatar/|signatur/|folgen/|blockierliste/|datenschutz/|impressum/|konversationen/|moderation/|schnellsuche/|abonennten/|news/|erstellen/|neu/|seiten/|bewerbung/|pillory-bans/|pillory-warnings/|notizen/|freunde/|kontakt/)?([^.]+)$ /$1index.php?$2 last;
   }
   #
}
Die Seite funktioniert, aber sie ist nur teilweise sicher und somit mit einem orangen ausrufezeichen.
Zuletzt geändert von Leatrixa am 14.06.2017 12:09:35, insgesamt 1-mal geändert.

rne
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

Beitrag von rne » 14.06.2017 12:05:42

Leatrixa hat geschrieben: Die Seite funktioniert, aber sie ist nur teilweise sicher und somit mit einem orangen ausrufezeichen.
Das liegt dann aber am HTML Inhalt der Seite selbst und ist kein Problem des Webservers.
→ Anderes Thema :wink:

PS: Schön, dass es funktioniert. Ich kann, wenn ich Zeit habe, eine detaillierte Erklärung der Konfiguration nachreichen.
PPS: Entferne mal zur Sicherheit gegen Bots & Spam die tatsächliche URL aus deinem Code-Block.
PPPS: Im HTML Code der Website habe ich folgendes gefunden, was wohl für die Mischinhaltswarnung verantwortlich sein dürfte:

Code: Alles auswählen

<img src="http://<deine_domain>/wcf/images/styleLogo-6a3a8820dd523bffc536c7586a40a61a2f232d1b.png" alt="" /></a>
Zuletzt geändert von rne am 14.06.2017 12:12:27, insgesamt 2-mal geändert.
Der Nachteil der Intelligenz besteht darin, daß man ununterbrochen gezwungen ist, dazuzulernen. -- George Bernard Shaw

Leatrixa
Beiträge: 46
Registriert: 01.04.2017 23:05:56

Re: SSL auf Default Host von NGINX

Beitrag von Leatrixa » 14.06.2017 12:08:07

Html? Dieses Woltlab Forum ist PHP ? o.O

rne
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

Beitrag von rne » 14.06.2017 12:11:24

Leatrixa hat geschrieben:Html? Dieses Woltlab Forum ist PHP ? o.O
PHP ist eine serverseitige Skriptsprache zur Generierung von HTML. Was vom Webserver zurückgeliefert wird und im Webbrowser angezeigt wird ist HTML, nicht PHP. Davon bekommt der Anwender nichts mit.
Zuletzt geändert von rne am 14.06.2017 12:13:31, insgesamt 1-mal geändert.
Der Nachteil der Intelligenz besteht darin, daß man ununterbrochen gezwungen ist, dazuzulernen. -- George Bernard Shaw

Leatrixa
Beiträge: 46
Registriert: 01.04.2017 23:05:56

Re: SSL auf Default Host von NGINX

Beitrag von Leatrixa » 14.06.2017 12:12:31

Aaaaah okay, und dies kann man fixen damit dies nicht mehr steht ?

rne
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

Beitrag von rne » 14.06.2017 12:14:46

Leatrixa hat geschrieben:Aaaaah okay, und dies kann man fixen damit dies nicht mehr steht ?
Ja, ersetze im HTML / PHP Code das http:// durch https://.
Wahrscheinlich ist dies eine Einstellung in der Admin-Oberfläche der Forensoftware, wo du das Logo einstellen kannst.
Der Nachteil der Intelligenz besteht darin, daß man ununterbrochen gezwungen ist, dazuzulernen. -- George Bernard Shaw

Leatrixa
Beiträge: 46
Registriert: 01.04.2017 23:05:56

Re: SSL auf Default Host von NGINX

Beitrag von Leatrixa » 14.06.2017 12:16:45

Habe gerade gegoogelt und der sagt mir das gleiche das werde ich gleich mal tun, es scheint schon richtig zu funktionieren.

Gib gleich nochma nen Feedback.

Leatrixa
Beiträge: 46
Registriert: 01.04.2017 23:05:56

Re: SSL auf Default Host von NGINX

Beitrag von Leatrixa » 14.06.2017 12:21:04

Tatsächlich, yeeeeeeh!

Wooooow! Vielen herzlichen Dank für deine super Unterstützung Rne :]

Es zickt, zwar noch einbischen rum aber da werde ich wohl alle http stellen ersetzen müssen.
Manche stellen im Forum.

rne
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

Beitrag von rne » 15.06.2017 13:23:19

Nur der Vollständigkeit halber.
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>
Entsprechende Konfigurationsoptionen habe ich am Anhang Anfang des Fadens bereits genannt.
Bei Rückfragen erläutere ich das Hardening gerne in einem neuen Faden.
Zuletzt geändert von rne am 15.06.2017 21:23:15, insgesamt 2-mal geändert.
Der Nachteil der Intelligenz besteht darin, daß man ununterbrochen gezwungen ist, dazuzulernen. -- George Bernard Shaw

Leatrixa
Beiträge: 46
Registriert: 01.04.2017 23:05:56

Re: SSL auf Default Host von NGINX

Beitrag von Leatrixa » 15.06.2017 20:50:19

Vielen Dank für deine Aufmerksamkeit, habe ich jetzt ebenfalls gesehen jedoch habe ich deine Anpassung der Config eingestellt, bzw. ist meine momentane Konfiguration.

Wie oder was fehlt denn noch damit es vernünftigt gesichert ist?

Lieben Dank für deine Aufmersame Hilfe.

Code: Alles auswählen

PS:

server {
   listen 80 default_server;
   listen [::]:80 default_server;
   server_name domain.de www.domain.de;

   return 301 https://$host$request_uri$is_args$args;
}

server {
   # SSL configuration
   #
   listen 443 ssl default_server;
   listen [::]:443 ssl default_server;
   
   ssl    on;
   ssl_certificate       /etc/letsencrypt/live/domain.de/cert.pem;
   ssl_certificate_key   /etc/letsencrypt/live/domain.de/privkey.pem;
   # Self signed certs generated by the ssl-cert package
   # Don't use them in a production server!
   #
   # include snippets/snakeoil.conf;

   root /var/www/html;

   # Add index.php to the list if you are using PHP
   index index.html index.htm index.nginx-debian.html index.php;

   server_name domain.de www.domain.de;

   location / {
      # First attempt to serve request as file, then
      # as directory, then fall back to displaying a 404.
      #try_files $uri $uri/ =404;
      try_files $uri $uri/ @rewrite;
   }

   # pass the PHP scripts to FastCGI server listening on 127.0.0.1:9000
   #
   location ~ \.php$ {
      include snippets/fastcgi-php.conf;
      include /etc/nginx/fastcgi_params;
      fastcgi_pass unix:/var/run/php5-fpm.sock;
      fastcgi_read_timeout 300;
   }

   location ~ /\.ht {
   deny all;
   }
   # Hier sind die SEO URLs
   location @rewrite {
      rewrite ^/(forum/|team/|wcf/|bewegungen/|onlineliste/|benutzersuche/|mitgliederliste/|benachrichtigungen/|benachrichtigungs-einstellungen/|einstellungen/|verwaltung/|avatar/|signatur/|folgen/|blockierliste/|datenschutz/|impressum/|konversationen/|moderation/|schnellsuche/|abonennten/|news/|erstellen/|neu/|seiten/|bewerbung/|pillory-bans/|pillory-warnings/|notizen/|freunde/|kontakt/)?([^.]+)$ /$1index.php?$2 last;
   }
   #
}

Leatrixa
Beiträge: 46
Registriert: 01.04.2017 23:05:56

Re: SSL auf Default Host von NGINX

Beitrag von Leatrixa » 15.06.2017 20:56:22

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

rne
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

Beitrag von rne » 15.06.2017 21:14:54

Meine Rede war von diesen TLS Optionen:
rne hat geschrieben: SSL und SPDY aktivieren

Code: Alles auswählen

listen 443 ssl spdy
Generische Diffie-Hellman Parameter für die HTTPS vServer

Code: Alles auswählen

ssl_dhparam /etc/nginx/conf.d/https-generic-2048.dh;
SSL Session Cache auf 10 Minuten begrenzen

Code: Alles auswählen

ssl_session_cache shared:SSL:10m;
Nur TLS ab Version 1.0 erlauben (Nachfolger von SSL)

Code: Alles auswählen

ssl_protocols TLSv1 TLSv1.1 TLSv1.2; 
Vom Server angebotene Chiffren bei der Aushandlung bevorzugen

Code: Alles auswählen

ssl_prefer_server_ciphers on;
Die von Server bevorzugten Chiffren

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";
Für Eliptic Curve Schlüsseltausch zu verwendende Kurve

Code: Alles auswählen

ssl_ecdh_curve secp384r1;
HSTS aktivieren.

Code: Alles auswählen

add_header Strict-Transport-Security "max-age=31536000; includeSubDomains; preload";
OCSP Stapling aktivieren

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

Leatrixa
Beiträge: 46
Registriert: 01.04.2017 23:05:56

Re: SSL auf Default Host von NGINX

Beitrag von Leatrixa » 15.06.2017 21:17:19

Aaaaah optionen okey und die kann ich in die Default Config packen?
Wenn ja, wo muss ich die einfügen?

rne
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

Beitrag von rne » 15.06.2017 21:26:21

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:

Code: Alles auswählen

openssl dhparam -out /etc/nginx/conf.d/https-generic-2048.dh 2048
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

Code: Alles auswählen

include conf.d/tls
am Anfang einfügen.
Der Nachteil der Intelligenz besteht darin, daß man ununterbrochen gezwungen ist, dazuzulernen. -- George Bernard Shaw

Leatrixa
Beiträge: 46
Registriert: 01.04.2017 23:05:56

Re: SSL auf Default Host von NGINX

Beitrag von Leatrixa » 15.06.2017 21:47:07

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 :)

wanne
Moderator
Beiträge: 7448
Registriert: 24.05.2010 12:39:42

Re: SSL auf Default Host von NGINX

Beitrag von wanne » 15.06.2017 23:00:22

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.
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>
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.
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.
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.
rot: Moderator wanne spricht, default: User wanne spricht.

Leatrixa
Beiträge: 46
Registriert: 01.04.2017 23:05:56

Re: SSL auf Default Host von NGINX

Beitrag von Leatrixa » 15.06.2017 23:39:31

Also wenn ich folgene Optionen einfüge, kommt nen Fehler von Nginx also startet nicht das wären folgende:

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;
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.

Leatrixa
Beiträge: 46
Registriert: 01.04.2017 23:05:56

Re: SSL auf Default Host von NGINX

Beitrag von Leatrixa » 16.06.2017 00:52:04

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

Leatrixa
Beiträge: 46
Registriert: 01.04.2017 23:05:56

Re: SSL auf Default Host von NGINX

Beitrag von Leatrixa » 16.06.2017 00:54:11

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.
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>
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.
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.
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.
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.

Lg Leatrixa

rne
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

Beitrag von rne » 16.06.2017 10:03:58

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. :wink:
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
Der Nachteil der Intelligenz besteht darin, daß man ununterbrochen gezwungen ist, dazuzulernen. -- George Bernard Shaw

Leatrixa
Beiträge: 46
Registriert: 01.04.2017 23:05:56

Re: SSL auf Default Host von NGINX

Beitrag von Leatrixa » 16.06.2017 13:13:35

Warum habe ich mir das schon gedacht Rne? :]

Oke, jaa ich habe mir bereits interessante Bücher über SSL angeguckt heute Morgen :-D

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

Viele Grüsse
Leatrixa

eggy
Beiträge: 3331
Registriert: 10.05.2008 11:23:50

Re: SSL auf Default Host von NGINX

Beitrag von eggy » 16.06.2017 13:29:54

Oke, jaa ich habe mir bereits interessante Bücher über SSL angeguckt heute Morgen :-D
Welche wären das?

Leatrixa
Beiträge: 46
Registriert: 01.04.2017 23:05:56

Re: SSL auf Default Host von NGINX

Beitrag von Leatrixa » 16.06.2017 13:46:57

eggy hat geschrieben:Welche wären das?
Also ich habe heute Morgen, in der Bibliothek gesucht :] Da verlasse ich mich lieber darauf, das ich reingucken kann..

Hauptsächlich habe ich nach Krypthographie und Verschlüsselung gesucht. Aber wenn du etwas suchst guck ma bei Google, Amazon etc. hat bestimmt was :]

wanne
Moderator
Beiträge: 7448
Registriert: 24.05.2010 12:39:42

Re: SSL auf Default Host von NGINX

Beitrag von wanne » 17.06.2017 19:54:52

rne hat geschrieben:Sicher?
Da war natürlich gemeint in der Konfiguration.
Btw. sind da 2 Sicherheitslücken, die drin die nur deine Konfiguration aber nicht den Default betreffen aber keine andersherum.
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.
Ü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).
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.
rne hat geschrieben:Du empfiehlst also, von der Deaktivierung von RC4 aus Kompatibilitätsgründen zu Kosten der Sicherheit abzusehen.
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.
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.
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.
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:Des weiteren gelten 2048 Bit Schlüssel immer noch als ausreichend sicher.
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: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.
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: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.
Macht dir DH wirklich so viel aus?
Ich weiß nicht wieviele User du hast.
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.
Er meint halt vor allem, dass die extrem schwierig sicher zu implementieren sind. Das ist ein wirklich guter Grund die dann nicht zu verwenden.
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. ;)
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:Woher nimmst du die Information, dass Browser SPDY abschaffen? AFAIK ist HTTP/2 eine Erweiterung von SPDY und größtenteils abwärtskompatibel dazu.
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:Eine Quelle wäre interessant und könnte mich umstimmen.
[/quote][/quote]
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.

Antworten