It's impossible to get a valid SSL certificate for an appliance running within someone their lan, without having to open ports. And opening ports would make the appliance even more vulnerable to attack.
Now that fully automated certificate issuance is becoming more mainstream (thanks to Let's Encrypt) I foresee this sort of thing becoming much more common in the future.
Unless I'm misunderstanding they did that by partnering with a CA. Becoming a semi-trusted CA themselves. This is not an option for most organizations.
That was only necessary because, at the time, there was no other way to get a large number of wildcard certs issued for their domain in an automated fashion.
With ACME that will no longer be the case. Let's Encrypt will allow you to do basically the same thing for free with ~20 devices a week[1] starting on February 27[2], for example. In the future, commercial CAs may choose to offer similar services with more relaxed rate limits.
It's possible, why not? Just use your own servers as a cert signing service for your IoT device as part of the bootstrap process if you are unwilling to have any services running on it. Or ship the device with the signed cert. You can have the host name in the DNS even though it's not accessible from everywhere.
> Can you not just create a certificate and push it to the system as a trusted cert?
If you were to control the user's machine, yes. But imagine you bought a shiny new internet connected coffee pot. Once you turn it on it does the following:
1. Coffeepot Determines its LAN IP address (e.g. 192.168.1.100)
2. Coffeepot connects to the coffeepot cloud service to register a dynamic DNS entry (e.g. user1.coffeepot.com) to point to its LAN IP address.
3. User is told they can access their coffeepot WebUI by going to user1.coffeepot.com, which resolves to 192.168.1.100
This is secure since the coffeepot can only be controlled if you are in the same network. Yet, since the coffeepot webui can only be reached if you are in its network, it is nearly impossible to get a valid SSL certificate on the coffeepot appliance.
> Presumably there is already some sort of communication going on if they're receiving Chrome updates.
There is a difference between outgoing network traffic and incoming network traffic. Only the latter requires open ports.
3. Coffeepot fails to connect to the cloud service because it's in some remote place with no internet.
Why does the coffeepot / TV / thermostat need internet access? That's often undesirable for the user (because that means the whole things breaks if the originating company goes away). Not to mention, how would the user know which host to connect to? How would the device get on WiFi if there is no way to enter the password?
I know Chromecast does this by making you download a custom application (Google Home on a phone, or Chrome on a desktop); that's not always practical.
I do think SSL in as many places as possible is great; I just also think they're trying to push for too much before solving the problems it will cause first.
It doesn't need it. You can always just nmap your network, find its lan ip and connect straight through that over http. But that's not very user friendly, hence the dyndns.
2.alternative: Coffeepot connects to the coffeepot cloud service to register a dynamic DNS entry (e.g. user1.coffeepot.com) to point to its LAN IP address and sends a Certificate Signing Request for user1.coffeepot.com?
If you are already registering a dynamic DNS, a CSR shouldn't be that much additional overhead?
Actually, now that I think about it, with the Let's Encrypt DNS challenge this might actually be viable... That's pretty recent, though. And they rate limit harshly. I was thinking about the HTTP validation, which would definitely fail, due to the DNS resolving to a LAN IP. Which a CA would obviously not be able to verify.
Right, that burden becomes coffeepot.com's. Supposedly they would already be doing due diligence to make sure that the dynamic DNS requests were from legitimate coffeepots that they themselves manufactured (rather than say the fraudulent activities of a botnet using their open DNS for communications). At that point they should also have enough security information to verify if they should sign a certificate presented to them by their manufactured coffeepot under their certificate authority delegation to *.coffeepot.com.
To my knowledge you can even piggy back off of ACME's protocol work from Let's Encrypt, even if the auth/validation checks are different for the different security models.
It's certainly possible to pay for such a thing today; many of our friends in Fortune 50+ companies have access to such things. You are right that we mere mortals with dreams of a tiny coffeepot IoT empire over HTTPS must hope for the post-Let's Encrypt era that the cost of such delegating certificate authority certificates drops in commensurate to other certificate types.
