Seite 3 von 5

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Verfasst: So Dez 01, 2019 5:08 pm
von hominidae
aiole hat geschrieben: So Dez 01, 2019 4:44 pm Nochmal zum Verständnis:
* MQTT wird normal nur lokal von openWB genutzt
* statt VPN-Zugang ist alternativ der Datenaustausch mit Apps (nativ) und externen MQTT-Servern (per bridging) möglich
Nein, Apps - wenn sie im I-Net, zB auf dem Phone via 3G/4G - laufen müssen auch zur openWB verbinden.
Das ist kein Ersatz für VPN.
Über eine MQTT-Bridge kannst Du aber, ausgehen von der openWB zu einem anderen MQTT-Broker verbinden.
Wenn der im I-Net ist - und dafür brauchst Du eben keine Port-Weiterleitung, da die openWB-Seite client/ausgehende Verbidnung ist - kann die App (wenn sie MQTT spricht/ mqtt-client ist) direkt zu diesem MQTT-Broker im I-Net verbinden. Die Kopplung zur realen openWB läuft über die MQTT-Server Verbindung.
App ist sicher ein nettes Spielzeug, mehr aber auch nicht (für die meisten).
MQTT als VPN-Ersatz muss zwingend abgesichert werden, sonst war's das mit geschützten Daten.
=> Außer dass openWB ev. etwas schneller mit MQTT läuft, sehe ich, ehrlich gesagt, keinen Zugewinn an features.
Denke es ist nicht schneller, sondern eher Ressourcen-Spatender...
...und flexibler (statt synchrone Verbindungen sind es nun events/asynchrone Verbindungen).
Es ist für manche eine phylosophische Frage ;-)
ps
http-UI ist ok.
Es ist eine klare Sache, dass der user kein portforwarding nutzen darf und bei Remotecontrol von außen einen sicheren VPN zu installieren hat.
...das gilt ja auch für mqtt....am ende geht es auf dem Layer da auch um IPs und Ports.
Die technische Verbindung ist eigentlich ähnlich, nur das ebenen in der Anwendung statt get/put - requests die publish/subscribe events drüber wandern.

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Verfasst: So Dez 01, 2019 6:04 pm
von hominidae
truckl hat geschrieben: So Dez 01, 2019 4:12 pm Hier ist der neue GUI-Vorschlag:
[...]
...sieht von hier gut aus :)

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Verfasst: So Dez 01, 2019 6:14 pm
von truckl
KevinW hat geschrieben: So Dez 01, 2019 4:55 pm Finde ich soweit ganz gut, nur keine Beschränkung der Steuerung auf Ladepunkt 1 sondern direkt alle.
Ich hoffe ich verstehe Dich richtig: Du möchtest die LPs einzeln de-/aktivierbar? Ich eigentlich auch ;)
Ich werde versuchen mir ein sinnvolles Control zu "ergoogeln". Ich hätte da am liebsten eine Dropdown-Liste mit Checkboxen wo man die gewünschten LPs anhaken kann. Scheitert aber im Moment an meinen HTML-/Javascript-Fähigkeiten.
Notfalls halt lauter einzelne Checkboxen. Finde ich aber nicht wirklich hübsch :?
KevinW hat geschrieben: So Dez 01, 2019 4:55 pm Ebenso würde ich Verschlüsselung nicht abschaltbar machen.
Wer lokal arbeitet kann sich als client subscriben.
Guter Punkt! Hab ich gar nicht bedacht: Lokal direkt zu subscriben ist ja kein Problem. Da macht bridging wirklich kaum Sinn.
Stimme deshalb überein: "None" wird entfernt.

