Think of LAN only IoT devices which aren't proxy through a external company site, have no domain, are accessed through (local area network IP) and maybe run in non internet environment.
I wish there was a solution for web based encryption for this application domain and browser vendors start to think out of their internet only box. ... same goes for service workers.
If we want to keep making the web a safer place, these kinds of cutoffs have to happen. Infinite backward compatibility simply holds everyone back for the sake of decreasingly-relevant devices and irresponsible manufacturers of new hardware and the customers who purchase their products.
The sooner we get to universal HTTPS the better.
as far as i can tell, my options are:
- install a self-signed cert on the device and force my users to click through all the warnings chrome throws up about untrusted certs
- create my own CA cert and sign the cert with that, and convince the user to install my CA cert as a trusted cert (which is not possible on iOS)
- get a cert signed by a trusted authority, and get the user to add an entry to their /etc/hosts file that maps the domain the cert is valid for whatever address the device is assigned
- distrubute a native (electron?) app that interfaces with my device and trusts my cert, and disallow direct browser access.
- find some sketchy SSL issuer who is willing to issue certs for *.local domains and run an mDNS resolver on my device
- Use HTTP instead of HTTPS and the only downside is a little badge in the address bar saying "not secure"
I'd love to have HTTPS everywhere, but i honestly don't know how to make it happen.
FWIW, unless we're talking about different things, you can install and trust custom CA certs on iOS. https://developer.apple.com/library/content/qa/qa1948/_index...
This is the most secure choice, using something like websockets to transfer data only.
Unless your product is completely offline and never connected to the internet, I don't think an IoT device that runs a web server is ever a good idea. All it takes is one successful remote attack, and soon your users could be installing ransomware at the device's direction!
Don't serve HTML/JS from a device that you can't physically pull the plug on.
Or virtually pull the plug, in the case of cloud hosted sites.
I don't think a web server is ever a good idea. All it takes is one successful remote attack and soon your users could be installing ransomware! We'd better shut down the internet.
As long as it's a “Not Secure” omnibox warning, I don't see it as a problem even there. Now, if they adopted the “block with non-obvious escape hatch” approach used for certificate errors for HTTP, that would be a problem.
sign the certificate in the manufacturing plant and put it in the coffee maker l. give the CA cert out in the app or the installer. now you can verify if the coffee maker talking to you over HTTPS is legit and probably get it’s serial number off the cert too. your CA keys never see the public. you could go even more secure and use that as a bootstrap to a per customer CA and generate a new cert on install, but this is a coffee maker right?
you don’t need to install any certificates in any case. the server just needs to validate the client is well signed
And why would they think outside of their internet only box when they're providing an internet browser?
Can you not just create a certificate and push it to the system as a trusted cert?
> And opening ports would make the appliance even more vulnerable to attack.
Presumably there is already some sort of communication going on if they're receiving Chrome updates.
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.
If you are already registering a dynamic DNS, a CSR shouldn't be that much additional overhead?
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.
Where can I get a certificate with the CA flag set for mydomain.com? I did not know this was an option for mere mortals.
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.
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.
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.
[1]: https://letsencrypt.org/docs/rate-limits/
[2]: https://letsencrypt.org/2017/07/06/wildcard-certificates-com...
[1]: https://docs.google.com/forms/d/e/1FAIpQLSetFLqcyPrnnrom2Kw8...
Certs expire sometimes. And the device doesn't necessarily have an internet connection. What then?