Unfortunately, this is a problem that will never go away, no matter how slowly and gracefully we transition. There is no alternative that allows these devices to continue to operate without friction that doesn’t also enable current device manufacturers to kick the can down the road by releasing new HTTP-only devices.

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.

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.

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

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.

I didn't read anything in the article that said that HTTP will stop working, only that it'll be marked as not secure in the new Chrome. If you understand the security risks involved and are okay with continued use of bare HTTP, it shouldn't make any difference to you.

the future of IoT is HTTPS with client side X.509 authentication. you don’t need internet to make that happen. but if you are web based and not using HTTPS... i can only ask why not? internal CAs are free

Please tell me how to painlessly install a CA on a user their computer? Imagine buying a network connected coffeepot. You plug it in and you're done.

all you need is a certificate on the device and an app in the app store. or an installer they can download to their computer. you don’t need a full on traditional CA. you just need to verify (one) certificates.

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?

What app store? Which OS? Do you now suddenly have to write software for all OSes to install the certificate? Something that you didn't even have to think about doing before. The entire reason you went for a webui to begin with.

this is only in the pure local no internet case. with internet it’s a no-install plug in and done

you don’t need to install any certificates in any case. the server just needs to validate the client is well signed

User's webbrowser is visiting the appliance which resides on LAN. Webbrowsers require certificates signed by a CA.

i think you are misunderstanding the IoT flow. you don’t connect to devices

That is a generalization. You certainly do with many networked appliances. And I prefer this, since that means connectivity with the device is not dependent on some cloud service. And that some cloud service can't control my appliance.

OK, so in your example they create a certificate and use HTTPS and I'm unsure what the problem is.

And why would they think outside of their internet only box when they're providing an internet browser?

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.

It's definitely not impossible. Plex does it automatically: https://blog.filippo.io/how-plex-is-doing-https-for-all-its-...

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.

[1]: https://letsencrypt.org/docs/rate-limits/

[2]: https://letsencrypt.org/2017/07/06/wildcard-certificates-com...

Yeah, would be nice if ACME with DNS validation was widespread. But right now it's still not viable due to Let's Encrypt's rate limits.

It's fairly trivial to request a rate limit adjustment from Let's Encrypt[1].

[1]: https://docs.google.com/forms/d/e/1FAIpQLSetFLqcyPrnnrom2Kw8...

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.

> Or ship the device with the signed cert.

Certs expire sometimes. And the device doesn't necessarily have an internet connection. What then?

> It's impossible to get a valid SSL certificate for an appliance running within someone their lan

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.

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

> under their certificate authority delegation to *.coffeepot.com.

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.

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.

You can totally set up a domain for an IoT device that has restricted accessibility.