An meinem nginx hängen als Beispiel 2 Backend. BackendA und BackendB
public IP -> nginx -> Backend A, Backend B etc...
Nun möchte ich, dass der gesamte Traffic für *.app.domain.tld an BackendA geht und zwar HTTPS wie auch HTTP ohne, dass nginx die SSL terminierung macht. Dies deshalb, weil BackendA selbst ein SSL Zertifikat von LetsEncrypt ausliefern soll und dieses auch selbst bezieht.
BackendB hingegen macht keine SSL terminierung, hier soll nginx dies übernehmen.
Für BackendB ist mir klar wie es geht. Jedoch weiss ich nicht, wie ich dies für BackendA implementieren kann.
Kennt sich hier jemand damit aus?
Idealerweise weiss jemand, wie dies mit dem nginx proxy manager gemacht werden kann.
Wie unterscheidest du denn, ob eine eingehende Verbindung nach A oder B geht? Um an den Request ranzukommen (URL, Header, etc) muß SSL ja erstmal terminiert werden.
Ob / wie nginx das kann, kann ich nicht sagen. Aber das Stichwort um SSL so zo Routen ist "TLS SNI reverse Proxy" (oft kurz "SNI Proxy" genannt).
(Da gibt es diverse Projekte. (Ich hatte zum spass auch mal einen geschrieben https://github.com/Daniel-Abrecht/DPA-SSL-SNI-Forwarder aber keine Ahnung, ob der noch geht, und Wildcards hatte ich dort noch nicht implementiert).
Was man dabei noch beachten muss, ist, Der SNI muss nicht zwangsweise vorhanden sein. Bei ganz alten Browsern hängt er. Und bei ganz neuen TLS Versionen gibt es glaube ich einen alternativen Weg (ESNI / ECH), für Server das richtige Zertifikat auszuhandeln, weil das ja eine streng geheime Information ist. Da geht das dann auch nicht mehr. Ist also nicht unbedingt eine gute Idee, sich darauf zu verlassen.
Auch noch zu beachten ist, dass der SNI und der Host Header nicht immer der selbe ist. Man kann also im SNI "bla.app.domain.tld" haben, aber im Host Header "localhost". Wenn man um ne teure Firewall herumkommen will, ist der Trick manchmal Gold wert.
TLDR: Mach die Terminierung bei nginx, das mag zwar weniger Sicher sein, aber funktioniert dafür immer & zuverlässig. Wenn du willst kannst du noch https zum Backend machen, mit gepinntem Zertifikat. Ist beim nginx dann zwar trotzdem Klartext, aber hey, wenn man den Kontrolliert, kann man sich auch ein LE Cert ausstellen lassen.
Alternativ, falls du reines IPv6 hast, könntest du auch einfach 2 unterschiedliche IPs nehmen, bei v6 bekommt man ja normalerweise mehr als genug davon.
Ich sehe, mein Vorhaben scheint nicht wirklich perfekt zu sein.
Hintergrund dafür ist, dass ich caprover laufen lassen möchte (oder eine ander PaaS opensource lösung).
CapRover https://caprover.com/ erstellt selbst neue domains und ssl zertifikate für neue applikationen. Daher wollte ich dies 1:1 forwarden.
Ich wüsste nicht, wie dies sonst zu handhaben wäre.
Die Idee mit der IP ist an sich nicht schlecht. Kostet aber wieder zusätzliches Geld...
Wie unterscheidest du denn, ob eine eingehende Verbindung nach A oder B
geht? Um an den Request ranzukommen (URL, Header, etc) muß SSL ja
erstmal terminiert werden.
SNI = Server Name Identification. Der Servername ist exakt deshalb die einzige Info, die unverschlüsselt auf die Reise geht. Anders könnte man nicht mehrere virtuelle Webserver unter einer IP-Adresse unterbringen.
SNI = Server Name Identification. Der Servername ist exakt deshalb die
einzige Info, die unverschlüsselt auf die Reise geht. Anders könnte man
nicht mehrere virtuelle Webserver unter einer IP-Adresse unterbringen.
Wie ich dich verstehe, sollte somit die Lösung mit einem SNI Proxy durchaus zuverlässig funktionieren?
Halte dich da eher an Daniel. Er hatte offenbar konkret daran gesessen. Ich habe mehr mit Webservern mit SNI zu tun, und mit Firewalls, die TLS nicht nur forwarden, sondern obendrein den Inhalt inspizieren.
Auch noch zu beachten ist, dass der SNI und der Host Header nicht immer
der selbe ist.
Bei Proxies hast du drei: CONNECT, Host, SNI :-/
prx schrieb:
Foobar schrieb:
Wie unterscheidest du denn, ob eine eingehende Verbindung nach A oder B
geht? Um an den Request ranzukommen (URL, Header, etc) muß SSL ja
erstmal terminiert werden.
SNI = Server Name Identification.
Das war halt die Frage.
C.H. schrieb:
Wie ich dich verstehe, sollte somit die Lösung mit einem SNI Proxy
durchaus zuverlässig funktionieren?
Du musst dir halt über eingehende Verbindungen ohne SNI (mein wget z.B. kanns noch nicht, generell ältere Clients, inkl Handys/Browser) Gedanken machen. Wenn die Clients z.B. alle bekannt sind und es unterstützen, kein Problem. Dann bräuchtest du allerdings auch kein Lets-Encrypt Zertifikat ...
Ich bin kein Fan von SNI, ein typischer Schnellschuß der Hoster ...
Hattest du es in letzter Zeit nicht so mit Updates?
Korrekt. Habe allerdings auch viele ältere Geräte im Einsatz, für die es keine Updates gibt.
droht man aber auch an der heute gängigen Forderung nach TLS ab 1.2 zu
scheitern.
Jo, ist eine Seuche geworden - selbst µC.net. Um das Problem an der Wurzel zu fassen, läuft auf meinem Router ein Proxy, der den HTTPS-Traffic aufbricht und auf moderne Ciphers umsetzt (inkl SNI).
Ich sehe, mein Vorhaben scheint nicht wirklich perfekt zu sein.
Hintergrund dafür ist, dass ich caprover laufen lassen möchte (oder eine
ander PaaS opensource lösung).
Was ist denn Deine Idee, und warum denkst Du daß Du eine Paas-Software dafür brauchst?
CapRover https://caprover.com/ erstellt selbst neue domains und ssl
zertifikate für neue applikationen. Daher wollte ich dies 1:1 forwarden.
Ich kenne Caprover nicht, aber es "erstellt neue Domains"? Was heißt das, registriert es die Domain?
Das mit den TLS-Certs können heute viele Lösungen, vom Reverse Proxy Traefik, über den Webserver Caddy, bis hin zu externer Software etwa für HAProxy, nginx oder Apache.
Habt ihr evtl. sonst noch eine Idee?
Klar: mit dem Reverse Proxy das TLS terminieren und dann den Upstream zum Server wieder verschlüsseln -- das kann mit einem selbstsignierten Zertifikat passieren, mußt Du dann halt beim nginx bekannt machen.
Aber der Möglichkeiten gibts viele, darum meine Frage, was Du am Ende wirklich erreichen möchtest.
Jo, ist eine Seuche geworden - selbst µC.net. Um das Problem an der
Wurzel zu fassen, läuft auf meinem Router ein Proxy, der den
HTTPS-Traffic aufbricht und auf moderne Ciphers umsetzt (inkl SNI).
