Moin,
gerne würde ich Stephan bei der Implementierung von TLS für MQTT Verbindungen unterstützen. Auf meinen vielen Bahnfahrten habe ich ja Zeit genug für solche Bastelarbeiten.
Was ich bis jetzt rausgefunden habe:
- MQTT verwendet DevIo.pm für die Verbindungsverwaltung.
- laut Doku soll der Eintrag $hash->{SSL}=1 dafür sorgen, dass die Verbindung verschlüsselt wird. (siehe auch frühere Anfrage (https://forum.fhem.de/index.php/topic,64358.0.html) hier)
- einen MQTT Broker, der verschlüsselte Verbindungen unterstützt und "echte" Zertifikate besitzt, habe ich betriebsbereit.
Was habe ich bisher probiert:
- in 00_MQTT.pm dafür gesorgt, dass im xxx_Define() der Wert $hash->{SSL} gesetzt wird
- der Verbindungsaufbau zu meinem MQTT Broker funktioniert auf port 1883 unverschlüsselt weiterhin
- der Verbindungsaufbau zu meinem MQTT Broker funktioniert auf port 8883 verschlüsselt noch nicht
Im mqtt Log des Brokers findet sich folgender Eintrag:
1528639332: New connection from <ipAddress> on port 8883.
1528639332: OpenSSL Error: error:140760FC:SSL routines:SSL23_GET_CLIENT_HELLO:unknown protocol
1528639332: Socket error on client <unknown>, disconnecting.
Der mqtt Broker unterstützt TLSv1.2
Ein ähnliches Verbindungsproblem hatte ich mit einem mqtt-Client auf meinem MacBook, solange ich den Parameter "SSL / TLS Version" auf "auto" stehen hatte. Nachdem ich diesen Wert fest auf TLSv1.2 gesetzt habe funktioniert der Verbindungsaufbau des Client problemlos.
Daraus ergibt sich meine Frage: Wie bekommt man DevIo.pm dazu, für eine bestimmte Verbindung fest TLSv1.2 zu verwenden. Das globale Attribut sslVersion kenne ich zwar, damit bin ich bisher aber nicht weitergekommen.
DevIo.pm ruft HttpUtils_Connect auf mit https://$dev/, falls SSL gesetzt ist, sonst mit http://$dev/
NAME und TIMEOUT wird passend weitergereicht. Natuerlich wird beim Aufruf aus DevIo.pm kein HTTP Header uebertragen.
In HttpUtils.pm wird das sslVersion Attribut zunaechst bei NAME, danach bei global gesucht, die Voreinstellung ist SSLv23:!SSLv3:!SSLv2. Das ist wohl noch die alte Variante, die Voreinstellung in TcpServerUtils ist seit Jahren TLSv12:!SSLv3. Wir sollten sie auch in HttpUtils aendern, bin nur unsicher, wer alles betreffen wird.
Wir reden aber bei mqtt nicht über http oder https Verbindungen - vielleicht liegt da schon eine Problemquelle
Zitat von: rudolfkoenig am 10 Juni 2018, 17:26:43
In HttpUtils.pm wird das sslVersion Attribut zunaechst bei NAME, danach bei global gesucht,
Andersrum :)
Zitat von: rudolfkoenig am 10 Juni 2018, 17:26:43
die Voreinstellung ist SSLv23:!SSLv3:!SSLv2.
...
Wir sollten sie auch in HttpUtils aendern, bin nur unsicher, wer alles betreffen wird.
Die Voreinstellung habe ich gerade in meiner Testinstallation geändert - ohne jegliche positive Auswirkung.
ZitatWir reden aber bei mqtt nicht über http oder https Verbindungen - vielleicht liegt da schon eine Problemquelle
Wie geschrieben, wenn HttpUtils aus DevIo.pm aufgerufen wird, dann wird nur der Verbindungsaufbau durchgefuehrt, ein HTTP Header wird nicht gesendet.
ZitatAndersrum
Haarspalter :). Im Endeffekt hat sslVersion in NAME Vorrang vor global.
ZitatDie Voreinstellung habe ich gerade in meiner Testinstallation geändert - ohne jegliche positive Auswirkung.
Ich habe dann erstmal keine weiteren Ideen.
Zitat von: rudolfkoenig am 10 Juni 2018, 17:50:58
Ich habe dann erstmal keine weiteren Ideen.
Und nun? Wie können wir weiter vorgehen, um die Aufgabe zu lösen?
Könnte sein, dass es ein Problem in der Broker-Konfiguration ist. Das Internet ist auch voll mit der angegebenen Fehlermeldung, aber eine wirkliche Lösung habe ich noch nicht gefunden.
Solle es ein Problem in der lokalen Broker-Konfiguration sein eignet sich auch https://test.mosquitto.org oder https://www.cloudmqtt.com um eine sichere Verbindung zu testen.
Grüße
Stephan
Es funktioniert aus FHEM heraus auch mit den angegebenen Test-URL nicht.
Auf der Konsole funktioniert
mosquitto_pub -h <fqdn> -t /carport/cp_Temp_T1/temperature -m "77" -p 8883 --capath /etc/ssl/certs/ -u "user" -P "password"
fehlerfrei. Also liegt es vermutlich nicht am Broker.
Wie/wo erfolgt in FHEM eigentlich die Zertifikatsprüfung für so eine Verbindung? Also die Prüfung des Zertifikats, mit dem sich der mqtt Broker (als Server) gegenüber FHEM (als Client) identifiziert?
ZitatWie/wo erfolgt in FHEM eigentlich die Zertifikatsprüfung für so eine Verbindung? Also die Prüfung des Zertifikats, mit dem sich der mqtt Broker (als Server) gegenüber FHEM (als Client) identifiziert?
SSL_verify_mode
This option sets the verification mode for the peer certificate.
The default (0x00) does no authentication. You may combine
0x01 (verify peer), 0x02 (fail verification if no peer
certificate exists; ignored for clients), and 0x04 (verify client
once) to change the default.
Ueber DevIo kann man keine sslargs uebergeben, nur ueber den direkten HttpUtils_NonblockingGet, bleibt also die Voreinstellung.