Mal wieder "Websocket error undefined"

[Tom Bombadil]

Hallo,

vorweg: shNG/sV laufen seit langem bei mir stabil in einer zentralen Debian-VM auf dem NAS (QNAP). In der gleichen VM liegt auch eine nextCloud-Installation, die unseren Kalender enthält. Diese nextCloud-Installation mault seit Ewigkeiten beim Selbstcheck, ich solle doch gefälligst ein Zertifikat installieren und auf https wechseln. Also hab ich mich mal drauf eingelassen.

Nach Installation des selbst ausgestellten Zertifikats wurden zwar noch die SV-Seiten dargestellt, aber keine Daten mehr durch shNG angeliefert. Nach einigen Sekunden erschien immer das rote ERROR-Warndreieck rechts oben mit der Meldung

Driver: smarthome.py
Could not connect to smarthome.py server!
Websocket error undefined.

Die sV-eigenen Plugins (nextCloud, Fritzbox) erhielten aber nach wie vor ihre Daten.

Da Chrome und Firefox auf https bestehen, war ein testweises Fallback auf http dort nicht möglich. http ging aber sehr wohl in Edge, in dem die Visu dann auch ordnungsgemäß mit allen shNG-Daten angezeigt wurde.

Die Chrome-Konsole hat auf ein Problem in driver/io_smarthome.py.js in Zeile 115 verwiesen:

protocol = location.protocol === 'https:' ? 'wss://' : 'ws://';

Nach einer temporären Änderung in

protocol = location.protocol === 'https:' ? 'ws://' : 'ws://';

lädt Chrome alle Daten wieder ordnungsgemäß. Offensichtlich gibt es also ein Kommunikationsproblem mit shNG bei der Verwendung von wss://.

Es werden zwar in der Konsole zwei Warnungen ausgegeben:

io_smarthome.py.js:130 Mixed Content: The page at 'https://192.168.178.7/smartvisu/index.php?page=heizung' was loaded over HTTPS, but attempted to connect to the insecure WebSocket endpoint 'ws://192.168.178.7:2424/'. This endpoint should be available via WSS. Insecure access is deprecated.

io_smarthome.py.js:130 Connecting to a non-secure WebSocket server from a secure origin is deprecated.

Es ist also fraglich, wie lange noch ('deprecated') - aber es läuft. Auch dauert es jetzt ca. 30s, bis erste Daten von shNG angeliefert werden (Eieruhr), vorher kamen die immer gleich.

Ist das ein Fehler auf der Treiberseite von sV/shNG, oder liegt hier ein anderes Problem vor? Nach meinem Verständnis haben ja eigentlich Websockets mit einem Zertifikat für den http-Webserver (Apache) eher wenig zu tun, oder? Hat hier jemand die Kombi shNG/sV mit installiertem (selbstausgestellten) Zertifikat erfolgreich am Laufen?

/tom

ps: Ich bin weder ein https-/Zertifikatsexperte (der ganze Krimskrams geht mir sogar auf die Nerven), noch bin ich mir sicher, ob das Thema in shNG nicht vielleicht besser aufgehoben wäre. Oder ob es sogar ein Konfigurationsproblem des Webservers bzw. Betriebssystems ist. Auch gibt es hier im Forum über die Jahre verteilt mehrere Threads zu genau diesem Fehlerbild; aber keinen einzigen mit einer Lösung (selbst Marcus/Callidomus hatte dann irgendwann aufgegeben). Danke also für neue Lösungsansätze!

[Tom Bombadil]

Nachtrag: Der konkrete Fehler im Browser bei Verwendung von wss lautet:

io_smarthome.py.js:130 WebSocket connection to 'wss://192.168.178.7:2424/' failed: WebSocket opening handshake timed out

/tom

[Tom Bombadil]

Nächster Nachtrag: Diese Fehlermeldungen sind im shNG-Log zu finden (Log ist der Lesbarkeit halber gekürzt und formatiert). Jedes Mal, wenn die sV eine Kommunikation über den Websocket aufbauen will, wird ein UTF8-Fehler geworfen. Ist es vielleicht ein Zeichensatzproblem?

