Verschlüsselte lokale Kommunikation mit der Visu und smarthomeNG

[wvhn]

Die einschlägigen Foren sind voller (Halb-)Wissen zu TLS-Verbindungen und Zertifikaten. Trotzdem (oder gerade deswegen ?) habe ich Tage damit verbracht, eine verschlüsselte lokale Kommunikation mit smartVISU funktionsfähig aufzusetzen. "Lokal" bedeutet hier, dass ein selbstsigniertes Zertifikat benötigt wird und eben kein z.B. von Letsencrypt signiertes Zertifikat für eine DynDNS vorliegt. Mehrfach war ich kurz davor, aufzugeben .

Um Euch dieses Schicksal zu ersparen, hier mal eine kleine Doku für den Apache Webserver. Wer möchte, kann dies gerne für nginx ergänzen.

1. Selbstsigniertes Zertifikat erstellen:
   Dies ist hier gut beschrieben. Für den "Common Name" geben wir anstelle "localhost" die IP-Adresse des Webservers (i.d.R. der Raspberry, auf dem smartVISU läuft) an.
   .
2. Apache konfigurieren:
   Wie im oben verlinkten Blog beschrieben, wird das ssl-Modul aktiviert, und die ports.conf ergänzt. Die Datei für den virtual host benennen wir abweichend "html-ssl.conf". Diese muss folgenden korrigierten Code enthalten:
   

   	<virtualhost *:443>
   	 DocumentRoot /var/www/html
   	
   	 ErrorLog /var/www/html/log/error.log
   	 CustomLog /var/www/html/log/access.log combined
   	
   	 SSLEngine on
   	 SSLCertificateKeyFile /etc/apache2/ssl/sslcert.key
   	 SSLCertificateFile /etc/apache2/ssl/sslcert.crt
   	
   	 <directory /var/www/html>
   	
   	     Options Indexes FollowSymLinks
   	     AllowOverride All
   	     Require all granted
   	
   	 </directory>
   	</virtualhost>

   Die Datei muss nun noch aktiviert werden:
   

   	sudo a2ensite html-ssl

   Danach wird Apache2 neu gestartet:
   

   	sudo systemctl restart apache2

   Damit ist smartVISU jetzt per https erreichbar. Beim Aufruf im Browser erscheint ein Sicherheitshinweis, von dem aus man über "Erweitert" eine Ausnahme für das selbstsignierte Zertifikat festlegen kann. Allerdings erhält die Visu noch keine Daten, weil der Browser jetzt keine unverschlüsselte Websocket-Verbindung zu smarthomeNG mehr akzeptiert (Security Downgrade ist verboten).
   .
3. Websocket Protokoll wss:// aktivieren:
   Die beiden Dateien "sslcert.key" und "sslcert.crt" aus Punkt 1 werden in das Verzeichnis "/usr/local/smarthome/etc" kopiert. Von der .crt-Datei muss die Endung in .cer geändert werden. Dann wird im gleichen Verzeichnis die module.yaml editiert, um das Websocket-Modul zu konfigurieren:
   

   	websocket:
   	 module_name: websocket
   	 # ip: 0.0.0.0
   	 port: 2424
   	 tls_port: 2425
   	 use_tls: true
   	 tls_cert: sslcert.cer
   	 tls_key: sslcert.key

   Alternativ kann man die Dateien auch in "shng.key" und "shng.cer" umbenennen und damit die default-Namen des Websocket-Moduls nutzen.
   
   In der Konfiguration der smartVISU ist bei smarthomeNG vor die IP-Adresse "wss://" zu setzen (Beispiel: "wss://192.168.2.12") und der TLS-Port des Websocket-Moduls einzugeben (hier "2425").
   
   Ab hier bekommt der Edge-Browser bereits Daten vom Websocket (Chrome vermultlich auch), Firefox weigert sich aber hartnäckig, das selbstsignierte Zertifikat auch für den Websocket zu akzeptieren. Hierzu gibt man in der Browser-Zeile im Fall des Beispiels
   

   	https://192.168.2.12:2425

   ein und erhält dann wieder den Sicherheitshinweis, in dem man die Ausnahme bestätigt. Nun läuft die Visu vollständig in Firefox. In Safari reicht das offenbar noch nicht aus. Maßnahmen reiche ich nach.
   .

Als nächsten Schritt werde ich smartVISU so erweitern, dass sie die Vorteile des neuen Websocket-Moduls nutzt und ohne Konfigurationsänderung sowohl mit https: als auch mit http: arbeiten kann.

Gruß
Wolfram

[Sipple]

Guten Morgen

Hmm. Die Versuchung ist groß es so mal zu versuchen. Ich werde mal in mich gehen
Im Code Block zum Websocket hast du ganz unten bei tls_key: ssslcert.key noch ein s zu viel drin.

Gilt das "lokal" auch wenn ich per VPN von außen mit meinem lokalen Netz verbunden bin?

Gruß, Martin

[wvhn]

Danke. „sslcert“ ist korrigiert.

VPN habe ich nicht probiert. Sinn des VPN ist ja, dass man von außen über einen geschützten Tunnel ins Heimnetz kommt und dort Zugriff wie ein lokaler User hat. Deshalb wäre es einen Versuch wert, bringt aber keinen Sicherheitsgewinn.

