Hallo zusammen Ich habe folgendes Thema: 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. Meine Versuche bisher: https://i.stack.imgur.com/p3Rq8.png Haben leider nicht funktioniert. Firefox meldet dann: https://i.stack.imgur.com/5D8D0.png Auch kann ich keinen Stream erstellen: https://i.stack.imgur.com/r4M88.png Da dort nur der gesamte Traffic geroutete werden kann. Danke schonmal :)
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.
Vielen Dank für die Antworten 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... Habt ihr evtl. sonst noch eine Idee?
:
Bearbeitet durch User
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. 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.
:
Bearbeitet durch User
Daniel A. schrieb: > Bei ganz alten Browsern hängt er. Wer heute noch mit einem Browser im Internet unterwegs ist, der kein SNI beherrscht, den kann man ignorieren.
:
Bearbeitet durch User
(prx) A. K. schrieb: > 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?
C. H. schrieb: > Wie ich dich verstehe, sollte somit die Lösung mit einem SNI Proxy > durchaus zuverlässig funktionieren? Im Prinzip sollte das möglich sein, ich habe allerdings keinen parat.
(prx) A. K. schrieb: > C. H. schrieb: >> Wie ich dich verstehe, sollte somit die Lösung mit einem SNI Proxy >> durchaus zuverlässig funktionieren? > > Im Prinzip sollte das möglich sein, ich habe allerdings keinen parat. https://github.com/dlundquist/sniproxy Hier gibt es offenbar einen relativ aktuellen (basierend auf den letzten commit daten)
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.
:
Bearbeitet durch User
Daniel schrieb: > 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 ...
Foobar schrieb: > generell ältere Clients, inkl Handys/Browser) Mit derart ollen Geräten, mit denen man an fehlendem SNI scheitert, droht man aber auch an der heute gängigen Forderung nach TLS ab 1.2 zu scheitern. > mein wget z.B. kanns noch nicht Hattest du es in letzter Zeit nicht so mit Updates? Der wget kann es seit 2012. ;-)
:
Bearbeitet durch User
prx schrieb: > 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).
C. H. schrieb: > 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.
(prx) A. K. schrieb: > Daniel A. schrieb: >> Bei ganz alten Browsern hängt er. > > Wer heute noch mit einem Browser im Internet unterwegs ist, der kein SNI > beherrscht, den kann man ignorieren. Ignorieren, verhauen, auf eine einsame Insel ohne Telefon und Internet verbannen... YMMV. :)
Foobar schrieb: > 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). Moderne Chiphers wie ROT-13?
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.