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...
For further actions, you may consider blocking this person and/or reporting abuse
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.
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
Thanks for the feedback! Great to know that the article was helpful.
Do you mind sharing what kind of IoT project you're planning?
"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.
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?
We will be attacked by an army of fridges soon.
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!
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...