Démon Zigate ne démarre pas si accès interne en https

Plugins Protocole domotique
1

Jeedom 4.1.20
Version plugin : 1.7.6
Version lib : 0.40.11
Version firmware : 3.1d

Bonjour, mon jeedom fonctionne bien en http(s) depuis l’extérieur ou l’intérieur (certificat letsencrypt). La partie SSL est gérée par haproxy. La com haproxy <-> jeedom est en http sur un réseau docker bridge.
Cependant, en configurant Jeedom : « Config »->« Réseaux »->« Accès interne » en https, le démon du plugin ne démarre plus (cf logs plus bas). Le démon semble vouloir se connecter à Jeedom en SSL également, sachant que des erreurs SSL sont possibles si l’URL ne colle pas avec le certificat serveur présenté (j’utilise l’adresse IP locale en interne), ou si le serveur présente un certificat auto-signé (test avec sujet du certificat correspondant à l’IP du serveur en local).
Quels sont les retours d’expérience sur des jeedom en https en interne ? Je ne dois pas être le seul dans ce cas, non ?

Fred.


*Traceback (most recent call last):*
*File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 600, in urlopen*
*chunked=chunked)*
*File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 343, in _make_request*
*self._validate_conn(conn)*
*File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 841, in _validate_conn*
*conn.connect()*
*File "/usr/lib/python3/dist-packages/urllib3/connection.py", line 344, in connect*
*ssl_context=context)*
*File "/usr/lib/python3/dist-packages/urllib3/util/ssl_.py", line 357, in ssl_wrap_socket*
*return context.wrap_socket(sock)*
*File "/usr/lib/python3.7/ssl.py", line 412, in wrap_socket*
*session=session*
*File "/usr/lib/python3.7/ssl.py", line 853, in _create*
*self.do_handshake()*
*File "/usr/lib/python3.7/ssl.py", line 1117, in do_handshake*
*self._sslobj.do_handshake()*
*ssl.SSLError: [SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1056)*
*During handling of the above exception, another exception occurred:*
*Traceback (most recent call last):*
*File "/usr/lib/python3/dist-packages/requests/adapters.py", line 449, in send*
*timeout=timeout*
*File "/usr/lib/python3/dist-packages/urllib3/connectionpool.py", line 638, in urlopen*
*_stacktrace=sys.exc_info()[2])*
*File "/usr/lib/python3/dist-packages/urllib3/util/retry.py", line 398, in increment*
*raise MaxRetryError(_pool, url, error or ResponseError(cause))*
*urllib3.exceptions.MaxRetryError: HTTPSConnectionPool(host='127.0.0.1', port=80): Max retries exceeded with url: /plugins/zigate/core/php/jeeZiGate.php?apikey=guLDGOT9lj4AnwXutRFf4jJWR8OHx7r6 (Caused by SSLError(SSLError(1, '[SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1056)')))*
*During handling of the above exception, another exception occurred:*
*Traceback (most recent call last):*
*File "/var/www/html/plugins/zigate/core/class/../../resources/zigated/zigated.py", line 297, in <module>*
*if not jc.test():*
*File "/var/www/html/plugins/zigate/core/class/../../resources/zigated/zigated.py", line 81, in test*
*r = self.send_now({'action': 'test'})*
*File "/var/www/html/plugins/zigate/core/class/../../resources/zigated/zigated.py", line 77, in send_now*
*return self._request(message)*
*File "/var/www/html/plugins/zigate/core/class/../../resources/zigated/zigated.py", line 64, in _request*
*verify=False)*
*File "/usr/lib/python3/dist-packages/requests/api.py", line 116, in post*
*return request('post', url, data=data, json=json, **kwargs)*
*File "/usr/lib/python3/dist-packages/requests/api.py", line 60, in request*
*return session.request(method=method, url=url, **kwargs)*
*File "/usr/lib/python3/dist-packages/requests/sessions.py", line 533, in request*
*resp = self.send(prep, **send_kwargs)*
*File "/usr/lib/python3/dist-packages/requests/sessions.py", line 646, in send*
*r = adapter.send(request, **kwargs)*
*File "/usr/lib/python3/dist-packages/requests/adapters.py", line 514, in send*
*raise SSLError(e, request=request)*
*requests.exceptions.SSLError: HTTPSConnectionPool(host='127.0.0.1', port=80): Max retries exceeded with url: /plugins/zigate/core/php/jeeZiGate.php?apikey=guLDGOT9lj4AnwXutRFf4jJWR8OHx7r6 (Caused by SSLError(SSLError(1, '[SSL: WRONG_VERSION_NUMBER] wrong version number (_ssl.c:1056)')))*
*[2021-03-06 20:08:03][ERROR] : Impossible de lancer le démon zigate, relancer le démon en debug et vérifiez la log*
2

J’ai peut-être en partie la réponse : l’erreur SSL WRONG_VERSION_NUMBER me suggère un pb de version d’OpenSSL : je force Haproxy à n’accepter que TLS 1.3… Je ferai un test en assouplissant ma config Haproxy pour accepter TLS 1.2
Fred

3

Hello

Tu es sur que ton coup ?
Parce qu’à regarder la log, quand je lis ça

(host='127.0.0.1', port=80)

