Setting Up a Honeywell T10+ Smart Thermostat
I don’t like IoT, but sometimes the benefits outweigh the risks…if it’s done correctly.
Setup
Physical Location
- Try to install the main thermostat in a central location that will get the best average temperature for the first floor.
- If running new thermostat wiring, make sure to use 18/8 and not 18/2. Even though it will only use two wires, good to future-proof in case Honeywell gets dropped like it’s hot.
- Ensure that the outdoor temperature sensor is in a spot where it will have minimal direct contact with the sun or wind.
Network
- Since this is IoT, it’s recommended to create a new VLAN and segment it from anything else on the network. If there aren’t enough SSIDs available on the access points, then ensure that client isolation is enforced so that all traffic goes to the gateway.
- Ensure that DHCP services are enabled on the VLAN and that there’s a static reservation for the thermostat.
Firewall Rules
DNS
Create a rule to the desired DNS server on UDP 53. The thermostat will take direction from DHCP.
Web Services
Create a firewall rule permitting the thermostat to access the following hosts on TCP 443 with the SYN flag:
- weather02.clouddevice.io (observed)
- provprod02.clouddevice.io (observed)
- fwuprod02.clouddevice.io (observed)
AMQP over TLS
Create a firewall rule permitting the thermostat to access the following hosts on TCP 5671 with the SYN flag:
- lcc-prodsf-lcc03sf-iothub.azure-devices.net
Homekit/HomeAssistant Integration
If desired, create two firewall rules permitting the thermostat to communicate with Homekit/HomeAssistant using multicast:
- Protocol UDP, destination IP address 224.0.0.251, port 5353
- Protocol IGMP, destination IP address 224.0.0.251
Note that a relay will be necessary if the automation appliance is on another subnet (which it should be).
The Deets
After doing tons of research and weighing options and cost (and using my “contractor” accounts), I decided on the T10+ from Resideo. The problem is, I hate IoT. The security around the majority of these things is the equivalent of putting a glass window in a steel reinforced door. However, I need it for a number of home automation tasks that make things easier while traveling. Risk vs. reward.
On boot, the device starts with two LLC broadcasts:
The device MAC address identifier is registered to Resideo. The DHCP request demands the following parameters:
The device doesn’t request an NTP server at all. There’s also no firewall activity over UDP 123, so it looks like NTP is not used.
Vendor class identifier is Resideo.
Interesting that the device is requesting an infinite lease in option 51. In terms of dynamic leases, this is a very bad idea as it can exhaust the address pool. I’m using a static lease and my DHCP server refuses it, so the risk is mitigated, but shame on you Resideo.
The device then attempts to discover IPv6 routes.
Followed by numerous attempts at MDNS queries over both IPv4 and IPv6:
Now that the pleasentries are out of the way, time to start connecting to Resideo. The first connection is to Resideo’s device provisioning services using HTTPS. The cipher quites are unremarkable.
Now this is interesting. The SNI in the client hello states “pki.resideo” …
The server provides certificates and picks its cipher suite:
The server does request a certificate from the client, so authentication is two-way:
Subsequent TLS connections follow the same pattern and handshake, including the AMQPS connection. I’ll have to dig into it further at some point, but for now I have a million other things to do. Exactly one million. No more, no less.
Sources
- https://buildings.honeywell.com/content/dam/hbtbt/en/documents/downloads/Pro-Watch_CIP%20V7%20Letter%202022_05.pdf
- https://prod-edam.honeywell.com/content/dam/honeywell-edam/hbt/en-us/documents/manuals-and-guides/reference-guides/31-00131.pdf
- https://prod-edam.honeywell.com/content/dam/honeywell-edam/hbt/en-us/documents/manuals-and-guides/user-manuals/HBT-BMS-31-00452M-SaMBa-Cybersecurity-Manual.pdf