Reverse-Proxy mit Standardlizenz

[Questi]

Hi,

wie ich gelesen habe ist man mit der Standardlizenz auf die 3cx domains limitiert, ist dies korrekt?
Ich bin nicht prinzipiell darauf angewiesen meine eigene Domain zu verwenden aber verwende zuhause einen reverse-proxy als auch eine firewall die beide das zertifikat benötigen würden.
3CX selber verwende ich innerhalb eines dockers auf einem RasPi4.

Am einfachsten wäre es natürlich, wenn ich meine 3CX Installation dazu bringen könnte komplett nur meine eigene domain zu verwenden, ansonsten müsste ich über ein script (meh, lieber nicht) das zertifikat regelmässig auf veränderung überprüfen und bei veränderung zum reverse-proxy und firewall kopieren...

Wie habt ihr das so gelöst?
Ich bin auch für alternative Lösungswege offen.
Reverse-Proxy hat bei mir zwei Gründe: 1.) Ich kann auf dem Provider-Route nur Weiterleitungen innerhalb des /24 erstellen, der 3cx "server" ist aber in einem anderem subnetz hinter einer firewall den der proxy erreichen kann. 2.) Ich habe nur eine öffentliche IP und nutze den SNI um den Traffic via Proxy zum richtigen Server zu leiten.
Der "dritte" Grund hängt mit der Firewall zusammen, ich habe dort mein Zertifikat hinterlegt um den Traffic aufzubrechen und auf "Angriffe/Schwachstellenausnutzung" etc. zu überprüfen.

Danke und Gruss,
Q

 

[fxbastler]

Hallo,

ansonsten müsste ich über ein script (meh, lieber nicht) das zertifikat regelmässig auf veränderung überprüfen und bei veränderung zum reverse-proxy und firewall kopieren.

1) Ja: wenn du eine 3X Standard benutzt dann wäre das der einzige Weg für dich.

nutze den SNI um den Traffic via Proxy zum richtigen Server zu leiten.

2) Bei SNI Nutzung im Reverse Proxy braucht es kein Zertifikat auf der Firewall wie in 1) beschrieben.

ich habe dort mein Zertifikat hinterlegt um den Traffic aufzubrechen und auf "Angriffe/Schwachstellenausnutzung" etc. zu überprüfen.

3) Das ist aber kein SNI am Reverse Proxy, das ist SSL Offload. Das wird mit der 3CX und HTTPS nicht funktionieren.

4) Warum wird der 3CX HTTPS Standard Port 5001 denn überhaupt geändert? Wenn der auf 5001 stehenbleibt sollte der Reverse Proxy (SNI hin, SSL Offload her) entbehrlich sein.

 

[Questi]

Hallo,


1) Ja: wenn du eine 3X Standard benutzt dann wäre das der einzige Weg für dich.


2) Bei SNI Nutzung im Reverse Proxy braucht es kein Zertifikat auf der Firewall wie in 1) beschrieben.

das zertifikat auf der firewall wird benötigt um den verkehr aufzubrechen und Threat Prevention zu ermöglichen.

3) Das ist aber kein SNI am Reverse Proxy, das ist SSL Offload. Das wird mit der 3CX und HTTPS nicht funktionieren.

was meinst du? Ich verstehe nicht ganz was du meinst.
Der Proxy benötigt doch das Zertifikat um nach aussen das selber Zertifikat zu präsentieren

4) Warum wird der 3CX HTTPS Standard Port 5001 denn überhaupt geändert? Wenn der auf 5001 stehenbleibt sollte der Reverse Proxy (SNI hin, SSL Offload her) entbehrlich sein.

Hierfür gibt es zwei Gründe, zum einem werden alle Ports bereits benötigt und zum anderem ist es gewollt den Traffic aufzubrechen und zu analysieren.

 

[fxbastler]

was meinst du? Ich verstehe nicht ganz was du meinst.

Reverse Proxy Nutzung mit SNI ist etwas anderes wie Reverse Proxy Nutzung und HTTPS Offloading.

