openWB Forum

Der Sinn ist das es nicht möglich ist an einen öffentlichen unverschlüsselten Broker seine Daten senden zu können.

Zertifikat hinterlegbar machen kann ich gern mit auf die Agenda nehmen.

Es hat nicht jeder seinen MQTT Broker im Internet stehen, sondern lokal im LAN. Und die meisten IoT-Geräte können nicht mal TLS via MQTT, weswegen dann gar kein Bedarf eines zusätzlichen TLS-Listeners besteht.
Ich finde das schon ein wenig eine Bevormundung.

Mir ist's jetzt egal, jetzt wissen wir ja, warum's nicht geht.

Und die meisten IoT-Geräte können nicht mal TLS via MQTT,

Moment, der Lokale Broker ist unverschlüsselt.
Es geht nur darum Brücken nach extern zu konfigurierender UI.

Davon ab kann lokal die Brücke auch von dem gegenbroker initiiert werden

christiantf hat geschrieben: ↑Fr Okt 23, 2020 5:21 pm Ist die MQTT-Schnittstelle immer noch so?
Man könnte das so bauen, dass man es verwenden kann: Entweder TLS abschaltbar, oder TLS fertig konfigurierbar.

Ich versteh nicht, warum da einerseits unverschlüsselt verhindert wird, anderseits aber TLS nicht fertig konfigurierbar ist.

Wie openWBSupport schon geschrieben hat: Es ist, zum Schutz von unbedarften UI-Nutzern absichtlich nicht möglich die Brücke im UI ohne TLS zu konfigurieren.
Die Funktion ist zur Anbindung im öffentlichen Internet befindlicher MQTT-Server entstanden. Und diese haben, spätestens seit LetsEncrypt, in aller Regel ein offizielles gültiges Zertifikat das vom Raspbian der openWB ohne Weiteres akzeptiert wird.

BennyK hat geschrieben: ↑Fr Okt 23, 2020 5:58 pm Die Brücke braucht man im internen Netz dann auch nicht? Wie kriege ich denn Werte aus der openWB in Richtung lokales MQTT Gateway? (Wobei das klappt auch mit der alten API), wichtiger wäre es EVU Leistung + PV schreiben zu können.

Zum Beispiel indem Du direkt am MQTT-Server der openWB subscribst und published.
Alternativ: Die Brücke in Deinem lokalen MQTT-Gateway (ich nehme an das ist auch ein normaler MQTT-Server) konfigurieren. Wenn keine Firewalls im Spiel sind ist es doch völlig gleichgültig "wie herum" die Brücke konfiguriert wird.

christiantf hat geschrieben: ↑Fr Okt 23, 2020 6:01 pm Und was ist die Absicht?
Ich weiß nur, dass ich (als Entwickler einer anderen Software) zwei Tage Support geleistet habe, weil das OpenWB-MQTT-Interface nicht so konfigurierbar ist, dass es funktioniert (ohne TLS nicht, mit TLS nicht).

Zwei Tage Support um herauszufinden, daß es im MQTT-Bridge-Nutzer-Interface der openWB weder eine Möglichkeit gibt TLS abzuschalten noch ein Zertifikat zu hinterlegen?
Du hast also selbst keine openWB (oder auch nur einem RASPI ohne echte Ladehardware) wo Du das auf einen Blick gesehen oder vorab mal getestet hättest? Bietest aber dafür Support für Kunden Deiner Software an? Das muß ich jetzt nicht verstehen, oder?

christiantf hat geschrieben: ↑Fr Okt 23, 2020 6:01 pm Bei meiner webkonfigurierbaren Software achte ich darauf, dass ich die Funktionen, die ich anbieten will, übers UI auch konfigurieren kann. Bei der openWB-Einrichtung geht aber weder das eine (unverschlüsselt) noch das andere (TLS-Zertifikat hinterlegbar).

Die bisherigen Use-Cases für die Funktion sind oben beschrieben. Mag sein daß Du einen neuen hast. Ich sehe daher folgende Möglichkeiten wie Du weiter kommst:

