Traduit de English par IA ·
Ça masque la destination à quelqu’un qui surveille la liaison du dépôt, oui, Rahul. Mais la destination n’a jamais été le secret, et Tor vous coûte de vraies choses côté Hermetry.Ce qui vous protège réellement aujourd’hui : la session MQTT utilise au minimum TLS 1.2 avec des suites à confidentialité persistante, donc le contenu et le jeton de l’appareil ne sont pas lisibles sur le réseau. Quelqu’un qui écoute la liaison montante du dépôt apprend seulement qu’un appareil parle à un broker toutes les N secondes. Tor masque le nom du broker, mais ajoute beaucoup de latence et de renouvellements de connexion.Maintenant les coûts. Chaque circuit Tor sort par une adresse différente. Hermetry envoie à vos administrateurs une notification lorsqu’un appareil se connecte depuis un nouveau réseau (au plus une fois par heure et par appareil). Si 9 nœuds changent de sortie en permanence, vous recevez un flux continu de ces notifications, et vous habituez les gens à ignorer précisément l’alerte qui leur indiquerait qu’un jeton a été volé. Vous perdez aussi l’option « Réseaux autorisés » du profil, l’un de vos meilleurs contrôles pour les appareils à site fixe : si vous y indiquez l’adresse publique du dépôt, un jeton volé utilisé ailleurs reçoit CONNACK 5. De plus, les connexions échouées répétées bloquent une adresse pour chaque appareil situé derrière elle, et sur des sorties partagées, vous n’avez aucune maîtrise là-dessus.Si le patron en veut davantage, je ferais plutôt ceci, tout dans le profil de l’appareil :
- Réseaux autorisés : l’adresse IP publique du dépôt
- TLS uniquement, Jeton dans l’URL désactivé, Commandes autorisées sans TLS vide
- passer des jetons d’accès à X.509 si votre firmware le permet, sinon MQTT basic, un identifiant par appareil
- abaisser les Limites du profil à ce que les nœuds envoient réellement, pour qu’un nœud détourné soit coupé rapidement
Et placez les ESP32 dans leur propre VLAN afin qu’un nœud compromis ne puisse pas atteindre les PC du bureau. La liste de contrôle se trouve sur Device transport security.
It hides the destination from someone watching the depot line, yes, Rahul. But the destination was never the secret, and Tor costs you real things on the Hermetry side.
What actually protects you today: the MQTT session is TLS 1.2 minimum with forward-secret suites, so contents and the device token aren’t readable on the wire. Someone sniffing the depot uplink learns there’s a device talking to a broker every N seconds. Tor hides the broker name and adds a lot of latency and connection churn.
Now the costs. Every Tor circuit exits from a different address. Hermetry sends your admins a notice when a device logs in from a new network (at most once an hour per device), so 9 nodes hopping exits means a steady stream of those, and you train people to ignore exactly the warning that would tell them a token was stolen. You also lose the profile’s Allowed networks option, which is one of the best controls you have for fixed-site devices: list the depot’s public address and a stolen token used from anywhere else gets CONNACK 5. Plus repeated failed logins block an address for every device behind it, and on shared exits that’s not under your control.
If the boss wants more, I’d do this instead, all on the device profile:
- Allowed networks: the depot’s public IP
- TLS only, Token in the URL off, Commands allowed without TLS empty
- move from access tokens to X.509 if your firmware can, otherwise MQTT basic, one credential per device
- lower the profile Limits to what the nodes really send so a hijacked one gets cut off fast
And put the ESP32s on their own VLAN so a compromised node can’t reach the office PCs. Checklist is on Device transport security.