so the solution to the warning is to make your offline IoT devices secure, but how do you actually do that? i have an IoT product that runs a web server and needs to be accessible by users when the internet connection isn't available. how do I enable HTTPS on it? (this is not a hypothetical. it's a problem i actually need to solve)

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.

> install my CA cert as a trusted cert (which is not possible on iOS)

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...

> - distrubute a native (electron?) app that interfaces with my device and trusts my cert, and disallow direct browser access.

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.

> 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'm not sure how your comment is supposed to help.

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.

I have dnsmasq running internally and my regular Netgear router gives out the IP of that internal host as the dns resolver. Local hosts are given subdomain names for a domain I control (pi3.example.com camera.example.com seedbox.example.com etc) and resolve to an internal IP. These domains resolve, on the public internet, to the one publically-accessable host in my network. That machine runs certbot and gets the cert. It then rsyncs the certs to the internal machines every renewal.

They should be doing the same thing for Javascript then. Release a version of Javascript without the crappy bits and not run the old version of Javascript.