Wer trusted wem ?

Mardor

Well-Known Member
Hi,

nachdem Nexcloud nun funktionsfähig ist wollte ich nun über NGINX einen Reverse Proxy auf einem komplett anderen Host davorsetzen:

Client --> Internet --> cloud.xyz.abc ---> backend.xyz.abc

Für cloud.xyz.abc benutze ich let's encrypt, für backend.xyz.abc nutze ich bereits meine Zertifikate. Ich habe mich nun gefragt wie denn cloud.xyz.abc ohne root-CA überhaupt backend.xyz.abc traut, denn die Verbindung zu backend.xyz.abc mit der nextcloud funktioniert bereits ohne irgendwelche Zertifikate zu installieren.

Wo müsste die Root-CA den in cloud.xyz.abc reingelegt werden ?

Gruß Mardor
 
Cloud ist der Reverse Proxy? Der terminiert SSL? Bzw. hättest du entsprechend eine nginx-Config damit das vielleicht klar ist?

Mit Root-CA meinst du was genau? Eigentlich gehört die Chain aber eher mit Intermediate-Zertifikat und dem Zertifikat in dein public key file, wenn du nginx nutzt.

Wegen Vertrauen. Wenn du auf cloud.xyz.abc HTTPS terminierst, hat du potentiell nur HTTP zwischen dem und backend.xyz.abc. Da kommt's drauf an, ob du das wirklich willst, weil die Verbindung dazwischen potentiell unverschüsselt/unauthentifiziert ist. Wenn das zwei Hosts auf der selben Maschine sind oder das sowas wie ein VLAN oder ähnliches ist, macht das weniger, wenn das in einer nicht vertrauten Umgebung (Internet, öffentliches Datencenter, öffentliche Cloud, etc.) ist ist das eher eine schlechte Idee.

Da gibt's mehrere Lösungsansätze und dann kommt es drauf an, was du willst, was der Sinn beim Reverse Proxy wirklich ist. Wenn der Proxy eher der öffentlich erreichbare Server sein soll, du dich nicht um Caching dort kümmerst könntest du einfach einen TCP-Proxy machen und auf backend terminieren. Das ist dann interessant, wenn du aus welchem Grund auch immer einfach keine anderen Zugriffe auf den Backend Server haben willst.

Du könntest zwei mal terminieren, was auf Performance geht. Oder wenn die Verbindung zwischen den beiden ohnehin sicher ist (Tunnel, nebeneinander, etc.) kannst du einfach weiterhin HTTP dazwischen verwenden.

Ist das Ganze in der Cloud? Dann gibt's normalerweise eine Lösung was dir irgendeinen Tunnel/VPN dazwischen baut.

Oder ist damit ein CDN gemeint? Die haben manchmal die sehr unelegante Lösung dass du ihnen vollkommen vertrauen müsstest und ihnen deinen private Key geben musst. In diesem Fall ist es eine gute Idee statische und dynamische Daten zu trennen und auf zwei (virtuelle) Hosts zu verteilen - ist ohnehin meist eine gute Idee. Weiß jetzt nicht ob das unter Nextcloud geht. Wobei ohnehin die Frage ist, ob CDN mit Nextcloud nicht dem Zweck widerspricht.

Die kurze Antwort ist: Zertifikate brauchst du nur dort wo du TLS/HTTPS terminierst. Wo du terminieren solltest hängt von der Verbindung zwischen den beiden Hosts ab. Du könntest wie gesagt zwei mal terminieren. Nicht das Schönste (vor allem von der Performance, aber auch dadurch das beide Server damit Angriffspunkte wären), aber je nach dem wie groß die Maschinen sind und wie viel das genutzt wird am Flexibelsten.

Ich hoffe das hilft. Hoffentlich habe ich das nicht ganz falsch verstanden.
 
Cloud ist der Reverse Proxy? Der terminiert SSL? Bzw. hättest du entsprechend eine nginx-Config damit das vielleicht klar ist?
Ja, cloud ist der Reverse Proxy. Let's Encrypt terminiert auf Cloud.

Mit Root-CA meinst du was genau? Eigentlich gehört die Chain aber eher mit Intermediate-Zertifikat und dem Zertifikat in dein public key file, wenn du nginx nutzt.
Du hast recht, ich habe mich falsch ausgedrückt. Das Intermediate, der Pubkey und Private Key befinden sich auf backend-cloud.

Wegen Vertrauen. Wenn du auf cloud.xyz.abc HTTPS terminierst, hat du potentiell nur HTTP zwischen dem und backend.xyz.abc. Da kommt's drauf an, ob du das wirklich willst, weil die Verbindung dazwischen potentiell unverschüsselt/unauthentifiziert ist.
Genau das möchte ich absolut nicht. Sowohl cloud als auch backend-cloud sind separate Server bei Hetzner.

Das ist dann interessant, wenn du aus welchem Grund auch immer einfach keine anderen Zugriffe auf den Backend Server haben willst.
Meine Hetzner Server besitzen nur eine IP Adresse. Auf backend-cloud laufen aber in mehreren Jails verteilte (und auf unterschiedliche Ports laufende Jails). Der reverse proxy soll einfach die Anfrage für url1 annehmen und beispielsweise den Request auf backend-cloud tcp port 6443 weiterleiten.

Ist das Ganze in der Cloud? Dann gibt's normalerweise eine Lösung was dir irgendeinen Tunnel/VPN dazwischen baut.
Hilft das bei meiner Anforderung ?

Die kurze Antwort ist: Zertifikate brauchst du nur dort wo du TLS/HTTPS terminierst. Wo du terminieren solltest hängt von der Verbindung zwischen den beiden Hosts ab. Du könntest wie gesagt zwei mal terminieren. Nicht das Schönste (vor allem von der Performance, aber auch dadurch das beide Server damit Angriffspunkte wären), aber je nach dem wie groß die Maschinen sind und wie viel das genutzt wird am Flexibelsten.
Diese Methode war meine ursprüngliche Idee. Wie bekomme ich denn nginx dazu das er dem Zertifikat von cloud vertraut.

Gruß Mardor
 
Dumme Frage:

Würde dies bedeuten, ich habe auf dem Server (Nextcloud/backend-cloud) ja ein certificate und ein key, hier würde ich das cert auf den nginx (reverse proxy/cloud) als proxy_ssl_trusted_certificate kopieren ?

Gruß Mardor
 
Hi,

ich würde dies einfach so wie von mir vermutet testen.

Kennt jemand von euch eine Webseite die die aktuell einzustellenden openssl (openssl.conf) Algorithmen als Empfehlung gibt. Meine eigene Anleitung ist schon etwas älter und benutzt als Einstellung SHA1.

Ich will da einfach auf dem neusten Stand sein.

Ich denke da an soetwas wie https://infosec.mozilla.org/guidelines/openssh.html nur eben nicht für openssh sondern für openssl ?

Gruß Mardor
 
Hi,

diese Webseiten kenne ich, allerdings wird hier mehr auf die Konfiguration des Webservers eingegangen. Ich möchte ja aber openssl Zertifikate ausstellen und eine neue Root-CA inkl. Intermediate. Mir fehlen einfach die korrekten Parameter für die openssl.cnf. In meiner Konfiguation gibt es allerdings relativ wenige Parameter bzgl. Verschlüsselung.
 
Zurück
Oben