@KevinW: Ist eigentlich in näherer Zukunft ein Update auf Debian "Buster" angedacht? Ich Frage nur wegen dem TLSv1.3. Der Mosquitto von Stretch scheint ganz schön alt (1.4.10, aktuell ist 1.6.7) wie auch das OpenSSL (1.1.0l vs 1.1.1d). Daher wird TLSv1.3 schlichtweg nicht unterstützt.
Wenn kein zeitnahes Update geplant ist, würde ich den Menüpunkt erst mal ganz raus nehmen. Ansonsten eine OS-Erkennung einbauen und die TLSv1.3 abhängig von OS-Version wählbar machen oder deaktivieren.
Oder soll ich TLSv1.3 + OS-Versions-Erkennung grundsätzlich drin lassen (z.B. für "RASPIAN Selbst-Installierer" die schon Buster nutzen)?

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Verfasst: So Dez 01, 2019 7:40 pm
von openWB
Ich hoffe ich verstehe Dich richtig: Du möchtest die LPs einzeln de-/aktivierbar? Ich eigentlich auch ;)
Ich werde versuchen mir ein sinnvolles Control zu "ergoogeln". Ich hätte da am liebsten eine Dropdown-Liste mit Checkboxen wo man die gewünschten LPs anhaken kann. Scheitert aber im Moment an meinen HTML-/Javascript-Fähigkeiten.
Notfalls halt lauter einzelne Checkboxen. Finde ich aber nicht wirklich hübsch :?
Nein, eigentlich meine ich "alle steuern können oder keinen".
Ich würde das auch garnicht so fein graduieren.
Sprich lesend:
mit graph / ohne graph halte ich für vollkommen ausreichend.
Schreibend:
Ja / Nein
@KevinW: Ist eigentlich in näherer Zukunft ein Update auf Debian "Buster" angedacht? Ich Frage nur wegen dem TLSv1.3. Der Mosquitto von Stretch scheint ganz schön alt (1.4.10, aktuell ist 1.6.7) wie auch das OpenSSL (1.1.0l vs 1.1.1d). Daher wird TLSv1.3 schlichtweg nicht unterstützt.
Wenn kein zeitnahes Update geplant ist, würde ich den Menüpunkt erst mal ganz raus nehmen. Ansonsten eine OS-Erkennung einbauen und die TLSv1.3 abhängig von OS-Version wählbar machen oder deaktivieren.
Oder soll ich TLSv1.3 + OS-Versions-Erkennung grundsätzlich drin lassen (z.B. für "RASPIAN Selbst-Installierer" die schon Buster nutzen)?
Da stehen noch ein paar Baustellen an. Zudem läuft das noch nicht Bugfrei.
Davon ab hängt das ja auch von der Gegenstelle ab.

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Verfasst: So Dez 01, 2019 9:08 pm
von aiole
KevinW hat geschrieben: So Dez 01, 2019 4:55 pm
Mit einem Großteil der "bridge-inputs" müsste ich mich erstmal beschäftigen. Da bleibe ich lieber beim VPN und openWB/MQTT lokal.
Was meinst du mit Inputs?
Die Config-Eingaben zum MQTT-bridging
Bitte nicht falsch verstehen - Ihr schafft hier die (sinnvolle) OPTION zum Datenaustausch, aber damit sind ordentlich Risiken verbunden.
Wer supportet das eigentlich? Die bridge geht openWB m.E. schon gar nichts mehr an.
Die Schnittstelle nach außen ist mmn nach schon Baustelle von openWB. open heißt nicht nur von allen "Parteien / Komponenten" die Daten abfragen sondern diese eben auch zur Verfügung stellen.
Wenn das einmal implementiert ist, ist der Support Aufwand gering bzw. nicht vorhanden.
OK - macht Sinn
ps
http-UI ist ok.
Es ist eine klare Sache, dass der user kein portforwarding nutzen darf und bei Remotecontrol von außen einen sicheren VPN zu installieren hat.
Eben genau das überfordert viele Nutzer eben schon. Hier eine Alternative anzubieten macht schon Sinn.
Na dann.

Sorry für meine Unkenntnis, aber wie bei vielen usern auch, interessieren mich bestimmte Dinge NICHT.
Daher die DAU-Fragen:
Ein echter VPN bleibt davon unberührt?
Sprich, wer die bis dato weit verbreitete VPN-Lösung hat, arbeitet weiter mit lokalem MQTT/openWB und lässt jegliches bridging außen vor, korrekt?