SNI ist eine TLS Erweiterung und bedeutet i.d.R.: die an eine URL anfragende Software eines Client (z.B. ein Browser) muss die Fähigkeit haben beim Aufbau einer (evtl. später verschlüsselten) Verbindung die URL in einem Parameter zu Anfang (immer unverschlüsselt) mitzugeben. Damit sind MITM Geräte (wie z.B. ein Reverse Proxy) in der Lage zu erkennen, wohin der Datenstrom auf einem höheren OSI Layer wie 3 (oder evtl. 4, pures IP NAT wie es nur normale Router tun) zu routen ist. SNI ist ein Redirect und funktioniert ohne Aufbrechen der Verschlüsselung. Dazu braucht der Reverse Proxy kein Zertifikat. Der schaut in den unverschlüsselten Anfang vor dem Handshake und leitet entsprechend um, vorausgesetzt die anfragende Software des Client unterstützt SNI.

Unsere aktuelle Erfahrung ist: alle heilwegs aktuellen Apps / Konstrukte im 3CX Universum kommen mit einer Reverse Proxy SNI Umleitung klar. Das ist da vorhanden und funktioniert. Wir haben noch nicht alle Szenarien durchgespielt. Es kann sein bei Direkt STUN und einigen Telefonen funktioniert das nicht (auch Präsenzanzeige usw.). Das muss man halt von Fall zu Fall probieren.

Unsere aktuelle Erfahrung zeigt auch: SSL Offloading im Reverse Proxy für den HTTPS Port einer 3CX funktioniert nicht vollständig - noch nicht. Wir arbeiten dran, wenn es denn überhaupt geht. Das Thema ist bei uns noch nicht abgeschlossen.

Es wird halt nicht supported, aus gutem Grund.

Hierfür gibt es zwei Gründe, zum einem werden alle Ports bereits benötigt und zum anderem ist es gewollt den Traffic aufzubrechen und zu analysieren.

Verstehe ich, machen wir auch. Das geht halt bei uns i.d.R. nicht: parallel zu SNI auf der gleichen Port eine solche Reverse Proxy Weiterleitung mit SSL Offload. Entweder SNI oder SSL Offload pro Regel.

Ansonsten eine Firewall (oder ausschließlich einen Reverse Proxy) hinter die Firewall (mit dem ersten Reverse Proxy mit SNI) bauen da wo SSL Offload notwendig wird.

 

[Questi]

Hallo Bastler,

kann es sein, dass wir etwas aneinander vorbeireden?

Ich versuche mal mein Verständnis niederzuschreiben:

Reverse Proxy Nutzung mit SNI ist etwas anderes wie Reverse Proxy Nutzung und HTTPS Offloading.

Ich verstehe nicht ganz wie Du auf HTTPS/SSL Offloading kommst bei einem simplen reverse-proxy, ich glaube hier verstehe ich nicht was du versuchst zu sagen.

SNI ist eine TLS Erweiterung und bedeutet i.d.R.: die an eine URL anfragende Software eines Client (z.B. ein Browser) muss die Fähigkeit haben beim Aufbau einer (evtl. später verschlüsselten) Verbindung die URL in einem Parameter zu Anfang (immer unverschlüsselt) mitzugeben.

SNI muss nicht unverschlüsselt mitgegeben werden aber zum Glück ist es noch nicht sehr verbreitet den SNI in TLS1.3 zu verschlüsseln.

Damit sind MITM Geräte (wie z.B. ein Reverse Proxy) in der Lage zu erkennen, wohin der Datenstrom auf einem höheren OSI Layer wie 3 (oder evtl. 4, pures IP NAT wie es nur normale Router tun) zu routen ist.

MITM ist nicht das Wort, dass ich für einen Reverse-Proxy verwenden würde aber ja ich verstehe was du damit ausdrücken willst. Allerdings würde die "Erkennung" aufgrund eines höheren OSI-Layers (TLS Erweiterung würde ich höher als Layer 4 ansiedeln) geschehen. Routing wäre in dem Fall Layer 3.

