Certificate Pinning - TLS weiter absichern

[Frogman]

Wie ich in #36 schrieb, ist DANE eine Möglichkeit - doch wäre es eben auch technisch möglich, ein Zertifikat Pinning für SMTP umzusetzen. Dafür müssen es aber als Erweiterung der RFC-2821 sowohl die Server als auch diverse Mailclients unterstützen - was meines Wissens nicht in der Pipeine ist.

 

[Flanders]

Hallo,

ich bin gerade auf dieses Thema gestoßen. Ich habe nun ein LetsEncrypt Zertifikat.
Nun möchte ich die PhotoStation, die WebStation und die FileStation mit HSTS und HPKP absichern.

Dafür muss je der entsprechende Header gesetzt werden. Wenn ich aber über SSH auf die Diskstation gehe,
gibt es kein Verzeichnis /etc/httpd/conf/, es endet /etc/httpd

Vermutlich sind die Verzeichnisse gewechselt?
Wie kann ich die nötige Absicherung vornehmen??

Greets

Flanders

 

[Frogman]

Du musst schon mehr Informationen auswerfen.

 

[Frogman]

Änderung im DSM 6

Für all diejenigen, die auf DSM 6 umgestellt haben (das könnte u.U. auch Flanders betreffen, da er von Let's Encrypt schreibt, was ja im DSM 6 direkt bezogen werden kann) - dort sind einige Pfade für die Webserver geändert.
Man kann dann die Festlegungen bspw. in der Datei /usr/local/etc/httpd/sites-enabled/httpd.conf treffen - denn es gibt in der Standarddatei httpd.conf eine Direktive

Include sites-enabled/*.conf

zur Einbindung aller *.conf-Dateien im Unterordner 'sites-enabled'. Direkt in der /usr/local/etc/httpd/conf/httpd.conf läßt sich nichts ergänzen, weil diese bei einem Neustart neu generiert wird und damit Änderungen verloren gehen.
PS: Das Ganze gilt dann aber nur für den Apache...

 

[Flanders]

Danke für diesen Hinweis.
Also würde einfaches Anlegen einer Datei blabla.conf mit den Headern funktionieren!

ABER, leider habe ich gesehen, dass die PhotoStation auf nginx läuft !
Kann ich sie auf apache umstellen oder die Header auch bei nginx eingragen?

Bei nginx habe ich ja ebenfalls das Problem, dass Änderungen nicht erhalten bleiben!!

PS: Die FileStation läuft auch auf nginx!

Greets

Byte

 

[Frogman]

Läßt sich umstellen - ich selbst nutze aufgrund der Unzulänglichkeiten von DSM 6 das Ding nicht, musst mal selbst im Forum suchen, steht irgendwo.

 

[Flanders]

Hi,

welche Unzulänglichkeiten (bin gespannt, habe noch keine gesehen)?

Ich habe die Erfahrung gemacht, dass ein ständiges Update sicherheitsrelevant ist und viele Sicherheitslücken schließt...

Mein Ansatz ist nun:

/usr/local/etc/httpd/sites-enabled/safeHeaders.conf für Apache
/etc/nginx/sites-enabled/safetyHeaders.conf für nginx

eine EIGENE Config mit den Headern anzulegen, nach meinen ersten Test bleiben Sie auch nach einem Neustart erhalten!

Greets

Byte

 

[Frogman]

..., nach meinen ersten Test bleiben Sie auch nach einem Neustart erhalten!
...

Das war ja der Zweck des Hinweises, die Anpassung nicht in der regulären httpd.conf zu machen, sondern in dem Unterordner...

Zu den Unzulänglichkeiten kannst Du Dich gerne in den Threads zu den DSM 6.x vertiefen, da läßt sich alles nachlesen.

 

[Flanders]

OK, danke.

Eine brennende Frage habe ich aber noch.
Wie könnte ich das "Root"-Zertifikat pinnen?
Also ich möchte z.B. alle Zertifikate von LetsEncrypt akzeptieren...
Damit auch zukünftige Zertifikate / Verlängerungen funktionieren...

GAU wäre ja, ein Nutzer geht einen Tag vorher auf die Seite, dann aktualisiere ich das Zertifikat und er muss die angegebene Cachdauer warten, da er ein ungültiges (das neue) Zertifikat vom Server bekommt..
Ich hab noch keine Vorgehensweise für das Zertifikat des LetsEncrypt Servers gefunden...

Greets

Flanders

 

[Frogman]

Das Root-Zertifikat einer CA, welches oftmals eine sehr lange Laufzeit von mehr als 15 Jahren hat, solltest Du nicht direkt pinnen - schlichtweg deswegen, weil damit automatisch alle Zertifikate der CA akzeptiert würden, somit wäre das Pinning weitgehend nutzlos. Lies dazu nochmal meinen Startpost...
Im Falle von Let's Encrypt ist das Root-Zertifikat ohnehin nicht direkt verfügbar, weil es noch nicht in der Liste vertrauenswürdiger CA ausgerollt ist. Bis das der Fall ist, sind die Intermediates von Let's Encrypt durch die Root-Zertifikate von IdenTrust quersigniert (siehe hier).

 

[Frogman]

Um an dieser Stelle vielleicht einen Hinweis zu geben:
ich stehe mit einem Synology-Entwickler in Kontakt, um hier die Funktionalität des Pinnings als Feature in das DSM zu integrieren... und es schaut ganz gut aus. Das bedeutet, dass im Falle der Umsetzung das DSM beim Abrufen eines Let's Encrypt-Zertifikats dessen Pin automatisch mit dessen Laufzeit pinnt, neben dem Pin eines CSR, der vom Let's Encrypt-Agent mit dem privaten Schlüssel der jeweiligen Domain signiert ist und für die Beantragung des jeweils nächsten Zertifikats verwendet wird. Damit kann übergangslos von einem auf das nächste Zertifikat gewechselt werden, da immer ein Pin gültig ist.

 

[Fusion]

Nice work, freu mich schon drauf.

 

[Olaf_R]

Gibt es hierzu schon neuere Infos?
Wäre toll wenn Synology das Pinning, so wie skizziert, einbauen würde.

 

[Tatalus]

Augenscheinlich nicht.

Ich warte ebnfalls. Na ja ist ja erst ein Jahr her.

Gruß
Tatalus

 

[Angwulf]

@Flanders und Frogman,

wie hat so eine selbstgebaute .conf mit Key Pinning denn auszusehen (jeweils für nginx und Apache)? Sind die .conf Dateien vom Aufbau immer identisch? Kann man dort auch X-Frame Options einfügen (macht das Sinn)?

Gruß
Angwulf

 

[jahlives]

@frogman
ich dachte der zweite Pin sollte/müsste immer ein Backup Pin sein für den Fall, dass der erste Pin über'n Jordan geht. Wusste ned, dass man auch was "Zukünftiges" pinnen kann

 

[Frogman]

Naja, Du pinnst ja den Hash über den öffentlich Zertifikatsteil - dafür reicht auch bereits der CSR.

 

[jahlives]

mit "öffentlichen Zertifikatesteil" meinst du den Public Key? Erstellt nicht LE (bzw der certbot) jedes Mal einen neuen Private Key bei Ausstellung/Verlängerung eines Zertifikats? Dann wäre der gepinnte Public Key hinfällig.

 

[Frogman]

mit "öffentlichen Zertifikatesteil" meinst du den Public Key? .

ja

Erstellt nicht LE (bzw der certbot) jedes Mal einen neuen Private Key bei Ausstellung/Verlängerung eines Zertifikats?

Nö, nicht unbedingt, hängt auch vom Client ab. Bei dem von mir auf DSM5.2 angepassten Client kann ich konfigurieren, für den CSR bestehende Schlüssel zu verwenden. Ansonsten lies nochmal hier