On 10/09/2016 07:31 AM, Mel Beckman wrote:
remote RF temperature sensor hub for home, the GW-1000U. ... The device accepts TCP connections on 22, 80, and 443. Theoretically I can't see why it ever needs ongoing inbound connections, so this seems to be a security concession made by the maker. Also, it appears to support SSL, but uses plaintext. Why? Because it's easier to debug in the early deployments, I'll wager. But the thing has been out for years and they're still not using encryption, even though the device apparently has the ability.
I could see one reason, and one reason only: to allow the customer to use a "control panel" with a local computer, smartphone app, or tablet app to set capabilities, options, and preferences. That said, the manufacturer probably thought that the sensor would be shielded from the Internet by a Wireless Access Point with NAT, so that there would be no direct exposure (in theory) to inbound connections from the outside world. For IPv4, this is barely tolerable. For IPv6, not so much. As a developer, I can tell you that "easier to debug in the early deployments" means that the later deployments won't be locked down until the manufacturer gets a fine, judgement, or other monetary hit. Would you put this thing on a DMZ? I thought not... :)