2020-04-03 19:32:39 ERROR plugins.visu_websocket _websocket.json_parse exception: 'utf-8' codec can't decode byte 0x80 in position 3: invalid start byte
Traceback (most recent call last):
File "/usr/local/smarthome/plugins/visu_websocket/__init__.py", line 838, in rfc6455_parse
self.json_parse(payload.decode())
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x80 in position 3: invalid start byte

2020-04-03 19:45:34'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte

2020-04-03 19:47:04'utf-8' codec can't decode byte 0x8a in position 2: invalid start byte
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 2: invalid start byte

2020-04-03 19:56:34'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte

2020-04-03 20:08:34'utf-8' codec can't decode byte 0xb3 in position 0: invalid start byte
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xb3 in position 0: invalid start byte

2020-04-03 20:11:34'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte

2020-04-03 20:12:17'utf-8' codec can't decode byte 0xd2 in position 0: invalid continuation byte
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd2 in position 0: invalid continuation byte

2020-04-03 20:12:17'utf-8' codec can't decode byte 0xc4 in position 0: invalid continuation byte
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc4 in position 0: invalid continuation byte

2020-04-03 20:12:17'utf-8' codec can't decode byte 0xc7 in position 1: invalid continuation byte
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xc7 in position 1: invalid continuation byte

2020-04-03 20:13:39'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte

2020-04-03 20:20:37'utf-8' codec can't decode byte 0x8a in position 2: invalid start byte
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 2: invalid start byte

2020-04-03 20:21:36'utf-8' codec can't decode byte 0x8a in position 1: invalid start byte
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 1: invalid start byte

2020-04-03 20:23:35'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte

2020-04-03 20:34:36'utf-8' codec can't decode byte 0xd1 in position 3: invalid continuation byte
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xd1 in position 3: invalid continuation byte

2020-04-03 20:41:36'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x8a in position 0: invalid start byte

2020-04-03 20:50:05'utf-8' codec can't decode byte 0xa0 in position 2: invalid start byte
UnicodeDecodeError: 'utf-8' codec can't decode byte 0xa0 in position 2: invalid start byte

2020-04-03 20:50:36'utf-8' codec can't decode byte 0x85 in position 0: invalid start byte
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x85 in position 0: invalid start byte

2020-04-03 20:59:35'utf-8' codec can't decode byte 0x88 in position 1: invalid start byte
UnicodeDecodeError: 'utf-8' codec can't decode byte 0x88 in position 1: invalid start byte

/tom

[Msinn]

Offensichtlich gibt es also ein Kommunikationsproblem mit shNG bei der Verwendung von wss://.

Hast Du denn in SmartHomeNG Zertifikate hinterlegt? Ich selber die Verbindung noch nie per wss probiert, aber bei einem Blick in den Code des visu_websocket Plugins sieht es so aus, als würde es wss beherschen (wenn man tls und Zertifikate kondiguriert hat).

[Tom Bombadil]

Die Verbindung auf wss wird ja automatisch aktiviert, sobald auf dem Server ein Zertifikat eingespielt wird; da kann man meines Wissens mit "normalen Mitteln" nichts händisch beeinflussen. Irgendwelche Zertifikate habe ich daher auch nur gemäß Anleitung eingespielt; nach meinem Laienwissen also nur für den Apache.

Wie geschrieben - alle anderen Systeme liefen ja auch auf Anhieb, inkl. Backend/Admin-Interface von shNG, die sV, NextCloud usw. Der NextCloud "System check" hat auch ganz stolz "Keine Fehler oder Probleme" gemeldet. Nur der Websocket zwischen shNG und sV wird nicht aufgebaut. Manuelles Fallback durch den bösen 'Hack' (siehe oben) in der io_smarthome.js bringt dann auch den Websocket wieder hoch.

Ich habe jetzt hoffentlich den richtigen Schalter gefunden, um SSL global wieder auszuschalten (Datei /etc/apache2/ssl/1, SSLEngine on --> off, danach service apache2 restart). Dann heult zwar NextCloud wieder rum, aber zumindest läuft die sV wieder auf allen Geräten. Wenn alles wieder ok sein sollte, fasse ich diesen ganzen Zertifikatsquatsch / SSL usw in den nächsten 1.000 Jahren ganz sicher nicht wieder an. Dieser ganze Blödsinn ist nix weiter als eine Arbeitsbeschäftigungsmaßnahme ...