Je vois pas bien ni comment ça passe par ton proxy (encore plus avec docker), ni comment ça fait du https

4

Hmm… j’ai dû mal configurer Jeedom en interne en voulant générer les logs : j’avais laissé le port sur 80 tout en mettant https. Cependant, j’ai bien un soucis en https port 443 en interne, même avec haproxy avec une conf ssl permissive : le démon ZiGate tente d’ouvrir https://127.0.0.1:443.
Cette fois, j’ai compris l’erreur : c’est mon proxy qui sécurise la connexion, pas jeedom. Du coup, mon Jeedom ne dispose pas de https sur localhost et 127.0.0.1, par la loopback.
La page de configuration de Jeedom dit : « cette configuration n’est là que pour informer Jeedom de sa configuration réseau et n’a aucun impact sur les ports ou l’IP réellement utilisés pour joindre Jeedom ». Le plugin « Mobile » utilise les adresses interne et externe pour configurer les smartphones, donc joindre jeedom à travers tous les équipements réseau. Le plugin « Zigate » utilise cette même configuration pour la loopback (protocole et port). Du coup, on tombe sur deux interprétations d’une même configuration.

5

Exactement. Sur le principe sécuriser le loopback c’est techniquement possible, mais c’est pas vraiment utile (ça transite pas vraiment sur le réseau)

Oui et non. Ça veut juste dire que les composants jeedom et les plugins (les daemons) se contrefichent de ces informations. Par contre elles sont peut-être nécessaires pour qu’on puisse accéder au plugin.
Dans le cas du plugin mobile, il utilise ces deux adresses pour pousser la bonne configuration sur le client mobile (via le qrcode)… Mais pour interagir avec jeedom ça passe par l’ip local ou le loopback.

Pour zigate, ça m’étonnerai que ce soit différent (127.0.0.1 c’est forcément en dur ou défini dans la configuration du plugin). Et le plugin n’a de toute façon pas besoin de passer par ha pour joindre Jeedom, il est sur la même machine…
Mais n’ayant ni le plugin chez moi, ni ta conf sous les yeux (ouais comme quoi ça sert) il y a peut-être un truc

6

Merci de t’intéresser à mon pb :slight_smile:. Je suis d’accord avec toi, pas besoin de sécuriser la loopback. Cependant, si j’avais modifié la conf Apache de Jeedom pour ouvrir le port 443 en SSL, la loopback aurait pu également bénéficier du SSL. Dans ma configuration, Apache reste en http port 80, car il faudrait modifier une conf sur mon container Docker Jeedom, qui ne sera perdue si je recréé mon container, et comme je souhaite héberger plusieurs services chez moi et tout faire passer par le proxy, pas besoin de sécuriser entre proxy et services.
Il y a donc bien un problème avec le plugin Zigate : ce dernier utilise l’ip de la loopback en dur, mais utilise le protocole et le port de la conf réseau de Jeedom.

7

Ça je suis pas totalement sûr… Sauf erreur 80 que l’on voit dans les logs, ça semble pas vraiment lié à ce que tu aurais du avoir configuré dans jeedom…pour avoir du SSL en interne via le ha.
Mais bon ça manque de détails concrets avec les conf pour être certain

Techniquement oui. Mais aucun bénéfice sauf à être plus consommateur de ressources et d’augmenter la latence

8

Je vais résumer un peu car on ne se comprends pas complètement:

Conf réseau Jeedom => Plugin Zigate => Démon Zigate

http 192.168.1.2 80 => http 127.0.0.1 80 => OK
https 192.168.1.2 80 => https 127.0.0.1 80 => NOK
https 192.168.1.2 443 => https 127.0.0.1 443 => NOK

On voit bien que le plugin utilise le port et le protocole de la conf réseau pour accéder à Jeedom à travers de la loopback. Dans un cas simple ça passe, mais dans ma conf où c’est le (reverse)proxy qui fait le SSL, ça ne peut pas marcher. Il manque une brique de conf qui dit au plugin Zigate comment joindre jeedom via la loopback (port et protocole).

9

Je pense avoir bien compris ce que tu présupposes, juste qu’il manque quand même les conf (jeedom et plugin) et les traces (plugin) de tes 3 tests…

Dans tes messages/exemples, il n’y a que le 2eme cas… et qui n’aboutie pas… et qui est probablement le moins représentatif (tout est hybride)

Si c’est les bonnes config et les bons logs, alors oui c’est probablement un bug… Mais bon il faut étayer un poil plus… Tu as pas forcement tord sur le diag, mais au moins ça lèvera les doutes restants coté dev

10

Je n’ai pas mis les logs avec tout car on est plutôt face à un problème de design et que comme je suis nouveau sur le site, je ne peux pas mettre en pièces jointes les logs avec les 3 cas. Je ne voulais donc pas noyer mes messages de logs :-).
Pour contourner le pb, j’ai configuré l’accès interne en http. Comme ça, le plugin ZiGate arrive bien à se connecter via la loopback en http. Pour l’appli jeedom sur les mobiles, elle sera redirigée par le proxy qui renvoie les connexions http vers https.

11

Tu as les balises </> pour les logs qui sont parfaitement adaptées

12

Merci pour ton aide !