Der Chat-Ersatz-Plauder-Thread

Hallo,

Zitat von Black Rider

Zusätzlich wäre es sicherlich nicht schlecht, eigene schöne DH-Parameter zu generieren und zu nutzen.

ich selbst hätte DHE gleich vollständig entfernt. Dann fehlt dir zwar in Android 2.3.7, Java 6 und OpenSSL 0.9.8 die Forward Secrecy, aber die sind (in meinem Fall) wegen SNI ohnehin außen vor. Und selbst wenn das passende Zertifikat käme ist es mir lieber die Liste der erlaubten Ciphersuites kurz zu halten, anstatt diesen uralt-Systemen Forward Secrecy zu geben.

Wenn man den IE 8 unter XP nicht mehr möchte, dann entfernt man am besten auch noch 3DES.

A+

Zitat von Black Rider

Wenn du HSTS einrichtest, bekommst du sicherlich A+, wobei Caching auch nicht schlecht wäre (forum.nginx.org/read.php?2,152294,152294) sowie die Nutzung von OCSP Stapling.

A+ schön und gut, aber jetzt haut er mir bei HTTP-Requests 400er (The plain HTTP request was sent to HTTPS port) um die Ohren. Hast nen nen Tipp? Ich habe die Konfiguration sogar bereits zurückgesetzt, aber irgendwie spinnt er immer noch rum.

server {
	listen	80;
	server_name blub.bla.de;
	rewrite ^	https://$server_name$request_uri? permanent;
}

server {
	root /vhost/bla/blub;
	listen	443 ssl http2;
	index index.php;
	server_name blub.bla.de;
	ssl_certificate /etc/letsencrypt/live/blub.bla.de/fullchain.pem;
	ssl_certificate_key /etc/letsencrypt/live/blub.bla.de/privkey.pem;
	ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	ssl_prefer_server_ciphers on;
	ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
}

Das ist aber die Konfiguration von vor A+, oder?
Die danach wäre wesentlich interessanter. Vermutlich hast du nicht alles exakt identisch zurückgesetzt.

Der Fehler kann mehrere Ursachen haben. Ich habe auch mal darüber geschrieben:
https://kittblog.com/article/6…port-unter-nginx-beheben/

Zitat von Black Rider

Das ist aber die Konfiguration von vor A+, oder?

Nein, das ist die Konfiguration von A und identisch zur vorherigen, da ich die Dateien überschrieben habe.
A+ war das hier (ssl_ciphers #2 braucht GitLab angeblich):

##
	# SSL Settings
	##
	#ssl_ciphers 'EECDH+AESGCM:EDH+AESGCM:AES256+EECDH:AES256+EDH';
	#ssl_ciphers "ECDHE-RSA-AES256-GCM-SHA384:ECDHE-RSA-AES128-GCM-SHA256:ECDHE-RSA-AES256-SHA384:ECDHE-RSA-AES128-SHA256:ECDHE-RSA-AES256-SHA:ECDHE-RSA-AES128-SHA:ECDHE-RSA-DES-CBC3-SHA:AES256-GCM-SHA384:AES128-GCM-SHA256:AES256-SHA256:AES128-SHA256:AES256-SHA:AES128-SHA:DES-CBC3-SHA:!aNULL:!eNULL:!EXPORT:!DES:!MD5:!PSK:!RC4";
	#ssl_protocols TLSv1 TLSv1.1 TLSv1.2;
	#ssl_prefer_server_ciphers on;
	#ssl_session_cache shared:SSL:10m;
	#ssl_session_timeout 5m;
	#ssl_dhparam /etc/ssl/certs/dhparam.pem;
	#ssl_stapling on;
	#ssl_stapling_verify on;
	#resolver 8.8.8.8 8.8.4.4 valid=300s;
	#resolver_timeout 5s;

fastcgi_param HTTPS on; bewirkt übrigens auch keine Änderung. Genauso das Zusammenlegen in einen Serverblock. Wenn ich vor sämtlichen Regeln deny all einfüge, passiert ebenfalls nichts neues.
Ich habe gerade nochmal eine ganz originale Konfiguration ausgepackt und die jetzige damit überschrieben, dann ging es, dann wieder mit der jetzigen überschrieben und es geht immer noch (mit einer anderen Domain probiert, damit der Redirect-Cache nicht greift). Das muss ich hoffentlich nicht verstehen.
Ich suche nachher mal den Knackpunkt…

Hallo,

Zitat von MysteryCode

aber jetzt haut er mir bei HTTP-Requests 400er (The plain HTTP request was sent to HTTPS port)

vielleicht versehentlich in irgendeinem vHost ein listen 80 ssl spezifiziert?

Eigentlich sehr unwahrscheinlich, da ich die Ports nicht angerührt habe.

Zitat von MysteryCode

vs1 steht im Accelerated und vs2 im First Colo, falls du sie mal besuchen willst.

Solange du nicht in die Lagerhalle gehst, denn da gibts Sprinkler . Tim war ja nur im acc weil er beim Schinzel unter gekommen ist, aber die Protection war da nicht so geil wie im FC.

Wie war euer Wochenende so?

Zitat von jacboy

denn da gibts Sprinkler

Die werden hoffentlich nicht auslösen.