Die Schritte sind reversibel. Man kann nichts kaputt machen, wenn man sich an das Vorgehen hält. Im Zweifelsfall den Websocket wieder auf ws:// und Port 2424 einstellen und die Visu nur per http:// aufrufen.

Gruß
Wolfram

[Msinn]

Hallo Wolfram,

Von der .crt-Datei muss die Endung in .cer geändert werden.

das muss man nicht tun. Man muss dann nur in der SmarthomeNG Konfiguration tls_cert: sslcert.crt angeben.

Ich überlege, ob es sinnvoll ist in der Konfiguration des Websocket Moduls die Zertifikate mit ganzem Pfad konfigurierbar zu machen. Dann könnte man direkt die Zertifikats-Dateien nutzen, die für den apache2 hinterlegt sind.

[wvhn]

Man muss dann nur in der SmarthomeNG Konfiguration tls_cert: sslcert.crt angeben.

Das ist natürlich noch besser. Ich wollte (aus Erfahrung nach meiner Odyssee) nur nicht an zu vielen Stellen gleichzeitig ändern.

Ich überlege, ob es sinnvoll ist in der Konfiguration des Websocket Moduls die Zertifikate mit ganzem Pfad konfigurierbar zu machen. Dann könnte man direkt die Zertifikats-Dateien nutzen, die für den apache2 hinterlegt sind.

Das wäre klasse, weil ein abgelaufenes Zertifikat dann nur an einer Stelle erneuert werden muss.

Gruß
Wolfram

[yachti]

Man muss dann nur in der SmarthomeNG Konfiguration tls_cert: sslcert.crt angeben.

Ich würde auch empfehlen auf die Endung .crt zu gehen. Damit ist man einheitlich zu anderen Apacche2 /nginx SSL Konfigurationen.
Grundsätzlich hat Msinn recht und die Endung spielt eine untergeordnete Rolle.

Ich überlege, ob es sinnvoll ist in der Konfiguration des Websocket Moduls die Zertifikate mit ganzem Pfad konfigurierbar zu machen.

Würde ich befürworten. Ich habe schon ein plugin wo ich das Zertifikat im plugin Verzeichnis ablegen muss. Schön wäre die Zertifikate nur an einer Stelle zu haben.

Gruß
Michael

[wvhn]

Im develop branch ist jetzt eine Version, die beide Ports des Websockets wahlweise anspricht:

• Bei HTTPS-Anforderung der Visu-Seite wird der TLS-Port des Websockets mit dem Protokoll WSS:// angesprochen
• Bei HTTP-Anforderung der Visu-Seite wird der "normale" Port mit dem Protokoll WS:// angesprochen
• Gibt man bei der IP-Adresse in der Config "wss://" vor der Adresse an, dann zwingt man den Websocket auf den TLS-Port mit verschlüsselter Kommunikation, auch wenn die Visu-Seite per HTTP aufgerufen wird
• Umgekehrt ist die Kombination aus HTTPS und WS nicht möglich, da der Browser ein Security Downgrade nicht zulässt.

Für Tester, die hier ihre Ergebnisse posten, bin ich dankbar.

Gruß
Wolfram

[ReviloEgros]

Habe gerade develop in ein neues Verzeichnis gecloned, konfiguriert und versucht meine Page zu laden. Ich bekomme leider keine Daten von FHEM und auf der Config Page ist unter Authentifizierung / Sicherheit nichts einzustellen.

27752C3A-756F-451D-807F-48D0FE3CBC73.png

[wvhn]

Danke fürs Testen. Ich arbeite noch daran, den leeren Authentifizierungsblock auf der config-Seite auszublenden. Den brauchst Du im fhem nicht.
Parallel habe ich die Treiber-Parameter als globale Variablen in JavaScript verfügbar gemacht und die Treiber umgebaut. Dabei habe ich in der init-Methode vom fhem-Treiber zwei Stellen übersehen. Sorry!

Das ist jetzt gefixt. Wenn Du nochmal pullst, sollte die Verbindung zum Backend wieder klappen.

Gruß
Wolfram

[ReviloEgros]

Kein Problem. Dachte nach dem ersten Pullen als nix ging es gäbe wieder etwas neues für die Config wofür man besser eine frische Installation nimmt und es deswegen evtl. nicht ging. Aber dafür hat man ja Backups 😂

Jetzt geht es wieder. Danke!

[henfri]

Hallo,

puh, wenn ich diesen Beitrag früher gesehen hätte, hätte es mir viel Zeit gespart. Das hab ich mir auch gerade erarbeitet
Danke für das Dokumentieren!

Bis hier hin war ich gekommen.

Ab hier bekommt der Edge-Browser bereits Daten vom Websocket (Chrome vermultlich auch), Firefox weigert sich aber hartnäckig, das selbstsignierte Zertifikat auch für den Websocket zu akzeptieren. Hierzu gibt man in der Browser-Zeile im Fall des Beispiels
Code:
https://192.168.2.12:2425
ein und erhält dann wieder den Sicherheitshinweis, in dem man die Ausnahme bestätigt. Nun läuft die Visu vollständig in Firefox. In Safari reicht das offenbar noch nicht aus. Maßnahmen reiche ich nach.

Den Trick kannte ich nicht. So funktioniert es bei mir mit dem Release auch.

Was aber leider noch inakzeptabel ist:
Firefox-Mobile "vergisst" die Ausnahme nach einem Browser-Neustart. In Windows ist das nicht so. Habt ihr das auch beobachtet?

Gruß,
Hendrik