1. Du erweiterst das MQTT-UI der openWB um die nötige Funktionalität. Du schreibst, Du bist selbst SW-Entwickler und die openWB ist Open Source. Meine Erfahrung ist, daß Pull-Requests jederzeit willkommen sind.
2. Du schreibst auf Seite Deiner Software ein User-Interface oder sonstige Funktion um die Brücke in die "andere Richtung" zu konfigurieren.
3. Du subscribst und published aus Deiner Software direkt am MQTT-Server der openWB.
4. Du findest einen Entwickler der die Erweiterung zum Hochladen eines Client- und/oder CA-Zertifikates für Dich ins openWB-UI einbaut. Natürlich ist damit zu rechnen, daß dafür ein entsprechender Obolus fällig wird.

Du hast die Wahl ...

Was aber eher kontraproduktiv sein dürfte ist, wenn Du nur hier im Forum nur über die bisher implementierte Funktion (die gar nicht für Deinen Use-Case gedacht war) herumlamentierst.

truckl hat geschrieben: ↑Fr Okt 23, 2020 7:40 pm Du hast also selbst keine openWB (oder auch nur einem RASPI ohne echte Ladehardware) wo Du das auf einen Blick gesehen oder vorab mal getestet hättest? Bietest aber dafür Support für Kunden Deiner Software an? Das muß ich jetzt nicht verstehen, oder?

Wie ich geschrieben habe, ich hab kein openWB. Aber ich helfe nunmal dabei, dass User Ihre Devices und Software per MQTT an mein Gateway mit Broker anbinden kann (so macht ihr das bestimmt auch, wenn jemand openWB mit irgendwas verbinden will).

truckl hat geschrieben: ↑Fr Okt 23, 2020 7:40 pm Die bisherigen Use-Cases für die Funktion sind oben beschrieben. Mag sein daß Du einen neuen hast. Ich sehe daher folgende Möglichkeiten wie Du weiter kommst:

1. Du erweiterst das MQTT-UI der openWB um die nötige Funktionalität. Du schreibst, Du bist selbst SW-Entwickler und die openWB ist Open Source. Meine Erfahrung ist, daß Pull-Requests jederzeit willkommen sind.
2. Du schreibst auf Seite Deiner Software ein User-Interface oder sonstige Funktion um die Brücke in die "andere Richtung" zu konfigurieren.
3. Du subscribst und published aus Deiner Software direkt am MQTT-Server der openWB.
4. Du findest einen Entwickler der die Erweiterung zum Hochladen eines Client- und/oder CA-Zertifikates für Dich ins openWB-UI einbaut. Natürlich ist damit zu rechnen, daß dafür ein entsprechender Obolus fällig wird.

Gut, dann wäre jedenfalls ein neuer Use-Case, dass das MQTT-Bridging von openWB unverschlüsselt zu einem anderen lokalen MQTT-Broker verbinden kann. Da der openWB-Broker selbst nicht TLS verwendet, wäre es ja legitim, dass openWB auch kein TLS zu einem anderen Broker erzwingt.
Man kann große rote Texte platzieren, dass eine unverschlüsselte Verbindung zu einem Internet-Broker gefährlich ist.

Erweitern der openWB-Funktionalität: Ich dränge mich in der Regel nicht in eine Software hinein, die ich nicht mal installiert habe, und programmiere irgendwas um. Es wären - wie ich gesehen habe - ca. fünf Zeilen Code, um "Unverschlüsselt" ins UI einzubauen und die Config entsprechend zu schreiben.
Bridge zu openWB: Hab ich, aber ausschließlich TLS-PSK Meins kann man aber auf beiden Seiten im UI einrichten
Du subscribst und published aus Deiner Software direkt am MQTT-Server der openWB: Das kann ich bereits, aber ich wusste nicht, dass openWB einen eigenen Broker hat (ist im Screenshot des MQTT-GUIs, den ich kenne, nicht ersichtlich). Da mein Gateway normalerweise den eigenen Mosquitto mitliefert, und das UI von openWB nach einer Client-Verbindung zu einem Broker aussah, war dem Benutzer und mir diese Möglichkeit nicht bewusst.
Du findest einen Entwickler der die Erweiterung zum Hochladen eines Client- und/oder CA-Zertifikates für Dich ins openWB-UI einbaut: Ich bin ein Entwickler, nicht der betroffene Benutzer.