VG

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Verfasst: So Dez 01, 2019 9:39 pm
von aiole
hominidae hat geschrieben: So Dez 01, 2019 5:08 pm
aiole hat geschrieben: So Dez 01, 2019 4:44 pm Nochmal zum Verständnis:
* MQTT wird normal nur lokal von openWB genutzt
* statt VPN-Zugang ist alternativ der Datenaustausch mit Apps (nativ) und externen MQTT-Servern (per bridging) möglich
Nein, Apps - wenn sie im I-Net, zB auf dem Phone via 3G/4G - laufen müssen auch zur openWB verbinden.
Das ist kein Ersatz für VPN.
Ja ok - da hatte ich nur die APP-Nutzung im HomeLAN gemeint.
Über eine MQTT-Bridge kannst Du aber, ausgehen von der openWB zu einem anderen MQTT-Broker verbinden.
Wenn der im I-Net ist - und dafür brauchst Du eben keine Port-Weiterleitung, da die openWB-Seite client/ausgehende Verbidnung ist - kann die App (wenn sie MQTT spricht/ mqtt-client ist) direkt zu diesem MQTT-Broker im I-Net verbinden. Die Kopplung zur realen openWB läuft über die MQTT-Server Verbindung.
Soweit habe ich das verstanden, aber
a) muss dieser externe MQTT eingerichtet werden (Welcher Normaluser hat einen womöglich noch extern gehosteten MQTT laufen? Dann muss das auch noch verschlüsselt werden. Da braucht man 'nen admin.) und
b) muss auch das bridging in der openWB vorgenommen werden.

a) + b) kommt mir (aus DAU-Sicht) vom Aufwand her keinesfalls einfacher vor, als ein VPN. Deshalb hinterfrage ich.
Dass MQTT eine bessere (sicherere) und moderne Kommunikation bei Nutzung von Verschlüsselung bietet, ist unstrittig (zumindest bis uns der Quantenrechner in die Suppe spuckt).
Aber ich vergleiche ext. MQTT mit einem sicheren VPN und nicht mit unsicherem Port-Forwarding. Prinzipiell bin ich bei Euch mit dem MQTT.

Jedoch insbesondere das Nutzen eines externen MQTT birgt für "Normalos" m.E. Risiken/Nachteile. Klar kann ich einen admin beauftragen, aber der kostet Geld - ggf. noch Jahresmiete für's hosten. Zum Schluss befindet man sich in einer neuen Abhängigkeit (ähnlich z.B. SMA beim Portal, auch wenn das dort anders geartet ist), weil irgend jemand ext. MQTT-support verkauft. Sowas stört mich, weil es kein MUSS ist.
App ist sicher ein nettes Spielzeug, mehr aber auch nicht (für die meisten).
MQTT als VPN-Ersatz muss zwingend abgesichert werden, sonst war's das mit geschützten Daten.
=> Außer dass openWB ev. etwas schneller mit MQTT läuft, sehe ich, ehrlich gesagt, keinen Zugewinn an features.
Denke es ist nicht schneller, sondern eher Ressourcen-Spatender...
...und flexibler (statt synchrone Verbindungen sind es nun events/asynchrone Verbindungen).
Es ist für manche eine phylosophische Frage ;-)
vermutlich

Ich kann Euch SW-chiefguides sowieso nur warnen - der Durchschnittsuser ist ein DAU, aber das ist für Euch eigentlich nichts neues. Dennoch will er/sie existierende features in openWB nutzen.

Kevin plant es m.E. schon richtig, diese Klientel nicht zu überfordern.
Das max. aus der Schnittstelle kitzeln ist auch verständlich, aber es muss abgeschottet werden. Z.B. extra Warnhinweis beim Aufruf der Bridge-Seite? - wie bei der Einstellseite -> Modulkonfiguration? + die roten Warnmarker in der Config-Seite.

