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