piVCCU3 mit Firmware 3.41.7

[jmaus]

der Post wäre sinnvoller im allgemeinen CCU3 Thread. Und eigentlich auch im.Changelog.

Auf das eQ3 ChangeLog hab ich keinen Einfluss. Es steht dir aber frei den Post entsprechend im CCU3 Thread zu verlinken bzw. dahin verschieben zu lassen. Mit der nächsten kommenden RaspberryMatic wird es aber einen entsprechenden ChangeLog geben der etwas ausführlicher ist als das was eQ3 da veröffentlicht hat.

[darkbrain85]

Ingesamt muss man sagen sollte das die generelle Sicherheit für RemoteAPI Anfragen an eine CCU wirklich substantiell verbessern. Einziger Wermutstropfen ist bis jetzt, das mit diesen Umstellungen (das lighttpd nun ein Proxy für all diese API Ports ist) eine Remote-API Abfrage nun zwingend mittels XMLRPC erfolgen muss und BINRPC Anfragen damit lediglich für localhost (127.0.0.1) Verbindungen weiterhin funktionieren wird. Ergo sollte BINRPC nun IMHO als obsolete angesehen werden – es war ohnehin nie ein offizieller Standard.

Da Du daran sicher rnicht unbeteiligt warst, herzlichen Dank dafür! Auch wenn sich immer einer findet der meckert, ist das doch ein erfreulicher Schritt...

[matthias.s]

Aktuell sind mir keine weiteren Bugs/Probleme mit system.Exec() und "&" bekannt und entweder mit der ReGaHss R1.00.0388.0130 oder der neuesten R1.00.0388.0202 (in der CCU 3.41.7) sollte es keinerlei Probleme mehr mit der system.Exec() und "&" mehr geben.

Kleine Verständisfrage dazu:

Keine Bugs/Probleme mit system.Exec() bezieht sich hier ausschließlich auf die piVCCU3-Firmware in der Version 3.41.7 oder auch auf die offizielle CCU3-Firmware?

Gruß, Matthias

[klassisch]

Nach meinem Verständnis bezieht sich das primär auf die offizielle CCU3 Version. piVCCU ist die getreuste Virtualisierung, ist Backup-kompatibe und erbt alle Pros und Cons der originalen CCU3-FW.

Im Thread zur originalen CCU3 FW 3.41.7 viewtopic.php?p=465157#p465157 ist wiederum ein Hinweis, daß es Probleme mit Mediola gibt. Das wird die meisten hier nicht direkt belasten, läßt aber erwarten, daß da noch was nachgeschoben wird.

[thkl]

Zusätzlich dazu existieren nun als neues Feature für all diese oben genannten Ports - über die normalerweise unverschlüsselt kommuniziert wird - entsprechende SSL Portvarianten die jeweils mit der Zahl "4" beginnen. D.h. z.b. Ist der Port für eine SSL verschlüsselte Kommunikation mit dem ReGa-Skript-Server nun die 48181, für den XMLRPC des ReGaHss die 41999, für den XMLRPC des RFD die 42001, usw. D.h. also man kann nun sämtliche XMLRPC/ReGa-Skript Kommunikation voll verschlüsselt ablaufen lassen wenn man statt den unverschlüsselten Ports die verschlüsselten Varianten verwendet.

Schaut leider so aus, als ob das SSL Zertifikat selbstsigniert ist. Damit ist es nutzlos. Jeder anständige Browser bzw. jedes https Framework verweigert die Kommunikation mit einem Server, welcher kein nachvollziehbares Zertifikat vorweist. Wenn ich diesen Check manuell ausschalten muss (siehe wget --no-check-certificate) kann ich es auch lassen.

[jmaus]

Schaut leider so aus, als ob das SSL Zertifikat selbstsigniert ist. Damit ist es nutzlos. Jeder anständige Browser bzw. jedes https Framework verweigert die Kommunikation mit einem Server, welcher kein nachvollziehbares Zertifikat vorweist. Wenn ich diesen Check manuell ausschalten muss (siehe wget --no-check-certificate) kann ich es auch lassen.

Dann erklär mir mal bitte wie auf eine Zentrale die rein im internen Netzwerk liegt ein komplett durchsigniertes SSL Zertifikat gelangen soll ohne dafür Geld zu verlangen?!? Und komm jetzt nicht mit LetsEncrypt, denn dafür müsstest du die Zentrale über gewisse Methoden direkt mit dem Internet verbinden damit die Server von LetsEncrypt darauf zugreifen können. Ergo, sowas geht nicht und jedes interne Hub usw. verhält sich hier genauso. Wenn du also z.B. einen Netzwerkdrucker hast und dort SSL einstellst wirst du auch ein rein selbst-signiertes Zertifikat erhalten, ausser du lädst ein eigenes kommerziell erworbenes Zertifikat hoch oder ein LetsEncrypt Zertifikat das du selbst alle drei Monate manuell beschaffst.

Ergo, dir bleibt nichts anderes übrig als deinen Browsern beizubringen das du diesem selbst signierten Zertifikat voll vertraust. Und genau das gleiche machst du ja auch mit der "--no-check-certificate" Option des wget/curl. Damit schaltest du ja nicht die Verschlüsselung aus sondern sagst lediglich das du diesem Zertifikat voll vertraust. Die SSL Verbindung ist also trotzdem sicher - zumindest solange niemand an den privaten SSL Schlüssel kommt der auf der Zentrale liegt.

[thkl]

Die SSL Verbindung ist also trotzdem sicher - zumindest solange niemand an den privaten SSL Schlüssel kommt der auf der Zentrale liegt.