Ich persönlich möchte keine Hilfe für einen ext. MQTT zukaufen, weil ich Unabhängigkeit liebe und es lokal auch ohne geht (und ein VPN den Zugang auch absichern kann).
ps
http-UI ist ok.
Es ist eine klare Sache, dass der user kein portforwarding nutzen darf und bei Remotecontrol von außen einen sicheren VPN zu installieren hat.
...das gilt ja auch für mqtt....am ende geht es auf dem Layer da auch um IPs und Ports.
Die technische Verbindung ist eigentlich ähnlich, nur das ebenen in der Anwendung statt get/put - requests die publish/subscribe events drüber wandern.
Ja - nur dass bei Portforwarding bei deutlich mehr Leuten die Alarmglocken angehen, während bridging bei Ungeübten schnell den Überblick verlieren lässt. Da nützen dann auch die roten Warnungen nur noch bedingt etwas - vor allem wenn die mehr als 1x in der Config beachtet werden müssen. In dieser Bridge-Config sehe ich das größte Risiko.

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Verfasst: Mo Dez 02, 2019 7:01 am
von truckl
aiole hat geschrieben: So Dez 01, 2019 9:39 pm Soweit habe ich das verstanden, aber
a) muss dieser externe MQTT eingerichtet werden (Welcher Normaluser hat einen womöglich noch extern gehosteten MQTT laufen? Dann muss das auch noch verschlüsselt werden. Da braucht man 'nen admin.) und
Nein. Zugang zu einem fertig und sicher konfigurierten MQTT-Server im Internet kann auch gemietet werden genau wie Speicherplatz auf Dropbox oder Google Drive. Da muß man ja auch keinen Server dafür konfigurieren oder einen Admin mieten der Dropbox betreibt.

Um Client-seitig Verschlüsselung zu Nutzen muß man übrigens nichts Konfigurieren. Auch nicht bei MQTT. Natürlich muß man konfigurieren daß verschlüsselt kommuniziert werden soll.
Vergleich: Mußtest Du bei Deinem Webbrowser etwas einstellen damit er "HTTPS" nutzen konnte? Aber in die URL-Zeile muß "https" anstatt "http" um dem Browser zu sagen daß er verschlüsseln soll.
aiole hat geschrieben: So Dez 01, 2019 9:39 pm a) + b) kommt mir (aus DAU-Sicht) vom Aufwand her keinesfalls einfacher vor, als ein VPN. Deshalb hinterfrage ich.
Also ich wage zu bezweifeln, daß das Einrichten eines VPN ins Heimnetz für IT-unkundige Nutzer einfacher ist als eine Dropbox zu nutzen (finde der Begriff "DAU" klingt zu böse).
Und vermutlich ist Dropbox auch sicherer. Sicherheit und Datenschutz sind zweierlei Dinge. Auf Datenschutz verzichten viel Normal-User aus Gründen des Comforts eher häufig (bitte ohne Wertung meinerseits zu verstehen). Auf Sicherheit (der IT-Systeme) sollte aber niemals jemand verzichten. Gerade im IoT-Umfeld ist das leider oft anders - siehe die vielen Beispiele für Botnetze aus gehackten IoT-Devices.
aiole hat geschrieben: So Dez 01, 2019 9:39 pm Ja - nur dass bei Portforwarding bei deutlich mehr Leuten die Alarmglocken angehen, während bridging bei Ungeübten schnell den Überblick verlieren lässt. Da nützen dann auch die roten Warnungen nur noch bedingt etwas - vor allem wenn die mehr als 1x in der Config beachtet werden müssen. In dieser Bridge-Config sehe ich das größte Risiko.
Bei wievielen Otto-Normal-Nutzern gehen diese "Alarmglocken" an wenn sie Dropbox & Co verwenden?
Die Konfigurieren sich auch kein VPN zu ihrem NAS sondern Nutzen im besten Fall die Cloud des NAS-Anbieters, o.ä.

Ich meine: Datenschutz ist Sache des Nutzers. Mann kann höchsten vor "schlechten" Dingen warnen. Systemsicherheit ist Sache des Herstellers (hier openWB). Und die Systemsicherheit sehe ich durch die Möglichkeit von MQTT-Bridges im Client-Mode nicht gefährdet.
KevinW hat geschrieben: So Dez 01, 2019 7:40 pm Nein, eigentlich meine ich "alle steuern können oder keinen".
Ich würde das auch garnicht so fein graduieren.
Ah. OK. Verstanden. Ich fände aber den feiner graduierten Ansatz schon schön. Daten die nicht raus gehen verursachen auch keinen Traffic und Systemlast (auch wenn diese super gering sind).
Ich könnte allerdings auch mit der Einfach-Lösung leben.
@KevinW: Magst Du ein "finales Machtwort" sprechen: Wäre es für Dich OK wenn ich es doch fein granular lasse? Oder ist die "Einfach-Lösung" ein muß?
KevinW hat geschrieben: So Dez 01, 2019 7:40 pm Da stehen noch ein paar Baustellen an. Zudem läuft das noch nicht Bugfrei.
Davon ab hängt das ja auch von der Gegenstelle ab.
OK. Ich glaub dann de-/aktiviere ich es vom OS-abhängig. Zeige es aber immer an.
Mir wäre hier übrigens auch lieber man müßte das gar nicht einstellen.
Leider erfordert die Technik hinter Mosquitto sich im Voraus auf die konkrete TLS-Version festzulegen. Ein "Auto" (sprich Handshake mit Aushandlung der Protokollversion wie bei HTTPS) läßt sich offenbar für den "bridge_tls_version" Parameter nicht einstellen.
Der Nutzer ist also leider gewzungen sich diese Information bei seinem MQTT-Server-Betreiber zu holen und hier passend einzustellen. Sonst kommt schlimmstenfalls keine Verbindung zu stande.

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Verfasst: Mo Dez 02, 2019 8:56 am
von aiole
Moin,
ich denke, dass diese Diskussion die Gefahren, die bei externer MQTT-Nutzung herrschen, sehr schön aufzeigt hat.

