Problem mit NodeRed und NodeJS 18.x

[Klesi]

Hallo zusammen,

ich habe ein Problem, welches vermutlich am Alter des EasyE4 Nodes liegt.

Dieser funktioniert bis zur NodeJS V16.x. Ab V18.x erscheint die folgende Fehlermeldung

Code: [Auswählen]

Node-RED: 9 Jun 13:53:35 - [error] [easyE4 IN:ae7c0dd02bcf44dd] Error: write EPROTO 40681F5C897F0000:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:../deps/openssl/openssl/ssl/statem/extensions.c:921: at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:95:16

Das Problem scheint darin zu liegen, dass der die veraltete SSL-TLS renegotiation verwendet, die seit NodeJS v18 standardmäßig deaktiviert ist.

Ich selber bekomme da Problem leider nicht gelöst und habe erstmal wieder einen Downgrade auf NodeJS 16.x durchgeführt.

Vielleicht hat hier jemand eine Idee wie das Problem zu lösen ist. Mittel der Wahl wäre wohl den Node zu aktualisieren, sofern das geht.

Viele Grüße

[CiesleRa]

Hallo Klesi,

ich habe mal versucht das nachzustellen und kann den Fehler nicht nachvollziehen.
Ich nutze nodejs 18.20.3 und Node-Red 3.1.3 und habe keine Probleme.
Auf der easyE4 Seite easySoft 8.10 mit FW.2.10. SSL/TLS aktiv auf Port 443. 

Vielleicht kannst Du dein E4- und Node-Red Projekt hier einstellen. Dann könnte ich mal schauen, ob mir etwas auffällt.

Gruß
Ralf

[Klesi]

Hallo Ralf,

ich hab das Projekt mal angehangen.
Der Webserver bei der E4 ist auch mit SSL/TLS auf Port 443, allerdings noch mit FW 1.23.

Der Flow läuft im IO-Broker und stellt eigentlich nur eine Schnittstelle zu Alexa dar.

Vielleicht fällt dir etwas auf. Sonst suche ich mal in meinem System weiter nach dem Fehler...

Viele Grüße

[w.sprungmann]

Hallo Klesi,
mach doch erst mal ein Firmware Update.
Ich würde FW1.41 nehmen weil,
FW 1.42 Probleme mit Programmverlust und Verlust der remanenten Daten haben könnte.
FW 1.43 bei mir Probleme mit dem Zeitserver SNTP hat.
Gruß Wilhelm

[CiesleRa]

Hallo Wilhelm,

ich bin bei dir, die easyE4 auf eine neue Firmware upzudaten. Ich bin ganz und garnicht bei dir was die Version betrifft.
Wenn Du dir die Release Notes zur FW 1.42 anschaust, findest Du eine sehr lange Liste, nicht nur von neuen Features,
sondern auch von Fehlerbehebungen die in der 1.41 noch vorhanden waren.

Meine Empfehlung ist es, immer auf die neuste Version upzudaten. In diesem Fall der 1.43. Auch wenn es bei dir evtl. Probleme
mit dem Zeitserver gibt. Das muß nicht allgemeingültig sein.

Gruß Ralf

[CiesleRa]

Hallo Klesi,

ich habe mir dein Node-Red Projekt mal angeschaut. Ich finde darin keine IN-NODE. Die braucht man zur Kommunukation mit der easyE4.
Vielleicht ist der Name etwas undeutlich, denn es geht nicht darum Eingänge einzulesen. In der IN-NODE werden alle I, Q, M, MW, MD ..... eingetragen,
die man in seinem Projekt verwendet. Vielleicht helfen schon die Bilder um ein Verständnis dafür zu bekommen, oder Du schaust mal in das
Video, dass ich zu dem Thema gemacht habe. https://youtu.be/DYSyAC2fZh8?si=kvba7Hx2rUUDNpcF.

In deinem easyE4 Projekt ist mir aufgefallen, dass hat aber nichts mit deinem Problem zu tun, dass beim DNS-Server lauter 8ten stehen und nicht 0 und
Du hast NET-Merker freigegeben, obwohl Du kein Netzwerk hast.
Ich persönlich bin auch kein Freund davon, den den  gesamten Merkerbereich von MW1 bis MW512 freizugeben und gebe nur das ein, was ich brauche.
Sollte aber auch nicht stören. Außerdem ist der Modbus-TCP Server aktiv. Wenn Du keinen Modbus-Client angeschlossen hast, würde ich auch das deaktivieren.
Warum die easyE4 mit nicht genutzten Funktionen belasten.

Gruß
Ralf
   

[Klesi]

Hallo Ralf,

danke für die Hinweise.
Das Video hatte ich gesehen und festgestellt, dass die Variante von mir ziemlich Ineffizient ist, da ja sehr oft Easy_out verwendet wird.
Vorher hatte ich gedacht. EasyIn = Lesen von Easy und EasyOut = schreiben nach Easy, da ich eigentlich nur die Infos von Alexa schreiben wollte habe ich alles mit EasyOut gelöst. Grundsätzlich funktioniert es aber und ich hatte bisher nicht die Muse das ganze neu zu machen.