Ich denke, jemand der weiß, was MQTT ist, versteht auch den Unterschied zwischen verschlüsselt und unverschlüsselt. Der vorauseilende Schutz des Benutzers ist aus meiner Sicht überflüssig, und da ja euer eigener Broker überhaupt kein TLS macht, sogar ein bisschen paradox.

Sei's drum, wenn ihr wollt, mach ich euch einen Pull-Request mit der dritten Option "Unverschlüsselt".

lg, Christian

truckl hat geschrieben: ↑Fr Okt 23, 2020 7:40 pm Zum Beispiel indem Du direkt am MQTT-Server der openWB subscribst und published.
Alternativ: Die Brücke in Deinem lokalen MQTT-Gateway (ich nehme an das ist auch ein normaler MQTT-Server) konfigurieren. Wenn keine Firewalls im Spiel sind ist es doch völlig gleichgültig "wie herum" die Brücke konfiguriert wird.

Meine Absicht ist es nicht, dass Ihr Euch streitet Ich suche nur irgendeine Lösung wie ich 3 Geräte sinnvoll zum kommunizieren kriege....

Da ich keine Einstelloptionen in der openWB sehe für das MQTT intern ohne TLS anzusprechen, muss ich das dann über das Gateway triggern? Christian Du hast ja die Screenshots gesehen, mir ist noch nicht klar, was ich anders machen muss damit es klappt....

@BennyK

Du kannst im LoxBerry MQTT Gateway "Use local broker" deaktivieren und dann die Verbindungsdaten des openWB Brokers angeben (wo du die findest, gibt's sicher ne Dokuseite bei openWB dafür). Andere LoxBerry-Plugins mit MQTT übernehmen diese in der Regel von selbst, wenn du sonst noch irgendwo (z.B. Shelly's) die Daten vom LoxBerry drin hast, musst du diese auch auf jene vom openWB-Broker ändern.

Probier bitte vorher, was ich dir "drüben" geschrieben hab

lg, Christian

BennyK hat geschrieben: ↑Fr Okt 23, 2020 8:27 pm Meine Absicht ist es nicht, dass Ihr Euch streitet Ich suche nur irgendeine Lösung wie ich 3 Geräte sinnvoll zum kommunizieren kriege....

Streiten möchte ich ja auch nicht. Nur von der allgemeinen Aussage "nicht komplett" fühlte ich mich schon ein wenig angegriffen. Für den Zweck für den ich die Funktion eingebaut habe war sie nunmal "komplett genug" und über die Sicherheits-Implikationen wurde hier im Forum offen diskutiert und die jetzige Lösung erarbeitet.

Das Ergebnis ist aber natürlich ein Kompromiss zwischen Einfachheit, Möglichkeiten und Sicherheit. Der Ansatz war dabei: Alles was im lokalen LAN liegt wird als "sicher" angenommen. Alles außerhalb als "unsicher". Und zweitens, daß die openWB mindestens hinter einer Firewall betrieben wird.

Die "Zugangsdaten" zum MQTT-Broker der openWB sind entsprechend einfach: Port 1883, IP sollte bekannt sein, keine Authentifizierung.

christiantf hat geschrieben: ↑Fr Okt 23, 2020 8:17 pm Ich denke, jemand der weiß, was MQTT ist, versteht auch den Unterschied zwischen verschlüsselt und unverschlüsselt. Der vorauseilende Schutz des Benutzers ist aus meiner Sicht überflüssig, und da ja euer eigener Broker überhaupt kein TLS macht, sogar ein bisschen paradox.

Der ursprüngliche Auslöser für die Funktion waren tatäschlich Rückfragen wie man denn im Internet-Router das Port-Forwarding für externen Zugriff auf die openWB konfigurieren müsse. Als dann auch noch Shodan.io erste openWBs zu Tage förderte konnte ich nicht länger "zusehen" (oder besser gesagt "untätig mitlesen").