Es geht nicht um die sichere Verbindung zur CCU und das Abhören der Daten. Es geht darum, das der Client auch der CCU vertrauen kann. Wenn ich schon ein User/Password zur Authentifizierung brauch, dann möchte ich doch bitte sichergehen, das ich dieses auch nur dem System mitteile, für welches es gedacht ist. Und nicht jedem x beliebigen Device im Netzwerk, welches sich hinter der vermuteten IP befindet. Dann kann ich es auch lassen ...

[jmaus]

Es geht nicht um die sichere Verbindung zur CCU und das Abhören der Daten. Es geht darum, das der Client auch der CCU vertrauen kann. Wenn ich schon ein User/Password zur Authentifizierung brauch, dann möchte ich doch bitte sichergehen, das ich dieses auch nur dem System mitteile, für welches es gedacht ist. Und nicht jedem x beliebigen Device im Netzwerk, welches sich hinter der vermuteten IP befindet. Dann kann ich es auch lassen ...

Dann hast du leider übersehen, das du natürlich z.B. bei einer Browserverbindung dir zumindest den Fingerprint des im Browser präsentierten Zertifikates der Verbindung mit dem eigentlichen selbst-signierten Zertifikat das auf der CCU liegt vergleichen solltest und wenn dieser Fingerprint übereinstimmt kannst du im Browser dieses Zertifikat als Vertrauenswürdig markieren. Sollte es sich dann später ändern (weil eben ein Angreifer dich auf eine andere Seite umleitet) dann wird dein Browser dir erneut eine Warnung bringen und dann sollte dir auffallen das der Fingerprint nicht mit dem übereinstimmt welcher in dem CCU Zertifikat hinterlegt ist.

Das selbe gilt natürlich bei anderen Clients wie auch wget/curl. Auch dort kannst du dir das Zertifikat ausgeben lassen und natürlich statt dem generellen "--no-check-certificate" das Zertifikat der CCU zum Beispiel zum lokalen Zertifikatsbundle wo der Client ausgeführt wird hinzufügen, dann sollte wget auch nicht mehr bei Nutzung ohne "--no-check-certificate" die Verbindung verweigern weil er im Bundle dieses als Vertrauenswürdig abgelegt findet.

Und wenn dir das immer noch nicht genug ist, dann bleibt dir natürlich trotzdem die Möglichkeit ein vollwertiges Zertifikat bei einem kommerziellen Anbieter zu beziehen der Zertifikate signieren dar und dessen CA Zertifikat selbst im Bundle bereits aufgenommen ist. Dann kannst du dieses manuell auf der WebUI hochzuladen bzw. in der CCU zu installieren.

Andere Möglichkeiten sind mir nicht bekannt und zu erwarten das die Firmware mit einem Zertifikat daher kommt das von öffentlichen Stellen durchsigniert ist oder solche Zertifikate generieren kann ist leider etwas zu kurz gedacht.

[g55]

Hallo Ihr Lieben,
erstmal herzlichsten Dank an Alex + Jens (@deimos und @jmaus) für euer stetiges Engagement hier !!
ich bin zwar erst HomeMatic-Anfänger seit ca. 2 Monaten, aber die Sicherheit ist mir schon wichtig. Hat mich schon etwas stutzig gemacht, dass im Homematic einfach per http ohne Auth kommuniziert wird ich möchte als etwas skeptischer User = paranoid auch im Heimnetz eigentlich nur https, wenn's geht auch mit zumindest "basic Auth" haben.
ich war schon dabei, mir die Infos ür nen ReverseProxy per nginx zusammen zu suchen, den brauch ich eh für den Raspi für Kontakte/Kalender-Server per Radicale ... und jetzt sehe ich, dass das auch mit CCU3 / piVCCU3 geht ... super, das probier ich die nächsten Tage bestimmt..

als ob das SSL Zertifikat selbstsigniert ist. Damit ist es nutzlos

da stimme ich definitiv auch Jens zu : selbstsignierte Zertifikate sind mMn.im Heimnetz immer gut. Das nutzen meine E2-Receiver, die Syno-NAS etc. alles ist HTTS im Heimnetz und ist in den Browsern so akzeptiert. Keines der Geräte steht im Internet, wozu auch, ich hab ja VPN "von draußen"

aber mal "back to piVCCU" : Alex , hab ich das richtig verstanden, dass ich für die neue Version in der apt config das stable auf testing ändern müßte und dann das normale "apt update && apt upgrade" ausführen ?

PS : wie komme ich eigentlich von "testing" wieder zurück auf "stable" ? ... sorry, bin halt noch "Anfänger" ...

[deimos]

Hi,

aber mal "back to piVCCU" : Alex , hab ich das richtig verstanden, dass ich für die neue Version in der apt config das stable auf testing ändern müßte und dann das normale "apt update && apt upgrade" ausführen ?

Korrekt. Bei den piVCCU3 Images steht das in der Datei /etc/apt/sources.list.d/pivccu.list

PS : wie komme ich eigentlich von "testing" wieder zurück auf "stable" ? ... sorry, bin halt noch "Anfänger" ...

Rein das Repository änderst du auf dem gleichen Weg, das macht dann aber kein automatisches Downgrade auf die letze stable Version. Das kannst du mit

Code: Alles auswählen

sudo apt install pivccu3-[VERSION]

machen, wobei [VERSION] durch die entsprechende Version zu ersetzen ist. Im Moment ist das die 3.37.8-6 Bei einem Downgrade muss man immer darauf gefasst sein, dass sich irgendwas inkompatibles in den Configs befindet, daher macht es da Sinn ein entsprechend altes (CCU-)Backup wieder einzuspielen.

Viele Grüße
Alex