/tom

[Msinn]

Da SmartHomeNG nicht unter Apache läuft, kann es auch nicht auf die dort eingespielten Zertifikate zugreifen. Siehe auch hier in der Config-Doku zum Plugin: http://www.smarthomeng.de/user/plugi...ght=zertifikat

[Tom Bombadil]

Ja, den Hinweis hatte ich gelesen. Nun ist ja aber das gute alte TLS nicht zwingend das gleiche wie SSL.

Auch finde ich nach den Installation im SSL-Verzeichnis des Apache zwar eine apache.crt und eine apache.key, aber keine ca.crt.

Am Rande: Die Beispieldaten in der plugin.yaml.default scheinen auch noch einen Fehler aus alten Zeiten zu enthalten:

websocket:
    plugin_name: visu_websocket
    #ip: 0.0.0.0
    #port: 2424
    #tls: no
    #wsproto: 4
    #acl: rw

Da tls gemäß Doku und gemäß plugin.yaml im Plugin-Verzeichnis ein boolscher Wert ist, müsste hier nach meinem Verständnis False/True und nicht no/yes verwendet werden.

Das ganze finde ich zumindest mittelprächtig verwirrend. Daher hatte ich ja auch eingangs gefragt, ob überhaupt schon jemand sowas am Laufen hat ...

/tom

[Msinn]

Wie ich schrieb, habe ich das noch nie mit wss genutzt. Das ist noch die selbe Implementation wie schon im alten smarthome.py. Du kannst im SmartHomeNG Forum ja mal fragen ob jemand das Websocket Plugin mit wss nutzt. (Ich kenne keinen).

Ich habe das in der plugin.yaml.default mal auf tls: False geändert.

[Tom Bombadil]

Ja, ich war mir ja auch nicht sicher, wo die Ursache liegt und hatte dann das sV-Forum gewählt, da der Fehler hier offensichtlich auftritt (wie eingangs geschrieben). Und hatte bei der Recherche gleich mehrere Threads mit genau diesem Fehlerbild gefunden - aber keinen mit einer Lösung.

Mittlerweile wird das Bild etwas klarer.

Im Grunde müßte der Treiber der sV einen Parameter "force_ws_instead_of_wss: False/True' für den mixed Mode bekommen, der bei https:// im Websocket trotzdem ws:// statt wss:// benutzt. Kann mich ja mal dranmachen, wenn gewünscht - die richtige Stelle hab ich ja eh schon am Wickel, und mehr als ein Dreizeiler plus ein neuer Parameter in der Config-Datei dürfte es eigentlich nicht sein.

Allerdings dürfte solch ein Fix nur temporärer Natur sein, da zumindest Chrome und FF bereits Deprecated-Warnungen schmeißen, wenn man 'mixed Mode' fährt. Besser wäre vermutlich ein klare Dokumentation, wie man SSL unter shNG einrichtet, und wo die dafür benötigten Daten/Dateien auf dem Webserver rumlungern. Das bringt dann aber auch regelmäßige (doppelte) Zertifikatsupdates mit sich - 1x Webserver, 1x separat in shNG. Die meisten freien Zertifikaten sind nur 3 Monate gültig...

/tom

[Msinn]

Das ist der Grund warum ich in meinem privaten Netz auch die Visu ohne https fahre.

[Tom Bombadil]

Im Grunde müßte der Treiber der sV einen Parameter "force_ws_instead_of_wss: False/True' für den mixed Mode bekommen, der bei https:// im Websocket trotzdem ws:// statt wss:// benutzt. Kann mich ja mal dranmachen, wenn gewünscht - die richtige Stelle hab ich ja eh schon am Wickel, und mehr als ein Dreizeiler plus ein neuer Parameter in der Config-Datei dürfte es eigentlich nicht sein.

Ich antworte mir mal selbst:

driver/io_smarthome.py.js ab Zeile 111:

