TLS-Zertifikat Sicherheit und Weiterleitung

[plopp79]

Hallo Zusammen,

ich bin neu in diesem Forum und habe ein Frage zum Thema Netzwerktechnik.

Ich habe folgende Situation:

• Ich habe einen Homeserver, der über meinem Router mit dem Internet verbunden ist.
• Auf dem Homeserver (Proxmox) habe ich einen Proxy Reverse Server(lxc container) eingerichtet, der dann intern an verschiedene Server (ebenfalls container z.b. Nextcloud) weiterleitet.
• Eine Subdomain - z.B. sub.myexample.com - leitet Anfragen über CNAME auf eine myfritz-Adresse weiter. (z.B. mYEXampLe4.myfritz.net)
• Von dort mittels AAAA-Record - auf den Fritzbox Router, der dann ja über Portforwarding die Anfragen an den ReverseProxy Server weiterleitet.

Wenn ich auf dem Reverseproxy nun ein SSL-Zertifikat erstelle - in meinem Beispiel mit Debian und Certbot mit dem Befehl certbot certonly -d sub.myexample.com - ist dann der gesamte Kommunikationsweg verschlüsselt?
Also vom Browseraufruf von sub.myexample.com über myfritz-Adresse bis hin zu meinem Reverse-Proxy-Server?

Der Aufruf der Subdomain im Browser zeigt ja ein gültiges Zertifikat an, Oder könnte z.B. zwischen der Weiterleitung von der Subdomain zur myfritz-Adresse unverschlüsselt gelauscht werden?

Ich konnte dazu leider keine verbindliche Aussage bisher finden...

 

[Barungar]

Ja, die Kommunikation ist dann fast komplett verschlüsselt. In Deinem konkreten Fall endet die Verschlüsselung aber am Reverse Proxy, und das letzte Stück der Verbindung ist entweder unverschlüsselt oder läuft über ein internes Zertifikat. Das kann ich ohne die genau Konfiguration zu kennen nicht sagen. Dieses letzte Stück befindet sich allerdings im "internen, virtuellen Netzwerk" des Proxmox; die Wahrscheinlichkeit, dass diese Kommunikation "angegriffen" wird ist ziemlich gering, dann müsste der Angreifer schon die Kontrolle über das interne, virtuelle Netz haben.

Grundsätzlich wirfst Du hier einfach drei unterschiedliche Themen in einen Topf.

1. Namensauflösung
2. Routing / Weiterleitung
3. TCP-Verbindung

Die Verschlüsselung gilt nur für Punkt 3, und die wird "Punkt zu Punkt" zwischen dem Client und dem Server aufgebaut. Beim "Aufbau" der Verbindung kommt zwar Punkt 1 ins Spiel und während der Verbindung kontinuierlich auch Punkt 2; aber aus Sicht von Punkt 2 ist das wie mit der Post. Die leitet auch Briefe weiter ohne das sie den Inhalt kennt.

Zur Namensauflösung zählen die Domänen und Subdomänen, sowie die CNAME-, A- und AAAA-Records im DNS. Die haben erst einmal gar nichts mit der eigentlichen Verbindung zu tun. Das ist eher wie ein Adreßbuch und dem "Namen an der Haustür". Das Zertifikat wird auf den FQDN (den "Namen an der Haustür") ausgestellt, weil dies die Information ist, die in URLs codiert ist und an Hand der ein Browser prüft, ob er den "korrekten" Partner gegenüber hat.

Das Routing / Weiterleiten durch die FritzBox bis zum Reverse Proxy ist, wie oben bereits erwähnt, durch die Verschlüsselung "geschützt". Bis eben zum letzten Stück Reverse Proxy zu eigentlichem virtuellen Server.

 

[plopp79]

wao, sehr cool, vielen Dank für die schnelle und sehr ausführliche Antwort.

Darf ich hier vielleicht noch eine Frage stellen, die tatsächlich auch mit diesem Thema zusammenhängt. Ich fühle mich hier gut beraten Ich bin nämlich auf dieses Thema gestoßen, als ich mir einen neuen Proxy-reverse-Server aufsetzten wollte.

Vielleicht muss ich noch ein bisschen weiter ausholen, um die Ursache für mein Problem zu finden.

