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.
This sounds particularly bad. Was there a lot of dropped packets or did you find any other badness with 3G vs HTTPS?
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.
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.
What I learned by watching security videos and going to meetups:
As for the HTTPS overhead maybe the QUIC protocol will improve things.
"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.
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.
This is also the solution described in Datto blog.heckel.xyz/2018/08/05/issuing...
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.
Thanks for the feedback! Great to know that the article was helpful.
Do you mind sharing what kind of IoT project you're planning?
We will be attacked by an army of fridges soon.
We're a place where coders share, stay up-to-date and grow their careers.
We strive for transparency and don't collect excess data.