var protocol = '';
if (!io.address || io.address.indexOf('://') < 0) {
[COLOR=#c0392b]  // adopt websocket security to current protocol (https -> wss and http -> ws)
  // if the protocol should be forced, add it to the address[/COLOR]
  protocol = location.protocol === 'https:' ? 'wss://' : 'ws://';
  if (!io.address) {
    // use url of current page if not defined
    io.address = location.hostname;
  }
[...]
}

So wie ich das interpretiere, muss man also nur in der config.ini statt driver_address="192.168.178.7" die Angabe driver_address="ws://192.168.178.7" machen, und der mixed Mode wird eingeschaltet. Hab's aber mangels Zertifikats-Nerven nicht ausprobiert.

/tom

[Hasenradball]

Hi bist Du schon weitergekommen?

Ich bin gerade ein wenig verwirrt mit dem ganzen Sicherheits gedönse.
Wenn ich über den reverse proxy mit https zugreife geht die VISU ohne Probleme (ohne Zertifikate zu installieren) auf --> nur die Wegsacket Verbindung klappt nicht.
Wenn ich intern im Netz bin kann ich die VISU nicht mal mit https aufmachen geht nur mit http deshalb weiß ich gerade nicht ob nur die Zertifikate das Problem sind.

[Tom Bombadil]

Nein - ich konnte glücklicherweise alles wieder einigermaßen 'zurückbiegen', die Visu funktionierte dann wieder auf allen meinen Geräten. Die ganze (am Ende erfolglose) Spielerei hat mich mehrere Tage und jede Menge Nerven gekostet, das fasse ich ohne Zwang ganz sicher nicht nochmal an ...
/tom

[matt82]

Hi Tom,

habe deinen Ansatz mit der Konfiguration (driver_address="ws://192.168.1.2" ) einmal ausprobiert, leider hat es mit der websocket Verbindung trotzdem nicht geklappt.

Nachdem ich mich dafür entschieden habe, ausschließlich via Reverseproxy auf smartvisu zuzugreifen, habe ich nginx dahingehend konfiguriert, dass es für den shng - websocket einen eigenen TLS Port zur Verfügung stellt:

NGINX Config - Achtung - im Beispiel ist keine Absicherung über Passwort oder Client Zertifikat konfiguriert!

server {
listen 4424 ssl http2;
server_name 192.168.1.2

access_log /var/log/nginx/smartvisu-websocket_access.log;
error_log /var/log/nginx/smartvisu-websocket_error.log warn;

add_header X-Frame-Options "SAMEORIGIN";

# Certificates used
ssl_certificate CERTFILE.pem;
ssl_certificate_key KEYFILE.key;

ssl_protocols TLSv1.2 TLSv1.3;

ssl_ciphers EECDH+AESGCM:EDH+AESGCM:EECDH:EDH:!MD5:!RC4:!LOW:! MEDIUM:!CAMELLIA:!ECDSA:!DES:!DSS:!3DES:!NULL;

ssl_dhparam /etc/nginx/ssl/dhparam.pem;

ssl_ecdh_curve secp521r1:secp384r1;

# Server should determine the ciphers, not the client
ssl_prefer_server_ciphers on;

ssl_trusted_certificate TRUSTCERTFILE.pem;

# SSL session handling
ssl_session_timeout 24h;
ssl_session_cache shared:SSL:50m;

add_header Strict-Transport-Security "max-age=15768000; includeSubDomains" always;

add_header X-Content-Type-Options nosniff;
add_header X-XSS-Protection "1; mode=block";
add_header X-Robots-Tag none;
add_header X-Download-Options noopen;
add_header X-Permitted-Cross-Domain-Policies none;
add_header Referrer-Policy no-referrer always;

fastcgi_hide_header X-Powered-By;



## smartvisu-websocket
location = / {
# erlaube nur Websocket gegen "/"
if ($http_upgrade = websocket) {
proxy_pass http://YOURSHNGIPADDRESS:2424;
}

# sperre andere requests ...
if ($http_upgrade != websocket) {
return 403;
}

}

Nach der Aktivierung habe ich in der Konfiguration von smartvisu den Port von 2424 auf 4424 geändert - funktioniert.
Nachteil an der Lösung: unverschlüsselte Verbindungen zu smartvisu (http) funktionieren nun nicht mehr, da der konfigurierte Port 4424 TLS verwendet und keine unverschlüsselte http Verbindung.