Der proxy-reverse-Server leitet über einen virtuellen Host sub.myexample.com auf einen Nextcloud-Server, (tatsächlich unverschlüsselt. Ich dachte, wenn schon jemand diesen Abschnitt abhören kann, dann habe ich bereits ganz andere Probleme ).

Bisher hat das mehrere Jahre so funktioniert. VH auf dem Proxy mit certbot ein Zertifikat für sub.myexample.com erstellt (config könnte ich bei bedarf posten, ich kenne mich leider nicht gut genug damit aus, um einschätzen zu können was ich mit welchen Sicherheiten posten kann bzw. sollte)

Jetzt musste/wollte ich dem Nextcloudserver ein Update verpassen und musste auch dafür einen neue Version von PHP (nämlich von PHP7.4 auf PHP8.1, PHP7 wird ja auch nichtmehr gepflegt im nächsten Jahr) installieren. Dabei gab es dann auch die Empfehlung fastcgi zu nutzen. Nextcloud ist auf Apache2 aufgesetzt. (keine Ahnung, ob das alles damit zusammenhängt).

Für die Weiterleitung von fastcgi benötige ich anscheinend auch php-fpm (laut Internet) auf dem Proxy. Da der alte Proxy noch auf Ubuntu 18.04 aufgestzt war, habe ich mich entschlossen einen neuen Container mit Debian 11 zu erstellen, habe nginx mit extra repo version 1.24, sowie auch hier php8.1 installiert... (8.2 ist wohl noch nicht ausgereift und laut ChatGPT nicht unbedingt kompatibel zu 8.1)

Die Ports (80 und 443) habe ich dann auf beiden Routern (fritz.box und dann Unify) auf den neuen Proxy-reverse-Server geleitet, eine schlichte sub.myexample.com.config Datei erstellt und certbot mit 'certbot certonly -d sub.myexample.com' mir ein Zertifikat erstellt. Das hat alles (ohne Fehlermeldung) funktioniert. Zum Testen habe ich in /var/www/html/bsp eine index.html mit dem Inhalt 'HIER' erstellt.
in der config habe ich dann auch 'root /var/www/html/bsp' gespeichert.
Wenn ich die Port-Weiterleitung von 80 auf 443 herausnehme, gelange ich auf die standard nginx-Seite.... Welcome to nginx (oderso ähnlich). wenn ich 443 aufrufe - wie gesagt, ich leite noch nicht an einen anderen Server weiter, nur auf das bsp Verzeichnis mit der index.html - dann kommt "Diese Seite kann nicht gefunden werden."

Es ist, als wenn der virtuelle Host nicht funktioniert, aber erst einmal, warum kommt die Anfrage auf port 80 zumindest am Server an und auf 443 nicht? Die Ports sind freigeschaltet und werden auch durchgeouret, sonst hätte ja auch certbot nicht funktioniert. Firewall ist auf dem Reverse-Proxy erst einmal noch nicht aktiviert. Kann das ggf. mit dem Zertifikat zusammenhängen?

hier noch eine Info mit telnet

╭─root@ReverseProxy in /etc/nginx/sites-available
╰$ telnet sub.myexample.com 80
Trying 22.34.34.22...
Connected to mYEXampLe4.myfritz.net.
Escape character is '^]',
Connection closed by foreign host.

und

╭─root@ReverseProxy in /etc/nginx/sites-available
╰$ telnet sub.myexample.com 443
Trying 22.34.34.22...
Trying 8e00:8e00:8e00:8e00:8e00:8e00:8e00:8e00...
telnet: Unable to connect to remote host: Network is unreachable

<Daten alle geändert>


Wäre schön, wenn ich hier eine Lösung für das Problem finden würde, im moment hänge ich dadurch ein wenig in der Luft...
Je nachdem in welche Richtung die Lösungsfindung geht, kann ich natürlich auch noch weitere
Informationen zukommen lassen.

 

[Barungar]

Ich bin nicht so tief in NGINX drin, aber sind es aus Sicht der Konfigurations-Logik von NGINX nicht zwei komplett getrennte "virtuelle Webserver"? Du hast einmal den Server der Port 80 bedient mit seiner Konfiguration und Du hast den Server der Port 443 bedient, ebenfalls mit seiner eigenen Konfiguration.

 

[blurrrr]

