Willkommen im Loxone Community Forum. Um alle Funktionen nutzen und sehen zu können, registriere dich bitte zuerst. Dies gilt auch für das herunterladen von Dateien.
Dieser Bereich ist für fertige Lösungen gedacht. Nutze bitte für Diskussionen die anderen Bereiche.
HOWTO: Miniserver per HTTPS erreichbar machen (Apache Reverse Proxy)
Äh... nein, die Verschlüsselung (TLS/SSL) ist doch das gleiche Prinzip.
Wir sind hier sowieso schon gut OT, es ging ja nur um die o.g. Nachfrage, Doku + Miniserver + SSL, nur kurz:
Der Unterschied zwischen TLS/SSL und STARTTLS ist, daß bei TLS/SSL zuerst eine sichere TLS/SSL Verbindung aufgebaut wird und darüber dann normales SMTP/IMAP/POP3 gesprochen wird.
Bei STARTTLS wird eine ungesicherte SMTP/IMAP/POP3 Verbindung aufgebaut, und darüber sagt der Client, er möchte jetzt TLS/SSL sprechen und dann wird hier der sichere Kanal aufgebaut.
Also den schwierigen Part der Verschlüsselung per/für TLS/SSL hat Loxone sauber gelöst, nur bei den restlichen 3 Prozent ''wir halten uns an den Protokollablauf'' hat Loxone dann einfach aufgehört und verweigert bewußt seit 1,5 Jahren die Fehlerbehebung.
Was für eine renitente Verschwendung von Programmierarbeit! :-(
Und damit es ja keine blöden Nachfragen gibt, lassen sie auch noch die Doku auf den Stand von vor 2 Jahren...
VPN oder HTTPS wurde ja schon mehrmals diskutiert, dazu gibt es mittlerweile auch mehrere Wiki-Einträge. Es dürfte klar sein, dass HTTPS alleine keinen ausreichenden Schutz bietet. Ich kann auch verstehen, dass Loxone SSL nicht in den Miniserver implementiert (wobei sie es für Mail ja gemacht haben). Der Miniserver ist nunmal eine SPS und kein Server im eigentlichen Sinne.
ABER: Es wäre ein Einfaches für Loxone die Javascripte so anzupassen, das keine absoluten URLs mehr verwendet werden und man damit einen HTTPS-Proxy verwenden könnte.
Hallo alle zusammen!
Ich ärgere mich über Loxone das sie die Scripte nicht anpassen. Würde es ebenfalls über einen reverseproxy mit ssl offloading und gültigem ssl zertifikat durchführen (mich nerven die browser warnungen - und noch viel blöder: ohne verifizierbarem zertifikat kann oft eine seite nicht geöffnet werden wenn die firewall streng ist - denn ich kann mit der lösung von überall drauf).
Zur immer wieder kehrenden diskussion und den falschaussagen das ein zugriff über https - also ssl offloading und reverse proxy nicht sicher genug ist:
Reiner blödsinn! Bevor man etwas schreibt sollte man sich auskennen, und nicht vermutungen anstellen.... Ich habe zb meine Firewall(was auch gleichzeit der "router" ist) von aussen über https erreichbar, und dabei noch ein lächerliches passwort vergeben beim admin user. Nur drinnen war noch niemand ausser mir - es gab nichtmal den versuch das passwort zu probieren.
Allerdings muss ich hierbei sagen das der zugriff auf die seite nur mit einem gültigen Client Zertifikat möglich ist - dh heisst hat man keines landet man beim zugriff auf die adresse ohne antwort und timeout im nirvana. Der reverseproxy lässt jemanden der ohne client zertifikat welches dieser gegen ein ca (Certificate authoritie) verifiziert nicht durch - dies ist GENAUSO sicher wie eine vpn.
Der praktikable unterschied liegt aber darin das ich auf dem computer von welchem aus ich zugreifen will nur das clientzertifikat in den browser importieren muss(und nachher wieder entferne wenn notwendig). Das clientzertifikat habe ich immer mit, oder übers netz verfügbar wenn benötigt. - dh. Es fällt eine installation von vpn weg - was oft schwierigkeiten mit sich bringt(domainrechte usw.). Das clientzertifikt selbst liegt natürlich in einem pkcs container welcher ebenfalls verschlüsselt ist.
Also bitte keine unwissentlichen Meinungen mehr das es ist nicht sicher, und nur ein vpn ist sicher. Diese Meinungen tragen nämlich dazu bei das es loxone nicht umsetzten wird...
Allerdings kann dies der 0815 user nicht umsetzen. Aber die Feststellung ist eben falsch.
wen es interessiert - ich verwende den haproxy mit layer 7 auflösung. - sicherer gehts kaum.
Werde nochmals bei loxone anfragen das sie es ändern.
Das Loxone kein ssl integriert verstehe ich voll und ganz - schaut euch mal die Leistungsdaten vom miniserver an(die paar watt unter volllastung!) - die hardware ist voll optimiert auf das eigentliche und wenig Energieverbrauch!(schaut wie oft das komplette programm in der sekunde durchläuft!).
Würden die jetzt SSL implementieren nur um https zu ermöglichen dann viel spaß. Stellt euch vor da greifen dann 20 personen gleichzeitig über https auf den miniserver zu(kann es durchaus geben für sales zwecke), und der miniserver läuft sowieso mit dem programm am limit - da geht die kiste in die Knie und die Stimmen werden laut welch ein Mist das nich ist. Wer jetzt meint Loxone hätte doch eine stärkere Hardware nehmen sollen (was schon einige Leute taten) dann gibt es auf der anderen seite wieder die Leute welche meinen "Der mist braucht maximal 15 watt? So ein schrams!". Wichtiger ist allerdings für Loxone natürlcih der geringe Energieverbrauch des Miniservers denn die Konkurenz schläft nicht, und die "Grünen" und "Grünen Vereinigungen" unter uns auch nicht welche eine Firma wegen deren Geräte mit zu hohem Energieverbrauch anprangern und so etwas breit publik machen.
Weiten wir das Ganze jetzt auf alle die gesamte hardware und Busteilnehmer von Loxone aus: da ein paar watt mehr, dort ein paar watt mehr(weil sich immer leute irgendwelche komischen features wünschen). Pötzlich braucht dein kompletter Loxoneaufbau mit zig teilnehmern statt 15 watt gesamt aber 70 watt. gefällt euch das? - immer denken bevor man redet.
Interessant. Gibt's hierzu irgendwo ein HowTo? Wäre es damit möglich ein Client Zertifikat für iOS / Android zu erzeugen und somit ohne einen VPN aufbauen zu müssen direkt (verschlüsselt) auf den Miniserver zuzugreifen? Der WAF (Android) würde erheblich steigen und ich kann mir perspektivisch den Kauf eines iPhones sparen. :-D
In welchem browser du das client zertifikat verwendest ist unerheblich (können warscheinlich alle) - ich hab meines im chroome am android.
Hier ein howto zu schreiben währe wahsinn. Einen haproxy kann man auf diversen geräten einrichten. Könnte auch ein raspberry sein - aber dann wären zumindest 2vlans notwendig. Das sollte aber dann parallel zu firewall(in einem gerät) das erste nach deiner anbindung ans internet sein. Da es bereits tiefer in die netzwerk materie geht würde ich davon abraten.
Die etwas einfachere möglichkeit ist ein router welcher openvpn kann: diesen einrichten und ein tun device erstellen und zwingend den ganzen verkehr über den vpn routen wegen der sicherheit. Es gibt für android genügend kostenlose openvpn clienten. Dann würdest du auf deinen miniserver mit dem browser am handy direkt auf den webserver am miniserver per ip zugreifen. Hostname geht bei dieser tunnelart nicht da den keiner(dns) auflösen kann. Bei einem tap device(bezeichnung der tunnel art von openvpn- ist kein hardware device!) allerdings, und richtiger konfiguration, können auch von deinem dns am router deine internen hostnamen aufgelöst werden.
Aber bevor du irgendetwas kaufst erkundige dich bei jemanden vom fach - es gibt diverse faktoren welche berücksichtig werden müssen, dazu gehört auch dein provider. Anleitungen für router mit openvpn einrichten gibt es genug im internet.
Habe aktuell ein OpenVPN laufen (Debian auf ESXi). Die Authentifizierung erfolgt über Zertifikate welche auf den Endgeräten (Android /iOS) liegen. Nervig ist nur, dass der VPN - im Falle von Android - vorab manuell aufgebaut werden muss (via OpenVPN Connect) und erst dann die Lox App genutzt werden kann. Bei iOS könnte man das mit VPN-on-Demand lösen. Bei Android wohl nur mit Tasker, wobei das mir schon wieder zu viel gefrickel wäre.
Der Router gibt leider nicht all zu viel her (Telekom Hybrid). Port-Weiterleitung ist schon das höchste der Gefühle. VLANs kann der Switch.
Ich bin nicht fernab vom Fach, aber bei weitem kein Netzwerker. :-)
Hatte gehofft eine einfache Variante zu finden, aber dann bleibt vorerst nur der Weg über VPN. Echt schade das Loxone in der heutigen Zeit kein HTTPS implementiert.
Servus,
Naja eine einfache(re) Möglichkeit gibt es noch - den Loxbery auf den du den zb den port 443 (default https port) weiterleitest. Dieser über einen minimal konfigurierten apache server als reverseproxy den miniserver über https zugänglich macht. Dabei steht aber wieder das Problem im raum das die seite des miniservers zwar verschlüsselt, aber theoretisch von jedem erreicht werden kann. Die Gefahr ist dann selber einzuschätzen. Ein gutes Passwort beim Miniserver ist auf jedefall empfohlen. Ob der Apach Client Authentifizierung mittels Zertifikat kann müsstest du nachsehen. Link:
Original HOWTO von Emil Brunner: http://forum.loxone.com/showthread.p...4319#post54319 (http://forum.loxone.com/showthread.php?t=6604&p=54319#post54319) Wer
oder hier im Forum. Der Loxberry ist ein Raspberry Pi mit der System Loxberry genannt. Funktioniert aber nur wenn du auf das alte Design umschaltest.
Ich verwende zb. die Firewall pfSense und auf diesem HaProxy mit Layer 7 auflösung. Da ich mehrere Seiten Privat hoste auf einer IP, und ich mit dem HaProxy anhand der Host adresse zb "loxone.meinedomain.at" bestimme an welche IP oder Hostname intern weiter gerootet wird.
Der HaProxy kann authentifizierung mit Zertifikat.
Was ich demnächst probieren werde ist mit dem HaProxy ein Workaround zu bauen für die neuere Loxone Oberfläche. Es müsste möglich sein über https zu gehen ohne Dateien vom Miniserver dazwischen zu speichern indem man mit dem haproxy in jedem packet das benötigte umschreibt was gesendet wird - in beide Richtungen. Wenn ich erfolg habe werde ich hier in diesem Forum berichten.
Wenn jemand eine gute Firewall benötigt würde ich pfSense oder OPNsense empfehlen - hab mir viel angesehen - ist im moment das beste in sachen integration der diversen Pakete und bedienbarkeit. Würde natürlich den Router ersetzten den man hat.
Ich teste aktuell stunnel (www.stunnel.org), das auch mit Client-Zertifikaten arbeiten kann. Leider gibt es auch hier aktuell einen Bug, der nur von Loxone gelöst werden kann: Bei der Türsteuerung denkt der Miniserver, man wäre lokal verbunden, da man sich über 127.0.0.1 zu stunnel verbinden muss und er nimmt dann die interne IP für den Stream, was nicht funktioniert, da stunnel diese nicht tunnelt bzw. nur über localhost tunneln kann. Auch wenn der Loxone-Support das Thema durchaus mit einem diskutiert, so glaub ich nicht, dass es dafür eine Lösung von Loxone geben wird. Einzige Lösung wäre hier nur, auch intern im eigenen WLAN über stunnel zu gehen. Aber wegen den anderen Fehlern aktuell nicht praktikabel.
Denn auf dem Handy die Verbindung immer wieder ab und man muss manuell die stunnel Verbindung stoppen/starten. Ob das an Loxone oder stunnel liegt, kann ich nicht beurteilen.
Auf dem PC funktioniert es aber einwandfrei und es läuft einfach im Hintergrund und es geht auch nicht der komplette nicht-Loxone Datenverkehr über diese schmale Leitung (Upload vom eigenen DSL Anschluss ist dann nicht mehr so entscheidend).
Vorab worauf lässt du die jeweiligen Server laufen? Bei mir läuft alles am "Router" also pfSense - pfSense habe ich umgesiedelt auf ein APU2C4 Einplatinenmcomputer --> Leitung für Private zwecke und den paar spielerein ausreichend. Bei interesse schreib einfach.
Da ich sauviel auf dem HaProxy eingerichtet habe kann ich dir eine Lösung sagen die funktioniert - hatte es damals mit stunnel nicht hinbekommen weil der, wenn ich mich richtig erinnere kein SNI(Server Name Indication) mitsendet - was aber beim HaProxy für die auflösung auf TCP ebene benötigt wird um die SSH Pakete intern an den richtigen SSH Server weiterzuleiten(in meinem Fall der PfSense SSH selber).
Hätte da eine Lösung für dich:
Diese Lösung verwende ich am Handy oder Computer von Aussen wo ich nur diesen einen Port haben will und damit kein unnötiger Verkehr über die Verbindung geht (Verwende sonst OpenVPN TUN/TAP oder eben HTTPS mit Offloading).
Du benötigst dafür allerdings eben den HaProxy - mit NGINX sollte es auch funktionieren?
Es funktioniert folgendermaßen:
Das Handy baut einen SSL Tunnel zum pfSense auf - pfSense wiederum weiß anhand der ACL und des SNI vom SSL Tunnel wohin die Verbindung weiterg gerootet wird. - wird zum SSH Server gerootet welcher im pfSense läuft, also 127.0.0.1:22(weil der HaProxy läuft ja im selben system wie der ssh server). Der HaProxy macht SSL Offloading und beendet somit den SSL Tunnel bevor zum SSH Server weitergerootet wird - zum öffnen des SSL Tunnels ist auch ein Client cert notwendig.
Durch den somit geöffneten SSL Tunnel wird jetzt ein SSH Tunnel geöffnet welcher ebenfalls verschlüsselt ist :-) und auf den SSH Server auf dem pfSense gerootet wird. Der SSH tunnel selbst bleibt einfach offen bis man die shell beendet.
durch den ssh Befehl "-L localhost:2001:LOXONEMINISERVERhostnameOderIP:80" wird der SSH Tunnel am Localhost:2001 gebunden, und der SSH Server schickt dich auf LOXONEMINISERVERhostnameOderIP:80 - somit kannst du am handy auf dem port 2001 den miniserver erreichen und alles funktioniert(habs getestet). man könnte den port auf auf am localhost auch auf 80 binden - aber dann muss das android gerootet sein.
Das ganze ist aber leichter gesagt als getan - es ist unter anderem noch der ssh befehl Proxycommand mitdabei welcher den openssl startet und der wiederum openssl "s_client" mit -nextprotoneg verwendet.
die ganze "Wurst" zum verbinden ist eeeewig lange. ABER (setzten wir kein passwort beim SSL cert und SSH cert voraus) das aufbauen der Verbinfung dauert dann nicht länger als 1 sekunde
Die Performance ist für die meisten zwecke ausreichend - komme bei samba dabei auf ca 220kBps(KiloByte pro Sekunde) was beschränkt ist durch die leistung des pfSense rechners.
PS:eine weiteren Vorteil gibt es an der Sache: da die ausgehende Verbindung, also der SSL Tunnel, auf zb ssh.meinzuhause.at:443 verbindet, wird das ganze durch die meisten firewalls als "normale" ssl verbindung interpretiert, dh. die würde glauben du schaust dir eine https seite an(man kann es filtern anhand komplizierter regeln). Somit kommst du nahezu durch jede Firewall nach aussen - also nach hause - und kannst dir über den SHH über SLL Tunnel diverseste andere prtololle laufen lassen ohne das es wer mitbekommt.(hab sogar zum probieren über den SSH/SSL Tunnel einen OpenVPN Tunnel aufgebaut - ging auch). Was in dem SSL Tunnel steck kann bereits nicht mehr erörtert werden - nur was hald so öffentlich in den diversen Layers im OSI modell von jedem Paket steht.
stunnel lass ich auf einem Raspberry Pi laufen. Verwende hier ebenfalls ein letsencrypt Zertifikat.
Wenn ich dich richtig verstehe bei deinem Alternativ Vorschlag müsste es ähnlich stunnel funktionieren, d.h. das Problem mit der Türsteuerung hätte ich immer noch. Oder machst du für die Türsteuerung dann noch einen weiteren Port im SSH Tunnel auf?. Welche Apps unter Android verwendest du für den SSH Tunnel? Und für die Batterie ist der offene Tunnel kein Problem? Würde es nicht auch reichen nur den SSH tunnel aufzumachen und dort drin alles unverschlüsselt zu senden?
Am meisten wurmt mich eben das loxone die scripts nicht anpasst - das ist lächerlich. Denn würde es einfach mit ssl offloading funktionieren wäre es echt super.
Da ich seit anfang an im pfSense gratis ssl zertifikate für jede "virtuelle" subdomain von letsencrypt beziehen kann(mitlerweile gibt es dazu sogar ein plugin im pfSense "ACME" - da wirds richtig leicht), würde ich wie gesagt überall auf den miniserver kommen da keine blöde meldung kommt "die seite ist nicht sicher blablabla"(und die seite wegen Firewall Richtlinien in Firmen dann eventuell komplett gesperrt wird) - weil auch meine https adresse vom miniserver offiziell verifiziert werden kann. Hab zwar dann noch das client cert für die https verbindung welches benötigt wird, aber das kann ich über ein sh script am pfSense dank einer pfSense api in 1 sekunde über das handy vorübergehend ausschalten(über den ssh über ssl tunnel) und dannach wieder aktivieren.
"virtuelle" subdomain? - da der dns server welcher meine private ip auflöst jedem subdomain an meine ip weiterleitet - egal ob diese als offizielle subdomain eingetragen ist oder nicht, kommt die verbindung bei mir an. Da ich die subdomains die ich verwende nirgens eingetragen habe (was wegen dem haproxy nicht notwendig ist), kennt diese auch niemand - was natürlich vorteilhaft ist. Zb meinzuhause.at ist eingetragen aber miniserver.auth.meinzuhause.at nicht - wird aber trotzdem auf meine ip gerootet wegen meinzuhause.at
Sofern alles richtig eingerichtet reisst die verbindung vom ssh über sll tunnel nie ab, hatte diese zum testen über 10h am handy offen ohne damit etwas zu tun - und benötigt kaum datenvolumen -war nahezu nichts in der zeit.
mit einer guten firewall gibt es keine grenzen ^^
ps: wenn es genug leute gibt die interesse haben sich soetwas zu bauen dann schreibe ich villeicht ein howto.
mfg
Nachdem ich mich jetzt fast einen Tag lang damit rumgeärgert habe, Loxone 9.0.1 über einen Apache als Reverse Proxy mit https erreichbar zu machen, schreib ich mal zusammen wie es bei mir jetzt endlich vernünftig zu laufen gebracht hab.
# optional: provide some valid certificates to get rid of browser warnings
SSLCertificateFile /root/.certstore/loxone.lan.crt
SSLCertificateKeyFile /root/.certstore/loxone.lan.key
# important: required as loxone sometimes seems to encode the slashes in encrypted commands
AllowEncodedSlashes on
</VirtualHost>
Grundsätzlich war meine Idee einen name-based virtual host einzurichten. Das ganze aber nur fürs interne LAN.
Ich hab mir dann auch eine eigene private root ca (wie hier https://deliciousbrains.com/ssl-cert...s-development/ beschrieben) erstellt und in meinem Browser importiert (dadurch wirds auch als 'sichere' Seite im Browser angezeigt). Wenn man eine 'richtigen' Domain verwendet kann man sich natürlich auch von einer der verbreiteten CAs ein Zertifikat signieren lassen..
Die ProxyPass /ws/ ws://192.168.1.1/ws/ Zeile ist alles das notwendig ist für die Websockets. Es ist hier soweit ich gesehen hab kein runterladen und modifizieren von javascript files mehr notwendig wie in http://www.loxwiki.eu/pages/viewpage...pageId=6980307 beschrieben. Loxone dürfte die Fallunterscheidung für https mittlerweile in ihre Skripts übernommen haben. (Das Einfügen von /miniserver in den Pfad ist ja sowieso nicht notwendig weil ich eben einen name-based virtual host verwende)
Und ganz am Schluss steht das was mich 99% der Zeit gekostet hat. Beim propietären encoden der Commands (das Loxone laut Doku als 'Ersatz' für richtiges https implementiert hat) wird in den Loxone Skripts teilweise ein urlencode des Base64 Strings durchgeführt. Da Base64 Strings Slashes enthalten können werden natürlich auch die Slashes encoded. Standardmässig akzeptiert aber Apache _keine_ URLs die kodierte Pfadtrennzeichen enthalten und schmeisst in diesem Fall _immer_ einen HTTP 404 - Not Found. Diese URLs werden ohne die 'AllowEncodedSlashes on' also auch gar nicht an die Loxone weitergeleitet sondern direkt am Apache verworfen. Was mich noch immer ein bisschen verwirrt ist, dass Loxone das urlencode scheinbar nur bei commands die über /jdev/sys/enc/ geschickt werden macht, nicht aber bei commands über /jdev/sys/fenc/ (die funktionieren auch ohne die AllowEncodedSlashes Direktive..)
Hallo
Ich habe ein Synology NAS (DS214se mit DSM 6.1.4). Ich benutze auch den Reverse Proxy aus dem Paketzentrum. Funktioniert problemlos, aber eben nicht mit Websockets. Kann mir jemand sagen wie ich dort die benötigten Websockets aktiviere?
Danke Volker
Das habe ich mich auch schon gefragt. Die Loxone App wird wahrscheinlich nur eine HTTP-Verbindung aufbauen. Mein eben eingerichteter Proxy leitet alles was auf HTTP ankommt auf HTTPS um. Ob die App das mitmacht weiß ich nicht, da es noch an einer anderen stelle klemmt.
Wenn ich mich anmelde, läd das Webinterface die Scripte 12 bis 12 und wartet dann "Connection Waiting". Mehr passiert nicht.
Schade das mit der App. Meine Tests mit dem NetScaler (u.a. Reverse Proxy) waren leider für die App auch nicht erfolgreich, da die https nicht versteht.
Kann wer von euch das bitte mal in https://www.loxwiki.eu/pages/viewpag...pageId=6980307 updaten? Dort steht eine andere Lösung, die nur mit der Classic Oberfläche geht. Als Netzwerk-Dummy sehe ich mich dazu nicht in der Lage...
Ich habe ein Synology NAS DS918+ im Einsatz.
Habe hier Reverse Proxy im Einsatz --> (findet man dort in der Standardoberlfäche unter "Systemsteuerung", "Anwendungsportal", "Reverse Proxy"
Das HTTPS Zertifikat kommt von Let's Encrypt. Das wird von auf dem Synology NAS auch ständig kostenlos erneuert.
Dies findet Ihr in dem Synology NAS unter "Systemsteuerung", Sicherheit", "Zertifikat"
Läuft wie geschnitten Brot - bringt aber halt alles nix für die Loxone iPhone APP. Denn wenn ich den Server eingebe: "https://loxone.deinedomain.com" findet er den Server nicht.
Per Web läuft es aber.
Der Webzugriff ist über diese Lösung wirklich perfekt - immer ein aktuelles und gültiges und kostenloses Zertifikat - ohne Fehlermeldung im Browser und perfekt verschlüsselt.
Wenn das Zertifikat ausläuft kümmert sich das NAS automatisch darum, dass es verlängert wird und stellt dies zur Verfügung. Besser geht es nicht!
Natürlich geht das aber auch alles über Linux und einen Raspberry Pi.
NGINX ist hier das Stichwort - das verwendet auch Synology im Hintergrund.
Eusebius - gerne - Habe Deine Anleitung überprüft. Da fehlt noch die Port 80 Freigabe aussen nach innen auf die Synology. Laut meiner Erfahrung geht sonst die Zertifikatausstellung nicht - oder?
Hallo logol01, Eusebius und Comunity, habe vor einigen Wochen exakt den vor kurzem in der Loxwiki ergänzten Beitrag bzgl. der Anbindung über https mittels Synology inkl. reverse proxy eigenhändig umgesetzt und war ratlos warum es im Browser geht und in der App nicht... jetzt hab ihr hier Licht ins Dunkeln gebracht...
Zufällig einen Workaround... habt ihr für das Problem nicht geschaffen? Wäre zu schön wenn der MS über https durch die APP ansprechbar wäre...
Was sehr schade ist und auch sicher nicht ewig so bleiben kann (da "unsichere" Apps in diversen App-Stores nicht mehr akzeptiert werden dürfen). Dass Loxone meint, dass ein proprietäres Datenformat "sicher" genug wäre reicht garantiert nicht. Zuerst aber werden sie den Miniserver aktualisieren oder extra eine Reverse-Proxy-Hardware (die man vor den Miniserver hängt & hoffentlich auch Client-Zertifikate versteht) zum Verkauf anbieten... d.h. das wird noch Jahre dauern...
logol01Eusebius vielleicht wird man das ganze aber denoch früher oder später umgehen können. Einige Tests haben bei mir ein paar Verständnisschwierigkeiten ausgelöst... wie in dem Tut beschrieben stelle ich eine Verbindung mittels https://loxone.meinedomain.de:443 direkt über den Port 443 zum 443 Port der Synology her wodurch der Reverse Proxy angesprochen wird und dann intern die weiterleitung durchführt zum Miniserver über http://miniserverip:80... geht nicht oder halt nur über den brwoser wie bei euch eben auch.
Wenn ich aber zum testen den Fritzbox eingen DYNDNS dienst myFritz mal aktiviere, dann hab ich folgendes Szenario. Über die https://xyz.myfritz.de:42422 komme ich verschlüsselt auf die fritzboxoberfläche (standardmäßig). Nun leite ich den Port weiter auf den internen Miniserver über dessen Port 80 und gelange somit auf den Miniserver von außen... das Szenario was sich jetzt ergibt ist: Wenn ich https://xyz.myfritz.de:42422 in den Broswer eingeben komme ich direkt auf die LoxVisu, so wie beabsichtigt. Ist diese Verbindung https? oder http? gesichert oder ungesichert? Denn in diesem Fall funktioniert es eben auch mit der APP auf dem Handy...
Ich bin jetzt davon ausgegangen, dass es gesichert sein muss, weil ic hden Port 80 direkt ja nicht freigebe, sondern eine gesicherte Anfrage auf den Port 80 weiterleite... falls ich falsch liege bitte ich um Aufklärung!
Dachte bloß wenn ich mit https 443 oder eben 42422 über die myfritz adresse rein gehe wäre es ja verschlüsselt. Zumal die Fritzbox ebenfalls sich dafür extra bei Letsencrypt ein Zertifikat zieht...
Wir verarbeiten personenbezogene Daten über Nutzer unserer Website mithilfe von Cookies und anderen Technologien, um unsere Dienste bereitzustellen, Werbung zu personalisieren und Websiteaktivitäten zu analysieren. Wir können bestimmte Informationen über unsere Nutzer mit unseren Werbe- und Analysepartnern teilen. Weitere Einzelheiten finden Sie in unserer Datenschutzrichtlinie.
Wenn Sie unten auf "Einverstanden" klicken, stimmen Sie unserer Datenschutzrichtlinie und unseren Datenverarbeitungs- und Cookie-Praktiken wie dort beschrieben zu. Sie erkennen außerdem an, dass dieses Forum möglicherweise außerhalb Ihres Landes gehostet wird und Sie der Erhebung, Speicherung und Verarbeitung Ihrer Daten in dem Land, in dem dieses Forum gehostet wird, zustimmen.
Tweet
Kommentar