Certificate Pinning - TLS weiter absichern

[Angwulf]

Das ist der Zertifikats Pin: wZiBnQYkrINZ8awN4kTNHGBkWGuQxTLroznxgYjgv6U=

 

[Frogman]

Ok, der sieht auch gut aus.
Ist unter Webdienst denn der Haken bei "Web Station aktivieren"? HTTPS etwas weiter unten ist aktiviert?

 

[Angwulf]

Den Haken kann ich nicht mehr setzen! Setze ich den Haken bei Web Station aktivieren, wird das mit der Meldung 'Operation fehlgeschlagen' abgebrochen.

 

[Frogman]

Und die gleiche Meldung kommt auch beim kompletten Neustart der DS?
Ich hänge mal gepackt die originale Datei an - Du kannst damit Deine mit WinSCP ja mal überschreiben, um auszuschließen, dass dort noch Syntax- oder Formatfehler enthalten sind. Das Zip entpacken und dann im linken Fenster von WinSCP dorthin navigieren, rechts in den entsprechenden Ordner der DS und dann rüberziehen.

 

[Angwulf]

Mit deiner Original Datei funktioniert nun wieder alles. Danke!!!!

Dann werde ich nochmal die Headerzeile ergänzen und gucken, was passiert.

 

[Frogman]

Es muss klappen - bei mir läuft's ja auch

 

[Angwulf]

Super!!

Das hat jetzt geklappt! Danke für deine Hilfe und Geduld! Und auch für den Tipp mit dem WinSCP, das macht die Sache mit der Konsole endlich überflüssig^^.

 

[Frogman]

Gerne. Und viel Spaß weiterhin mit dem Absichern der DS

 

[Frogman]

Kleine Ergänzung: Firefox und Chrome prüfen RFC-gemäß inzwischen intern auf das Vorhandensein von mindestens zwei Pins im Header - ist nur einer angegeben, wird zumindest vom Firefox in der Kosnsole ein Fehler "The site specified an invalid Public-Key-Pins header." ausgegeben und das Pinning ignoriert. Chrome meckert hier aktuell leider gar nicht, er ignoriert dann das Pinning einfach stillschweigend.
Ergo: man muss also immer mindestens zwei Pins angeben, also am besten ein aktuelles Zertifikat und ein Reserve-CSR.

 

[Nima]

Neues Jahr, neues Glück! Also mal das Pinning ausprobieren.

Als erstes fällt mir auf, ich habe die Datei cert.pem im Verzeichnis /usr/syno/etc/ssl/ssl.crt/server.crt gar nicht.
Und zweitens fehlt mir auch die Datei httpd-ssl.conf-user im Verzeichnis /etc/httpd/conf/extra/.
Ist das normal?

Aus dem Let's encrypt hatte ich 4 Dateien generiert:
accoun.key
domain.key
chained.pem
dhparam.pem

accoun.key = ca.crt
domain.key = server.crt
aber welches pem ist nun der cert.pem?

 

[Frogman]

Und zweitens fehlt mir auch die Datei httpd-ssl.conf-user im Verzeichnis /etc/httpd/conf/extra/.

Du hast aber die Web Station im DSM und dafür auch https aktiviert?

 

[Nima]

Nein. Wozu? Ich nutze die Web Station gar nicht.

 

[Nima]

Funktioniert leider nicht...

 

[Frogman]

Die Datei httpd-ssl.conf-user nutzt Du ja, um das Zertifikat für den User-Apache zu pinnen - der ist für die Dinge da, die nicht über den System-Webserver laufen (also bspw. die Photo Station oder anderes).
Willst Du den System-Webserver auf das Zertifikat pinnen, musst Du die Anpassungen in der /etc/httpd/conf/extra/httpd-ssl.conf-sys vornehmen, für WebDAV in /etc/httpd/conf/extra/httpd-ssl.conf-webdav.

 

[Nima]

Wie Axel Stoll sagen würde: muss man wissen.
Also jeder Dienst nutzt seine eigenen Zertifikate???
Wobei hier die gleichen verwendet werden? Und man muss alles separat pinnen, damit alle SSL Verbindungen geschützt sind? Ist Mail auch noch mal extra?

 

[Frogman]

Nein, alle nutzen die gleichen Zertifikate.
Die Frage, ob ein Webserver für eine https-Verbindung ein Pinning ausliefert, kann separat in den Konfig-Files festgelegt werden. Die gepinnten Zertifikate des DSM können sich dabei auch von denen des User-Webservers unterscheiden (bsp. könnte man im DSM das Root-Zertifikat pinnen, im User-Webserver das Serverzertifikat). Es macht allerdings eher Sinn, beide Webserver gleich zu pinnen.
Das betrifft hier Apache-Webserver, dafür muss der Client, also der Browser, ein Pinning unterstützen - email läuft dagegen über einen SMTP-Server, dafür steht das meines Wissens nicht zur Verfügung. Hier bietet sich dann auch DANE an, wenn der Hoster das in seinem DNS unterstützt.

 

[Nima]

Okay. Mir erschliesst sich der Sinn aber nicht. Wieso wird jeweils separat das gleiche Zertifikat hinterlegt? Auch jeweils verschiedene Zertifikate würden ja keinen Sicherheitsgewinn bringen. Also: why???
Das Pinnen macht ja Sinn, um Mitm zu verhindern. Und das ist ja bei allen Diensten sinnvoll. Bringt ja dann faktisch nur mehr Arbeit ohne weiteren Nutzen. Oder übersehe ich da was?

 

[Frogman]

Dass man getrennte Festlegungen zu machen hat, liegt einfach daran, dass auf der DS nicht nur ein Webserver läuft. Und ich schrieb ja, dass es sinnvoll ist, die Webserver gleich zu pinnen - zu der Frage, mit welchem Zertifikat, habe ich eingangs ja einiges geschrieben.

...Das Pinnen macht ja Sinn, um Mitm zu verhindern. Und das ist ja bei allen Diensten sinnvoll.

Sinnvoll schon, aber nur dann, wenn es auch die Clients unterstützen... und hier sind es bisher eigentlich nur Browser, die dazu zählen, bspw. um sicherheitsrelevante Verbindung wie Onlinebanking usw. abzusichern. Das Ganze ist ja auch nur ein Mittel und dient auch ein wenig zur zeitlichen Überbrückung, bis sich eine grundlegende Architektur wie DANE/DNSSEC durchgesetzt hat - dann erfolgt praktisch über den TLSA ein Pinning auf das Serverzertifikat.

 

[Nima]

Meinen die hier heise.de/security/meldung/Posteo-testet-Certificate-Pinning-2849267.html
TLS Spinning für die Mailübertragung oder reden die hier von der WebGui?

 

[Fusion]

@Nima - die reden von ihrem Webmailer / WebGUI.
Für die Übertragung zwischen Mailservern bzw. MTA (via SMTP) benötigt es z.B. DANE.