Wenn ich auf dem Reverseproxy nun ein SSL-Zertifikat erstelle - in meinem Beispiel mit Debian und Certbot mit dem Befehl certbot certonly -d sub.myexample.com - ist dann der gesamte Kommunikationsweg verschlüsselt?
Also vom Browseraufruf von sub.myexample.com über myfritz-Adresse bis hin zu meinem Reverse-Proxy-Server?

Ja, das sieht dann stark vereinfacht so aus:

<Client>---HTTPS---<Reverse-Proxy>---HTTP/S---<Webserver>

SSL zwischen RP und WS ist dann optional. Die meisten machen sich die Mühe für "interne" Kommunikation eher nicht.

sind es aus Sicht der Konfigurations-Logik von NGINX nicht zwei komplett getrennte "virtuelle Webserver"?

Korrekt, normalerweise geht man auf Port 80 lediglich hin und erzeugt eine Umleitung (redirect) auf Port 443, so die unverschlüsselte Verbindung über Port 80 zwar als Einstiegspunkt genutzt werden kann ((http://)www.example.com), der Webserver diese Anfrage entgegen nimmt und dann sofort an Port 443 verweist ((https://)www.example.com). Das könnte dann z.B. so aussehen:

server {
    listen 80;
    server_name example.com www.example.com;
    return 301 https://www.example.com$request_uri;
}

server {
    listen 443 ssl http2;
    server_name www.example.com;
    .......
}

Die "return"-Zeile wäre dann der Umleitungsteil... Schau einfach mal hier rein: https://www.nginx.com/blog/creating-nginx-rewrite-rules/

 

[plopp79]

Das ist beides in einer config-Datei aber ja, man kann und sollte auch die unterschiedlich konfigurieren(ähnlich wie bei apache2)....

...ich habe mithilfe von chatGPT die Ursache herausbekommen. Anscheinend befindet sich nun standardmäßig die aktivierten VHs nichtmehr unter /etc/nginx/sites-enabled/ sonden unter /etc/nginx/conf.d. Dadurch hatte er auch nun immer die standard-default Einstellung beibehalten, egal was ich unter den config-Dateien bei mir gemacht hatte ....

Also entweder die *.conf Dateien unter conf.d verlinken oder in der /etc/nginx/nginx.conf die Zeile 'include /etc/nginx/conf.d/*.conf' in 'include /etc/nginx/sites-enabled/*.conf ändern. ... Problem gelöst

Übrigens, wen es interessiert, chatGPT (oder besser Bing unter Skype) wollte mir partout nicht glauben, dass bei meiner Konstellation der oder die Browser ein gültiges Zertifikat anzeigen. Laut der AI müssen nach jeder Verbindung bzw. Weiterleitung ein gültiges SSL-Zertifikat erstellt werden, um die Verschlüsselung auf dem gesamten Weg zu erhalten. Also auf der Subdomain, auf der myfritz Domain und auf dem Server. ...sollte man halt doch noch nicht alles glauben

...vielen Dank für Unterstützung und den Informationen

 

[plopp79]

SSL zwischen RP und WS ist dann optional. Die meisten machen sich die Mühe für "interne" Kommunikation eher nicht.

Ja, das ist auch glaube ich nicht ganz trivial, ich kann für die Interne Kommunikation lediglich ein eigenes, nicht geprüftes Zertifikat ausstellen, oder muss evtl. am proxy reverse Server lediglich durchrouten und das Zertifikat am Server erstellen?!? oder evtl. sogar das gleiche Zertifikat an beiden stellen integrieren?!?

Ansonsten kann er kein eigenes 'geprüftes' Zertifikat mit z.B. certbot erstellen oder updaten, wenn schon einer devor sitzt, das verhindert Port 80 durchzurouten.

Ich finde die eigenen nicht geprüften Zertifikate auch für einen Homeserver murks. Da muss man dann jedesmal im Browser bestätigen, dass man wirklich auf die Seite möchte.... immer diese Bevormundung von den Programmen , wann hört das endlich auf.

"Kein Schutz" ist für mich auch keine Alternative und die Zertifikate einzeln in den jeweiligen Browsern zu integrieren, hat bei mir nicht funktioniert und wäre mir auch viel zu aufwendig.

Wenn jemand eine Lösung kennt wie man das umgeht, daran wäre ich interessiert.

 

[blurrrr]

ich kann für die Interne Kommunikation lediglich ein eigenes, nicht geprüftes Zertifikat ausstellen, oder muss evtl. am proxy reverse Server lediglich durchrouten und das Zertifikat am Server erstellen?!?

Das wäre sowohl als auch möglich, das gleiche Zertifikat an beiden Stellen macht allerdings eher weniger Sinn.

Ich finde die eigenen nicht geprüften Zertifikate auch für einen Homeserver murks. Da muss man dann jedesmal im Browser bestätigen, dass man wirklich auf die Seite möchte.... immer diese Bevormundung von den Programmen , wann hört das endlich auf.

Kannst das Zertifikat auch einfach importieren und jut ist, oder Du legst Dir einfach selbst eine interne CA an und stellst damit Zertifikate aus, dann musst Du nur dem CA-Zertifikat vertrauen.

Also ich sag mal so... "je nach Konstrukt" halt, aber ich kann sehr gut mit den selfsigned Zertifikaten leben, denn ich meld mich auch nicht 5x am Tag an den Systemen an (und ich bin beruflich mit der IT verbandelt). Für alles, wo man tagtäglich ran muss (ggf. auch von aussen) kann man das einfach wunderbar über einen Reverse-Proxy laufen lassen, dort findet die SSL-Terminierung statt (z.B. mit LE-Zertifikaten) und alles dahinter arbeitet entweder mit selfsigned Zertifikaten oder ohne (je nach Umgebung).

 

[plopp79]

Kannst das Zertifikat auch einfach importieren und jut ist, oder Du legst Dir einfach selbst eine interne CA an und stellst damit Zertifikate aus, dann musst Du nur dem CA-Zertifikat vertrauen.

Das Zertifikat in den Browser zu importieren, hat nicht funktioniert und eine eigene interne CA anzulegen, erschien mir bisher noch zu aufwendig...

so wichtig ist mir das jetzt auch nicht, aber es nervt mich schon, wenn alle paar Tage die Nachfrage kommt, wenn ich z.B. Proxmox oder NodeRed aufrufen möchte... Bei diesen Diensten möchte ich ja möglichst kein Zugriff nach draußen haben(außer mit VPN), weshalb ich dann kein gültiges Zertifikat erhalten kann.

Eine Frage fällt mir dazu noch ein... Wenn ich meinen Nextcloud Server dann in meinem Netzwerk (also intern) über die offizielle externe Adresse sub.myexample.com aufrufe, kann es sein, dass er dann gar nicht die Verbindung über den Umweg der Subdomain -> myfritz -> proxy, sondern lediglich direkt intern den proxy reverse Server aufruft und von dort direkt auf den Server geleitet wird?

Bei mir wird nämlich kein Traffic nach "draußen" angezeigt und ich habe schnellere Download bzw. Upload Raten als ich normalerweise haben sollte (DSL-Vertrag).
Ich habe ja evtl. dadurch meine Frage schon selbst beantwortet, ich kann mir das nur nicht vorstellen, da ich explizit keine Einstellungen dahingehend unternommen habe und ich mir auch nicht sicher bin warum das so ist und ob es auch stets der Fall ist oder ob das eher willkürlich - mal so mal so - funktioniert...? Ich hatte mal versucht, dass über einen eigenen DNS Server hinzubekommen(also von intern, dann den kurzen Weg), habe dann aber dabei festgestellt, dass ich das evtl. garnichtmehr benötige, da dass sowieso schon so funktioniert...

 

[blurrrr]

nach "draußen"

Würde genau "was" bedeuten? Kleiner Tip: Der Router weiss schon über die IPs seiner Interfaces Bescheid, ansonsten würde die ganze Nummer nicht funktionieren - also kein Grund, irgendwas "raus" zu befördern (was der nächste Hop nach dem Router aus LAN-Sicht wäre)

 

[plopp79]

ja genau, mit "draußen" meinte ich das Internet und demnach mit "drinnen" dann das Intranet - also aus Internet-Sicht, alles was hinter dem Router sitzt ist drinnen und alles was im Internet ist, bzw. im Internet erreichbar ist, ist "draußen" (keine Ahnung ob ich mich hier richtig Ausdrücke, ich hoffe es geht aus meinen Aussagen hervor, was ich damit meine )

Das der Router über die IPs bescheid weiß, ist mir schon klar ...
Allerdings kennt der Router ja nicht die Konfigurationen vom Proxy, oder die Einstellung der CNAME-Records der Sub-Domain an die ich die Anfrage im Browser richte... das meinte ich ja damit, ich rufe Nextcloud über die sub.myexample.com auf und eben nicht über die interne IP vom Server oder vom Proxy. Trotzdem scheint es, dass der Datenaustausch nicht über die Sub-Domain geleitet wird, sondern direkt vom Router an den Proxy.

...oder bekommt der Router ggf. mit, dass die Anfrage, die er an die Subdomain leitet auch kurze Zeit später wieder erhält oder erhalten würde und deshalb direkt mit dem Proxy kommuniziert? Ich finde den Effekt ja super, so sollte es sein. Ich sehe auch keinen Grund darin etwas 'raus" zu befördern Ich kann mir das eben nur nicht erklären warum das so ist, dazu fehlt mir leider das Hintergrundwissen.
Und das war meine Frage, ob mir das jemand erklären kann.

 

[Barungar]

Allerdings kennt der Router ja nicht die Konfigurationen vom Proxy, oder die Einstellung der CNAME-Records der Sub-Domain an die ich die Anfrage im Browser richte... das meinte ich ja damit, ich rufe Nextcloud über die sub.myexample.com auf und eben nicht über die interne IP vom Server oder vom Proxy. Trotzdem scheint es, dass der Datenaustausch nicht über die Sub-Domain geleitet wird, sondern direkt vom Router an den Proxy.

Der Router muss auch weder die Domänen noch den CNAME kennen, weil beides für den Datentransport (und das ist die Aufgabe des Routers) vollkommen ohne Belang sind. Die Domäne wird nur für die "unflexiblen Menschen" gebraucht, die sich einfach die IP-Adressen nicht merken können. Die Domäne wird also ursprünglich ausschließlich dafür verwendet, einen "Alias" also einen hübschen Namen für eine IP zu haben. Diese "Aliasse" werden in einem großen Adreßbuch geführt (das DNS-System).

Wenn Du eine Domäne ansprichst, geht Dein Client hin und fragt das DNS: "Wer ist sub.example.com?" Und erhält die Antwort: "sub.example.com ist ein CNAME von secret.example.com und hat A 198.51.100.200 (und AAAA 2001:db8::200)!"

Ab diesem Moment ist die Domäne für den Datenverkehr vollkommen egal. Seitdem TLS-SNI in Mode ist kommt, später nach dem TCP-Handshake, noch der TLS-SNI-Handshake, wo auch die Domäne in Verbindung mit dem Zertifikat nochmal von interesse ist; aber das liegt weit oberhalb des Datentransports und ist für den Router total egal.

In dem Moment, wo die Datenpakete also Deinen Router passieren sind es auf den "Adressaufklebern" (Zielen) IP-Adressen und keine Domänen mehr.

 

[plopp79]

Ah ja ok, das klingt auch logisch. Ich hatte das auch schon mal gehört, dass technisch nur die IPs verwendet werden, konnte das nur nicht in diesem Zusammenhang erkennen....

Demnach ist der Router dann auch gleich in dem Moment seine eigene Zieladresse. Er versucht also die Anfrage rauszusenden, hat aber sich selber als Ziel, und leitet die Anfrage nur noch über Portforwarding durch.

Vielen Dank

 

[blurrrr]

dass technisch nur die IPs verwendet werden, konnte das nur nicht in diesem Zusammenhang erkennen....

Zunächst schaut der Client wohin die Reise gehen soll (DNS), danach folgt das Routing (IP) und am Ziel wird eben nochmal auf den angesprochenen FQDN geschaut, um den richtigen virtellen Host zu ermitteln (SNI).

Demnach ist der Router dann auch gleich in dem Moment seine eigene Zieladresse.

Da würde noch ein weiteres Thema auf Dich zukommen, aber das hast Du ja anscheinend schon ggf. nach der offiziellen Anleitung von AVM gelöst

 

[plopp79]

Alles Klar, vielen Dank Euch beiden, für die ausführlichen Erklärungen.
Sorry nochmal, wenn ich mit meiner Unwissenheit zu den Themen mit meinen Aussagen für Verwirrungen gesorgt haben sollte.
Für mich sind damit die Fragen aber zu diesem Thema beantwortet.