Ein FW-Update auf v1.43 habe ich gemacht das hat leider nicht geholfen. Beim lesen der Releasenotes von FW v2.0 habe ich gesehen, dass TLS-Zertifikate eingeführt werden. Möglicherweise ist das die Ursache. Leider habe ich HW-Version 03 und kann somit nicht höher als FW v1.43.

Ich habe den IOBroker testweise auf ein frisches System neu installiert. Auch da tritt der Fehler auf. Ein Problem auf der Seite der Kommunikation würde ich also ausschließen.

[CiesleRa]

Hallo Klesi,

die IN-Node dient der Optimierung der Kommunikation und ist unbedingt erforderlich.
Ohne die IN-Node wird der Fehler nicht behoben werden können. Wenn Du dir die
Fehlermeldung aus deinem ursprünglichen Post ansiehst, geht es um die IN-Node.

Node-RED: 9 Jun 13:53:35 - [error] [easyE4 IN:ae7c0dd02bcf44dd] Error: write EPROTO 40681F5C897F0000:error:0A000152:SSL routine

Die Fehlermeldung hat nichts mit SSL/TLS zu tun, sondern erscheint, weil die IN-Node fehlt.
Bitte baue sie in dein Projekt ein und konfiguriere sie. Ich bin mir sicher, dass dann alles in Ordnung ist.

Gruß
Ralf

[Klesi]

Hallo Ralf,

der IN-Node hat nur indirekt damit zu tun. Ich hatte einen IN-Node im Flow, aber den Programmteil wollte ich nicht veröffentlichen. Der Fehler kommt bei jedem Versuch eine Kommunikation mit der Easy aufzubauen.

Code: [Auswählen]

Node-RED: 14 Jun 20:44:21 - [error] [easyE4 OUT:7e6d47fa6f79ea5c] Error: write EPROTO A06BF2B6:error:0A000152:SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:../deps/openssl/openssl/ssl/statem/extensions.c:922: at WriteWrap.onWriteComplete [as oncomplete] (node:internal/stream_base_commons:94:16)
Wichtig ist der Teil

Code: [Auswählen]

final_renegotiate:unsafe legacy renegotiation disabled:
Bei Node.js v16 funktioniert mein Flow fehlerfrei.

Das Problem liegt im Kommunikationsaufbau.

Beispiele hier:
https://discourse.nodered.org/t/http-request-unsafe-legacy-renegotiation/73309
https://support.axway.com/kb/182365/language/en

Der Hintergrund ist, dass mit Node.js v17 OpenSSL v3.0.7 eingeführt wurde. Damit wurde die  "secure renegotiation" deaktiviert. Diese nutzt aber die Easy offenbar noch um das TLS-Protokoll beim Handshake auszuhandeln. (siehe die Links oben).
Die Lösung ist eigentlich nur, dass die "alte" Easy FW v1.43 ein Update auf TLS v1.3 bekommt (wie bei FW 2.0) ODER die alten Geräte müssen weiterhin nur mit Nods.js V16 arbeiten.

Viele Grüße

[w.sprungmann]

Hallo,
ich habe die Anfrage zur Entwicklung von Eaton geschickt und diese Antwort erhalten,

die V2 Geräte haben auch nur TLS 1.2
Für V1 Geräte ist nicht geplant noch weitere Feature Updates zu machen, da diese Geräte nicht mehr produziert werden.
Für V2 natürlich schon.
im Forum steht:
SSL routines:final_renegotiate:unsafe legacy renegotiation disabled:
Das hat nichts mit TLS V1.2 oder V1.3 zu tun.
V1 und V2 nutzen eine unterschiedliche Art der Renegotiation. Das hat nicht mit TLS zutun
Vermutlich reicht es in seinem node.js die Renegotiation wieder zu aktivieren.

Hier beschrieben:
https://stackoverflow.com/questions/74324019/allow-legacy-renegotiation-for-nodejs
 
you can setup the global configuration for OpenSSL when executing node process:
 __
node --openssl-config=./openssl.cnf# or by ENV (thanks for Faisal Feroz)OPENSSL_CONF=./openssl.cnf node
--openssl-config: Load an OpenSSL configuration file on startup.
where openssl.cnf can be like:
 __
nodejs_conf = openssl_init
[openssl_init]
ssl_conf = ssl_sect
[ssl_sect]
system_default = system_default_sect
[system_default_sect]Options = UnsafeLegacyRenegotiation
Using nodejs_conf is required, since it will avoid conflict with other configuration files, see --openssl-shared-config for more info.
 
hier nochmal dasselbe:
https://stackoverflow.com/questions/75147968/npm-unsafe-legacy-renegotiation-disabled-issue
 
es geht vor allem um
[system_default_sect]
Options = UnsafeLegacyRenegotiation


Gruß Wilhelm