DEV Community

Cover image for Where is HTTPS for IoT? (Update)

Where is HTTPS for IoT? (Update)

Daniel Albuschat on September 10, 2018

Updated, 10/22/2018: Added proposal 1.a, with added HTTP Public Key Pinning By now everyone should know that HTTPS is secure, and that HTTPS is im...
Collapse
 
jimsy profile image
James Harton

I’ve run into a situation where we had devices sending payloads over HTTPS every 30 seconds over a cellular 3G connection. We wound up disabling HTTPS because the SSL overhead greatly increased payload size and latency. In our case the payload size meant the difference between a $100/month per device data cost vs a $3000/month per device cost. I wasn’t part of the original engineering team that chose HTTP for the transport otherwise I would have investigated messagepack over UDP or something more sensible. The problem isn’t that HTTPS isn’t baked in but that engineers are making poor protocol choices and security is an important part of that decision. In our case the data was ephemeral and had a short usefulness lifetime but your case may differ.

Collapse
 
andrewlucker profile image
Andrew Lucker

This sounds particularly bad. Was there a lot of dropped packets or did you find any other badness with 3G vs HTTPS?

Collapse
 
jimsy profile image
James Harton

These devices are installed in vehicles on rural roads so you can assume that we saw every conceivable kind of connectivity issue but bill shock was of the most importance to the client.

Thread Thread
 
andrewlucker profile image
Andrew Lucker • Edited

Countries have a bunch of satellites that transmit data unencrypted... not like it is all top secret, but TLS is not an option. There are so many different reasons why TLS breaks, and stock TCP can be horribly inefficient for different use cases.

Just a bit curious, since cellular ~3G transport is probably going to get a lot more common in the next few years.

Collapse
 
bgadrian profile image
Adrian B.G.

What I learned by watching security videos and going to meetups:

  • do not open any port on your IoT devices, not even a web server, is an invitation "hack me", I've seen how they hack real cars by using the wifi, bluetooth or worse had them run a .sh from the USB stick
  • do not allow users to upload anything on your devices, especially firmware, you will lose the control over them

As for the HTTPS overhead maybe the QUIC protocol will improve things.

Collapse
 
dipeshs32800497 profile image
Dipesh sapkota

Thank you for sharing, loved your article.
Hope to see more article on IOT as I am currently getting started with IOT ,also it has awared me about the security flaws in IOT device.

learned

Collapse
 
danielkun profile image
Daniel Albuschat

Thanks for the feedback! Great to know that the article was helpful.
Do you mind sharing what kind of IoT project you're planning?

Collapse
 
andrewlucker profile image
Andrew Lucker • Edited

"I'm not a security expert, so please bear with me if you find information that may appear to be not totally correct or incomplete."

Assessing the validity of statements regarding security is fairly simple: assume that the first and all following assertions are false.

Collapse
 
stevebroshar profile image
Steve Broshar

Great article. Very helpful. Another aspect for IoT/devices seems to be expiration period. A cert has a maximum life of just over 2 years. Once our device is fielded there no way for us to update the cert and the user won't want to manage that either. Is this a common problem? Are there common solutions?

Collapse
 
bbasile profile image
Basile B.

We will be attacked by an army of fridges soon.

Collapse
 
oclyke profile image
Owen

It's well after midnight and this party is still going! Great article. I am facing this issue with a product that is meant to form its own network when no others are available. Trust is the core of the issue and preventing is from using an otherwise beautiful, secure, cutting edge environment at every level.

Is anyone working on this problem? I would like to further explore ways to establish trust that don't depend on a public internet connection. Obviously mass adoption of any solution won't arrive in time for our project but it would be great to see this use case covered for future devs!

Collapse
 
krusenas profile image
Karolis

Hi Daniel, thanks for the mention :) I am the creator of Webhook Relay.

Recently I explored IoT area as well and thought about ways I could help other engineers/developers/admins. The main problem in running a public reverse proxy I guess is trust, therefore I added a new feature - TLS pass-through without the termination on the public server side.

Currently I only created an addon for Home Assistant (webhookrelay.com/v1/guide/home-aut...) which auto generates locally a DuckDNS certificate and can even do TLS termination on the device if the web server doesn't support it. It makes it quite easy to deploy.

However, ideally the web server that user runs should generate the certificates using Let's Encrypt DNS challenge so they could not trust proxy provider at all :)

Another useful feature would be doing IP whitelisting on the public server side, although it can become less useful if the user has dynamic IP (goes to a cafe and uses a wifi).

Also, when a device just needs to receive webhooks and doesn't need to respond, a safest way would be to use webhook forwarding (webhookrelay.com/v1/guide/webhook-...) where traffic is going only one-way and only to a specific URL path (for example: /v1/webhook). This way attacked would have to know exactly what kind of web server is on the other end + that HTTP handler would have to be exploitable.

Collapse
 
brnvrn profile image
Bruno Vernay

This is also the solution described in Datto blog.heckel.xyz/2018/08/05/issuing...