SSL Probleme mit NodeJS-20
-
Hallo zusammen,
ich habe heute ein Update von NodeJS von v12 auf v20 gemacht und in dem zusammenhang auch alle Adapter und der IOB auf aktuelle Versionen gebracht.
Nun bekomme ich von Node-Red folgende Fehlermeldung:
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:16Das Problem scheint darin zu liegen, dass der bezeichnete Noder "EasyE4 IN" die veraltete SSL-TLS renegotiation verwendet, die seit NodeJS v18 standardmäßig deaktiviert ist.
Siehe z.B. hier
Oder ein möglicher Workaround hier, allerdings für einen anderen Anwendungsfall.: https://johnnyreilly.com/node-18-axios-and-unsafe-legacy-renegotiation-disabled)
Jetzt komme ich allerdings nicht weiter. Kann mir da jemand weiterhelfen? Das übersteigt meinen Horizont dann doch einwenig.
Viele Grüße
@klesi sagte in SSL Probleme mit NodeJS-20:
von NodeJS von v12 auf v20 gemacht
Und das Betriebssystem (und damit dessen root-Zertifikate) auch auf einen aktuellen Stand gehoben?
-
@klesi sagte in SSL Probleme mit NodeJS-20:
von NodeJS von v12 auf v20 gemacht
Und das Betriebssystem (und damit dessen root-Zertifikate) auch auf einen aktuellen Stand gehoben?
-
@thomas-braun
Hi, wenn du apt update && apt upgrade meinst, das mache ich jede woche 1x -
Nix besonderes. Für das Update habe ich NodeJS neu installiert, da das update über "iob nodejs-update" nicht funktioniert hat. Das script hat hinterher aber noch ein Verzeichnis repariert...
======================= SUMMARY ======================= v.2024-05-22 Static hostname: simon-extensa5630 Icon name: computer-desktop Chassis: desktop Operating System: Ubuntu 22.04.4 LTS Kernel: Linux 5.15.0-112-generic Architecture: x86-64 Hardware Vendor: To Be Filled By O.E.M. Hardware Model: To Be Filled By O.E.M. Installation: native Kernel: x86_64 Userland: 64 bit Timezone: Europe/Berlin (CEST, +0200) User-ID: 1000 Display-Server: true Boot Target: graphical.target Pending OS-Updates: 0 Pending iob updates: 0 Nodejs-Installation: /usr/bin/nodejs v20.14.0 /usr/bin/node v20.14.0 /usr/bin/npm 10.7.0 /usr/bin/npx 10.7.0 /usr/bin/corepack 0.28.1 Recommended versions are nodejs 18.20.3 and npm 10.7.0 Your nodejs installation is correct MEMORY: total used free shared buff/cache available Mem: 7.7G 2.6G 2.5G 145M 2.5G 4.6G Swap: 4.1G 0B 4.1G Total: 11G 2.6G 6.6G Active iob-Instances: 10 Active repo(s): stable ioBroker Core: js-controller 5.0.19 admin 6.13.16 ioBroker Status: iobroker is running on this host. Objects type: jsonl States type: jsonl Status admin and web instance: + system.adapter.admin.0 : admin : simon-extensa5630 - enabled, port: 8081, bind: 0.0.0.0, run as: admin system.adapter.web.0 : web : simon-extensa5630 - disabled, port: 8082, bind: 0.0.0.0, run as: admin Objects: 3377 States: 2482 Size of iob-Database: 22M /opt/iobroker/iobroker-data/objects.jsonl 1.3M /opt/iobroker/iobroker-data/states.jsonl =================== END OF SUMMARY ====================Edit:
da die NodeJS instalölio0n vorher schon bisschen kaputt war habe ich deinen Tipp aus nem anderen Thread benutzt und nodeJS einmal mitsudo apt purge nodejs* npm node-* libnode72Entfernt und dann aus dem Paketquellen die aktuelle Version installiert.
-
Nix besonderes. Für das Update habe ich NodeJS neu installiert, da das update über "iob nodejs-update" nicht funktioniert hat. Das script hat hinterher aber noch ein Verzeichnis repariert...
======================= SUMMARY ======================= v.2024-05-22 Static hostname: simon-extensa5630 Icon name: computer-desktop Chassis: desktop Operating System: Ubuntu 22.04.4 LTS Kernel: Linux 5.15.0-112-generic Architecture: x86-64 Hardware Vendor: To Be Filled By O.E.M. Hardware Model: To Be Filled By O.E.M. Installation: native Kernel: x86_64 Userland: 64 bit Timezone: Europe/Berlin (CEST, +0200) User-ID: 1000 Display-Server: true Boot Target: graphical.target Pending OS-Updates: 0 Pending iob updates: 0 Nodejs-Installation: /usr/bin/nodejs v20.14.0 /usr/bin/node v20.14.0 /usr/bin/npm 10.7.0 /usr/bin/npx 10.7.0 /usr/bin/corepack 0.28.1 Recommended versions are nodejs 18.20.3 and npm 10.7.0 Your nodejs installation is correct MEMORY: total used free shared buff/cache available Mem: 7.7G 2.6G 2.5G 145M 2.5G 4.6G Swap: 4.1G 0B 4.1G Total: 11G 2.6G 6.6G Active iob-Instances: 10 Active repo(s): stable ioBroker Core: js-controller 5.0.19 admin 6.13.16 ioBroker Status: iobroker is running on this host. Objects type: jsonl States type: jsonl Status admin and web instance: + system.adapter.admin.0 : admin : simon-extensa5630 - enabled, port: 8081, bind: 0.0.0.0, run as: admin system.adapter.web.0 : web : simon-extensa5630 - disabled, port: 8082, bind: 0.0.0.0, run as: admin Objects: 3377 States: 2482 Size of iob-Database: 22M /opt/iobroker/iobroker-data/objects.jsonl 1.3M /opt/iobroker/iobroker-data/states.jsonl =================== END OF SUMMARY ====================Edit:
da die NodeJS instalölio0n vorher schon bisschen kaputt war habe ich deinen Tipp aus nem anderen Thread benutzt und nodeJS einmal mitsudo apt purge nodejs* npm node-* libnode72Entfernt und dann aus dem Paketquellen die aktuelle Version installiert.
@klesi sagte in SSL Probleme mit NodeJS-20:
Display-Server: true
Boot Target: graphical.targetIst auch 'kaputt'. Schalt den Desktop an der Kiste aus.
Und was genau soll
da die NodeJS instalölio0n vorher schon bisschen kaputt war
und
da das update über "iob nodejs-update" nicht funktioniert hat.
heißen? Da war dann zuvor bestimmt was anderes als die 'nodesource'-Version installiert.
-
@klesi sagte in SSL Probleme mit NodeJS-20:
Display-Server: true
Boot Target: graphical.targetIst auch 'kaputt'. Schalt den Desktop an der Kiste aus.
Und was genau soll
da die NodeJS instalölio0n vorher schon bisschen kaputt war
und
da das update über "iob nodejs-update" nicht funktioniert hat.
heißen? Da war dann zuvor bestimmt was anderes als die 'nodesource'-Version installiert.
Da war NodeJS 12 drauf und vor einiger Zeit hatte ich ein Update auf V16 gemacht. Das aber wohl nicht richtig, da das Script immernoch V12 erkannt hat. Dadurch hat es dann scheinbar nicht funktioniert.
Nachdem ich NodeJS wie oben geschrieben entfernt hab und über apt install neu installiert hab habe ich iob diag laufen lassen und noch einen Fehler gehabt (Pfad von corepack war nicht korrekt. Die genaue Meldung habe ich nicht mehr parat)
Mit iob nodejs-update wurde dann noch der Pfad von /usr/bin/corepack korrigiert. -
Hallo nochmal,
Ich bin aktuell auf dem Stand, dass das System mit nodejs v 16.x aus der nodesource läuft. Sobald 18.x oder 20.x drauf ist, kommt der Fehler.
Testweise habe ich mal ein System komplett frisch mit Armbian aufgesetzt. Da ist das Problem das gleiche. Ich denke es liegt also weder an IO-Broker noch am Betriebssystem.iob diag:
======================= SUMMARY ======================= v.2024-05-22 Static hostname: bananapi Icon name: computer Operating System: Armbian 24.5.1 jammy Kernel: Linux 6.6.31-current-sunxi Architecture: arm Installation: native Kernel: armv7l Userland: 32 bit Timezone: Europe/Berlin (CEST, +0200) User-ID: 1000 Display-Server: false Boot Target: graphical.target Pending OS-Updates: 0 Pending iob updates: 0 Nodejs-Installation: /usr/bin/nodejs v18.20.3 /usr/bin/node v18.20.3 /usr/bin/npm 10.7.0 /usr/bin/npx 10.7.0 /usr/bin/corepack 0.28.0 Recommended versions are nodejs 18.20.3 and npm 10.7.0 Your nodejs installation is correct MEMORY: total used free shared buff/cache available Mem: 966M 410M 176M 4.0M 378M 528M Swap: 483M 0B 483M Total: 1.4G 410M 659M Active iob-Instances: 6 Active repo(s): stable ioBroker Core: js-controller 5.0.19 admin 6.13.16 ioBroker Status: iobroker is running on this host. Objects type: jsonl States type: jsonl Status admin and web instance: + system.adapter.admin.0 : admin : bananapi - enabled, port: 8081, bind: 0.0.0.0 (SSL), run as: admin Objects: 1900 States: 1692 Size of iob-Database: 6.5M /opt/iobroker/iobroker-data/objects.jsonl 3.9M /opt/iobroker/iobroker-data/states.jsonl =================== END OF SUMMARY ====================Evtl. liegt das Problem auf der "anderen Seite" der Kommunikation. Das ist eine Kleinsteuerung (Eaton Easy E4). Die ist ggf zu alt und unterstützt nur noch veraltete Protokolle. Ich bin da momentan im Kontakt mit der Hersteller.
Edit:
Die Steuerung unterstützt:- TLS_RSA_WITH_AES_128_CBC_SHA.
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
Erst ab einer neuen FW-Version, werden TLS-Zertifikate unterstützt. Passt das mit dem SSL-Fehler zusammen?
Wenn ja, wie kann ich Node v18.x dazu bringen, diese wieder freizuschalten? Auf lange Sicht macht es aber vermutlich Sinn die Steuerung gegen ein neues Modell zu ersetzen.
-
Hallo nochmal,
Ich bin aktuell auf dem Stand, dass das System mit nodejs v 16.x aus der nodesource läuft. Sobald 18.x oder 20.x drauf ist, kommt der Fehler.
Testweise habe ich mal ein System komplett frisch mit Armbian aufgesetzt. Da ist das Problem das gleiche. Ich denke es liegt also weder an IO-Broker noch am Betriebssystem.iob diag:
======================= SUMMARY ======================= v.2024-05-22 Static hostname: bananapi Icon name: computer Operating System: Armbian 24.5.1 jammy Kernel: Linux 6.6.31-current-sunxi Architecture: arm Installation: native Kernel: armv7l Userland: 32 bit Timezone: Europe/Berlin (CEST, +0200) User-ID: 1000 Display-Server: false Boot Target: graphical.target Pending OS-Updates: 0 Pending iob updates: 0 Nodejs-Installation: /usr/bin/nodejs v18.20.3 /usr/bin/node v18.20.3 /usr/bin/npm 10.7.0 /usr/bin/npx 10.7.0 /usr/bin/corepack 0.28.0 Recommended versions are nodejs 18.20.3 and npm 10.7.0 Your nodejs installation is correct MEMORY: total used free shared buff/cache available Mem: 966M 410M 176M 4.0M 378M 528M Swap: 483M 0B 483M Total: 1.4G 410M 659M Active iob-Instances: 6 Active repo(s): stable ioBroker Core: js-controller 5.0.19 admin 6.13.16 ioBroker Status: iobroker is running on this host. Objects type: jsonl States type: jsonl Status admin and web instance: + system.adapter.admin.0 : admin : bananapi - enabled, port: 8081, bind: 0.0.0.0 (SSL), run as: admin Objects: 1900 States: 1692 Size of iob-Database: 6.5M /opt/iobroker/iobroker-data/objects.jsonl 3.9M /opt/iobroker/iobroker-data/states.jsonl =================== END OF SUMMARY ====================Evtl. liegt das Problem auf der "anderen Seite" der Kommunikation. Das ist eine Kleinsteuerung (Eaton Easy E4). Die ist ggf zu alt und unterstützt nur noch veraltete Protokolle. Ich bin da momentan im Kontakt mit der Hersteller.
Edit:
Die Steuerung unterstützt:- TLS_RSA_WITH_AES_128_CBC_SHA.
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA256,
- TLS_ECDHE_RSA_WITH_AES_128_CBC_SHA.
Erst ab einer neuen FW-Version, werden TLS-Zertifikate unterstützt. Passt das mit dem SSL-Fehler zusammen?
Wenn ja, wie kann ich Node v18.x dazu bringen, diese wieder freizuschalten? Auf lange Sicht macht es aber vermutlich Sinn die Steuerung gegen ein neues Modell zu ersetzen.
Dürfte der Grund sein:
https://nodejs.org/en/blog/vulnerability/openssl-november-2022
openSSL3 hat diverse steinalte, unsichere Verfahren ad acta gelegt.
-
Dürfte der Grund sein:
https://nodejs.org/en/blog/vulnerability/openssl-november-2022
openSSL3 hat diverse steinalte, unsichere Verfahren ad acta gelegt.
Ich hab mich nochmal bisschen eingelesen. Das Internet ist quasi voll davon.
z.B. hier:
https://discourse.nodered.org/t/http-request-unsafe-legacy-renegotiation/73309
https://support.axway.com/kb/182365/language/enDie Fehlermelung aus dem Ursprünglichen Post kommt wenn ein "Outdated Client" versucht sich mit secure negotiation einem Server zu verbinden der OpenSSL 3+ (bzw. node.js v17+) benutzt. Die Lösung besteht nur darin, dass alle Clients nur noch TLS 1.3 verwenden.
-
Ich hab mich nochmal bisschen eingelesen. Das Internet ist quasi voll davon.
z.B. hier:
https://discourse.nodered.org/t/http-request-unsafe-legacy-renegotiation/73309
https://support.axway.com/kb/182365/language/enDie Fehlermelung aus dem Ursprünglichen Post kommt wenn ein "Outdated Client" versucht sich mit secure negotiation einem Server zu verbinden der OpenSSL 3+ (bzw. node.js v17+) benutzt. Die Lösung besteht nur darin, dass alle Clients nur noch TLS 1.3 verwenden.
Wovon? Das einige veraltete Verfahren aus Sicherheitsgründen auf Eis gelegt wurden?
Hey! Du scheinst an dieser Unterhaltung interessiert zu sein, hast aber noch kein Konto.
Hast du es satt, bei jedem Besuch durch die gleichen Beiträge zu scrollen? Wenn du dich für ein Konto anmeldest, kommst du immer genau dorthin zurück, wo du zuvor warst, und kannst dich über neue Antworten benachrichtigen lassen (entweder per E-Mail oder Push-Benachrichtigung). Du kannst auch Lesezeichen speichern und Beiträge positiv bewerten, um anderen Community-Mitgliedern deine Wertschätzung zu zeigen.
Mit deinem Input könnte dieser Beitrag noch besser werden 💗
Registrieren Anmelden624
Online32.8k
Benutzer82.8k
Themen1.3m
Beiträge