Habt bitte deshalb Verständnis dafür, daß ein komplettes Abschalten von TLS über das UI deshalb nicht erwünscht ist.

Ich verstehe aber die Anforderungen hier. Deshalb folgender Kompromissvorschlag:

Wie wäre es, wenn wir TLS deaktivierbar machen wenn die IP-Adresse des "entfernten MQTT-Servers" im Bereich der privaten IPs laut RFC 1918 liegt (Netzwerke 10/8, 172.16/12, 192.168/16, für IPv6 noch link-local fe80:: dazu)? Das impliziert aber, daß das Abschalten von TLS wirklich nur bei Angabe der IP, nicht aber bei Hostnamen (die IP dahinter könnte sich ändern), freigegeben würde.

Da diese Adressen von den BGP-Router im Internet (und hoffentlich auch von Internet-Modems beim Enduser) definitiv nicht weitergeleitet werden wäre ausgeschlossen, daß unverschlüsselte Zugangsdaten weiter als bis zum ersten Router kommen.

@openWBSupport: Wäre diese Erweiterung auch von eurer Seite aus akzeptabel?

@christianf: Ich bin leider absolut kein Web-Entwickler.
Wenn Du die entsprechende Funktionalität im Web-UI (Validierung der IP und entsprechende Freigabe eines "Kein TLS"-Option-Buttons) zuliefern könntest (Pfad "web\settings\mqtt.php" sowie "web\tools\savemqtt.php" relativ zum Repoistory-Root) würde ich die restlichen Anpassungen an "web\tools\savemqtt.php" machen um die Mosquitto-Konfiguration entsprechend zu schreiben.
Dabei würde ich ggf. auch die Template für die mittlerweile deutlich "gewachsenen" MQTT-Topics anpassen.

Dazu ist aber evtl. auch nochmal ein Dialog mit @openWBSupport nötig. Denn ich habe mittlerweile den Überblick verloren welche Topics ggf. für bestimmte Module auch schreibend interessant sind. Oder sollen wir jetzt doch nur noch auf das Root-Topic gehen?

@openWBSupport: Wäre diese Erweiterung auch von eurer Seite aus akzeptabel?

Finde ich eine sehr gute Lösung!

Ich denke, jemand der weiß, was MQTT ist, versteht auch den Unterschied zwischen verschlüsselt und unverschlüsselt.

Leider ist das nicht immer der Fall.

Sei's drum, wenn ihr wollt, mach ich euch einen Pull-Request mit der dritten Option "Unverschlüsselt".

Siehe Truckls Idee, wenn du das so umsetzt wird das direkt gemergt.

christiantf hat geschrieben: ↑Fr Okt 23, 2020 8:35 pm @BennyK

Du kannst im LoxBerry MQTT Gateway "Use local broker" deaktivieren und dann die Verbindungsdaten des openWB Brokers angeben (wo du die findest, gibt's sicher ne Dokuseite bei openWB dafür). Andere LoxBerry-Plugins mit MQTT übernehmen diese in der Regel von selbst, wenn du sonst noch irgendwo (z.B. Shelly's) die Daten vom LoxBerry drin hast, musst du diese auch auf jene vom openWB-Broker ändern.

Probier bitte vorher, was ich dir "drüben" geschrieben hab

Es gibt keinen Shell Zugriff, da ein Fertigprodukt.... finde ich einerseits auch richtig, da einige sich nicht so gut mit Linux auskennen.... aber ich habe es über den Weg geschafft.

Für die Nachwelt: Hab die openWB eingetragen mit Port 1883 und ohne Benutzername und Passwort und schwups war im MQTT Gateway von Dir Christian alles angezeigt.... sogar mehr als ich gedacht habe ....

Hab jetzt den Solaredge WR und Energiezähler direkt an der openWB dran und hole per MQTT Gateway die Werte in die Visualisierung und Haussteuerung....

Vielen Dank an alle für die angeregte Diskussion und die hilfreichen Infos.