SNI ist ein Redirect und funktioniert ohne Aufbrechen der Verschlüsselung. Dazu braucht der Reverse Proxy kein Zertifikat. Der schaut in den unverschlüsselten Anfang vor dem Handshake und leitet entsprechend um, vorausgesetzt die anfragende Software des Client unterstützt SNI.

SNI ist erst einmal nur eine TLS Erweiterung die ausgewertet werden kann, für den "Redirect" (bzw. die Funktion "Proxy" zu einem anderem Server) braucht ein Reverse Proxy meine Wissens nach aber ein Zertifikat.
Kennst du einen anderen Weg über den SNI eine reine Weiterleitung durchzuführen? Wenn ja wäre ich froh um eine genauere Erläuterung mit einem Beispiel.

Unsere aktuelle Erfahrung ist: alle heilwegs aktuellen Apps / Konstrukte im 3CX Universum kommen mit einer Reverse Proxy SNI Umleitung klar. Das ist da vorhanden und funktioniert. Wir haben noch nicht alle Szenarien durchgespielt. Es kann sein bei Direkt STUN und einigen Telefonen funktioniert das nicht (auch Präsenzanzeige usw.). Das muss man halt von Fall zu Fall probieren.

Unsere aktuelle Erfahrung zeigt auch: SSL Offloading im Reverse Proxy für den HTTPS Port einer 3CX funktioniert nicht vollständig - noch nicht. Wir arbeiten dran, wenn es denn überhaupt geht. Das Thema ist bei uns noch nicht abgeschlossen.

Es wird halt nicht supported, aus gutem Grund.

Ja, dass eine Anfrage wie meine mit einer kostenlosen privaten Lizenz nicht supported wird ist mir bewusst, daher habe ich es mal hier im Forum versucht.

Verstehe ich, machen wir auch. Das geht halt bei uns i.d.R. nicht: parallel zu SNI auf der gleichen Port eine solche Reverse Proxy Weiterleitung mit SSL Offload. Entweder SNI oder SSL Offload pro Regel.

Diesen Satz verstehe ich vermutlich am wenigsten, ich glaube wenn ich versuche darauf einzugehen driften wir zu weit vom Thema ab.

Ansonsten eine Firewall (oder ausschließlich einen Reverse Proxy) hinter die Firewall (mit dem ersten Reverse Proxy mit SNI) bauen da wo SSL Offload notwendig wird.

Eine Firewall hinter die Firewall, erste Proxy?
Ich weiss nicht was du meinst...
Es gibt aber derzeit "nur" eine Firewall und nur einen Reverse-Proxy.

Auf jeden Fall danke, dass Du dir die Zeit genommen hast zu antworten, bitte verstehe meine Antwort nicht falsch, ich will dir nicht auf die Füsse treten aber denke irgendwo sind noch Unterschiede im Verständnis einiger Sachen / Probleme.

Danke und Gruss
Q

 

[fxbastler]

Hallo,

aber denke irgendwo sind noch Unterschiede im Verständnis einiger Sachen / Probleme.

ja, so liest es sich

für den "Redirect" (bzw. die Funktion "Proxy" zu einem anderem Server) braucht ein Reverse Proxy meine Wissens nach aber ein Zertifikat.

nein

Kennst du einen anderen Weg über den SNI eine reine Weiterleitung durchzuführen?

ja, haproxy

Ich verstehe nicht ganz wie Du auf HTTPS/SSL Offloading kommst bei einem simplen reverse-proxy

Du schreibst vom Aufbrechen des HTTPS - simpel hin oder her, das ist offloading

Eine Firewall hinter die Firewall, erste Proxy?

Ja, das wäre imho die einzige Möglichkeit beides zu nutzen, geht halt erstmal nicht auf einer Maschine (ausser evtl. eine haproxy Instanz mit SNI an andere Ports eines squid auf dem gleichen Blech der dann das offloading - mit Zertifikat - umsetzt).