Du schreibst:
truckl hat geschrieben: Mo Dez 02, 2019 7:01 am ...Zugang zu einem fertig und sicher konfigurierten MQTT-Server im Internet kann auch gemietet werden genau wie Speicherplatz auf Dropbox oder Google Drive. Da muß man ja auch keinen Server dafür konfigurieren oder einen Admin mieten der Dropbox betreibt.
.....
Bei wievielen Otto-Normal-Nutzern gehen diese "Alarmglocken" an wenn sie Dropbox & Co verwenden?
Die Konfigurieren sich auch kein VPN zu ihrem NAS sondern Nutzen im besten Fall die Cloud des NAS-Anbieters, o.ä.
....
Das openWB-Merkmal "guter Datenschutz", welches durch eine rein lokale Nutzung gegeben ist, kann also mittels externem MQTT leicht ausgehebelt werden, wenn man nicht sorgfältig arbeitet und/oder unsichere Komponenten in der Kette hat.
Hinzu kommen ggf. Kosten für ext. MQTT-Server, die der Nutzer zu bezahlen hat. Damit begibt er/sie sich zudem in Abhängigkeiten. Das ist alles kein Problem - die Nutzer müssen nur vorher wissen, was sie tun.

Nur das wollte ich durch entsprechende Warnhinweise (bei externer MQTT-Nutzung) + Optionen der Vermeidung (nur Lokalnutzung) sauber für die Nutzer dargestellt wissen.

VG aiole

ps
Danke für die Geduld

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Verfasst: Mo Dez 02, 2019 9:02 am
von openWB
Sind ja nur Checkboxen mehr. Vor allem reden wir hier wirklich nur über initiales senden der 0 Werte.
In Anbetracht das sich da ggf. mal Dienste hinter befinden kann man sich da dann eine Prüfung auf "Wenn nicht vorhanden dann = 0" sparen.
Schöner wäre wenn die 0 für ChargePointConfigured gleich mitkommt.
Spart dir auch Arbeit ;)

@aiole
Es zwingt ja keiner jemanden das zu nutzen.
Die Gefahr ist aber bedeutend geringer wie bei HTTP PortForwarding oder einem schlechten VPN, schlicht weil schon bedeutend weniger Daten zur Verfügung stehen. Die wirklich kritischen gleich garnicht.

Re: howto: openWB über anderen mosquitto MQTT Broker vernetzen (MQTT Bridge)

Verfasst: Mo Dez 02, 2019 9:13 am
von aiole
KevinW hat geschrieben: Mo Dez 02, 2019 9:02 am @aiole
Es zwingt ja keiner jemanden das zu nutzen.
Die Gefahr ist aber bedeutend geringer wie bei HTTP PortForwarding oder einem schlechten VPN, schlicht weil schon bedeutend weniger Daten zur Verfügung stehen. Die wirklich kritischen gleich garnicht.
Alles gut. Mir war nur die klare Abgrenzung lokal vs. ext. MQTT mit Warnungen wichtig.
Letzteres kann man übrigens mit einer guten Anleitung (+ ein paar Hintergründen, warum was verwendet wird) auch nutzerfreundlich gestalten. Damit sollten sichere MQTT-configs (f. extern Kommunikation) möglich werden.
VG aiole