Allow both SSL and non-SSL traffic with the http integration

Feature Requests
#1

For those of us with local push IoT devices that don’t support SSL, like the Ecowitt Weather Station, please enable webhook handling on the internal_url if SSL is enabled with the http configuration.

The Ecowitt integration used to use a dedicated listening port to handle the Ecowitt POSTs but has been updated to use webhooks. However that now requires the NGINX TLS Proxy Add-on which itself requires the MariaDB add-on. Not exactly a clean solution. Since the web UI is already available on the internal_url, it doesn’t seem like it would be much of a security issue.

#2

Mmm… Webhooks are not restricted to SSL, afaik. The doc even has a plain http example.
Probably some confusion somewhere

#3

Perhaps, but I traced the webhook registration and handling of the Ecowitt integration. It works fine if a webhook POST is made to the SSL port. But the same post made to the non-SSL port results in no callback to the integration code although the TCP connection is handled.

#4

It seems you make a generality from an Ecowitt issue, maybe?

You might open an issue towards the Ecowitt integration.
If you are then told to create a feature request, be specific that it is related to that integration, because the current title doesn’t make sense.

My suspicion is that it’s an Ecowitt limitation, though.
Which is even more confusing as the integration doc specifically say it doesn’t support SSL :thinking:

image

#5

Yes, the problem is that the Ecowitt device is not an SSL-capable HTTP client. However, any small embedded device can generate an HTTP POST using a sockets interface. I am making a generalized feature request so that these types of devices can be integrated into HA using webhooks. It is not an Ecowitt integration issue since that integration uses the HA webhook registration and callback methods. My requested change is to the HTTP websockets interface to allow /api/webhook requests to be handled on the internal_url socket without using SSL.

#6

Ok, so that should already work.
Any proof it doesn’t, out of the ecowit context, i.e. you tested it and it didn’t work?

#7

Well, here’s a Wireshark capture of the HTTP POST to the non-SSL port. No response from HA.

ecowitt-post2
ecowitt-post21581×920 392 KB

#8

You’re banging your head against some wall, here

image

image
image920×661 17.7 KB

#9

2023-06-12_111347
2023-06-12_111347737×241 85.2 KB

Do you have an http configuration entry enabling SSL on that port?

#10

Obviously not. You can only configure HA proper to have SSL or not, not both.

Maybe you are using some reverse proxy?

#11

OK, I think you’re missing the point here. This isn’t a bug report about webhooks not working. This is a feature request to enable webhooks on a non-SSL port if SSL is enabled. If today HA only responds to either SSL or not doesn’t mean it has to stay that way. Handling HTTP requests from multiple SSL and non-SSL ports is quite feasible–Apache has virtual hosts for that very reason. And HA currently knows enough right now to redirect a non-SSL request to the web configurator:

2023-06-13_080245
2023-06-13_080245994×311 65.7 KB

If you have something to say on the merits of this feature request, let’s hear them. For me, it generalizes the ability to use webhooks for simple IoT devices to pass data to HA. The developers can decide if this request is worthwhile or feasible.

#12

Ok, then your feature request is very wrongly formulated.
Webhooks are not using a special http handling, it’s the same as the main HA interface.

Your FR should be something like “Allows both SSL and non-SSL (so 2 ports) on the http integration”, which has merit and that I’ll happily +1.

#13

Changed the title.