home-assistant
Ecowitt Integration - HTTPS requirements non functional
The problem
Duplicate of https://github.com/garbled1/homeassistant_ecowitt/issues/154
I'm running HA Blue hardware w/ HASS and want to use HTTPS to make Ecowitt plugin (core) work.
Since the plugin went into core HA the TLS/SSL was dropped and the requirement is to use NGINX to reverse proxy HTTPS > HTTP.
Before I had port 4199 > 4199 forwarded(at the router) to the HA Blue box and it was working fine (using custom plugin). I modified the new path to match the path specified by the plugin at time of installation/configuration and I have no data coming through and no errors in the logs.
Given that I expose https for core without a plugin what are my options here?
Related to https://github.com/garbled1/homeassistant_ecowitt/issues/149 but I wanted to create a new issue to remove the noise
What version of Home Assistant Core has the issue?
core-2023.5.2
What was the last working version of Home Assistant Core?
n/a
What type of installation are you running?
Home Assistant OS
Integration causing the issue
Ecowitt
Link to integration documentation on our website
https://www.home-assistant.io/integrations/ecowitt/
Diagnostics information
No response
Example YAML snippet
No response
Anything in the logs that might be useful for us?
No response
Additional information
No response
Hey there @pvizeli, mind taking a look at this issue as it has been labeled with an integration (ecowitt) you are listed as a code owner for? Thanks!
Code owner commands
Code owners of ecowitt can trigger bot actions by commenting:
@home-assistant closeCloses the issue.@home-assistant rename Awesome new titleRenames the issue.@home-assistant reopenReopen the issue.@home-assistant unassign ecowittRemoves the current integration label and assignees on the issue, add the integration domain after the command.
(message by CodeOwnersMention)
ecowitt documentation ecowitt source (message by IssueLinks)
![home-assistant[bot] avatar](https://avatars.githubusercontent.com/in/97978?v=4 "Published by a pub.dev verified publisher"){kind=small}
The requirement to use NGINX proxy is a step backward and a security issue. The custom integration was able to expose a specific port for a specific purpose and not expose 8123 over HTTP. Even local I do not consider exposing my entire HA instance over HTTP acceptable.
This integration should be reworked to support HTTP without exposing all of HA via HTTP like the HACS version did.
This integration should be reworked to support HTTP without exposing all of HA via HTTP like the HACS version did.
Is this accurate @veilofsecurity - It doesn't change your point but I think the above statement includes mistakes? I think it's meant to say
- "This integration should be reworked to support HTTP for a specific purpose without the requirement to expose all of HA".
and/or (and this is for my use case).
- "This integration should be reworked to support ecowitt where HA is exposed via core HTTPS handlers and not require Nginx reverse proxying.
They are two separate approaches. You'd of thought 2) would be supported "out of the box" given that it was implemented for hass.io.
My wording about HACS was definitely ambiguous and your 1 clarifies the meaning. Your 2 wont work because the Ecowitt gateways only support HTTP and I doubt they will be updated anytime soon, if ever.
There are 3 options:
- Best - Ecowitt updates to support HTTPS and we use the native integration as is.
- Better - HA makes the integration expose an HTTP port whose only function is to ingest from Ecowitt. This is what HACS did and doesnt make all of HA available via HTTP which is unacceptable in my opinion.
- Not great - Expose HA via HTTP allowing Ecowitt to send to the integration. Use NGINX Rev Proxy to enable HTTPS for HA for your everyday use, mobile apps, etc.
For now I am continuing to use the HACS integration with the line 21 code fix but I dont expect that integration to work forever as it seems to now be unmaintained. I would like to see option 2 implemented in the official integration or I am open to othet ideas if I've missed something.
Where could I vote for option "1. Best" from previous post from @veilofsecurity ? :-)
For now I am continuing to use the HACS integration with the line 21 code fix
Given the situation I might be forced to do the same ;( Can you please link to the line 21 code fix?
I suppose it's this one: https://github.com/garbled1/homeassistant_ecowitt/issues/149#issuecomment-1535912016
Skimming through the code it looks like the port for the webhook could be made configurable? https://github.com/home-assistant/core/blob/3fbc026d5a3dbee78778ed42548a0c2d9c0d026c/homeassistant/components/ecowitt/config_flow.py#L46
My GW1000 seems to support adding different ports, just not using HTTPS over whatever port is selected.
Given that option 1 is extremely unlikely to happen (since that would require ecowitt to add the function and this does not seem likely), option 2 would make most sense. It also is the easiest for existing ecowitt users to migrate to.
Funny thing is that when installing the new Ecowitt integration after deleting all of the old HACS-originated stuff, it talks about finding an open port and even suggest 4199 which is what the old HACS ecowitt integration used - but it obviously does not actually support listening on 4199...
Just ran into this issue with a new weather station. Option 2 seems the most reasonable to me as well, because I also don't want to expose the rest of HA on HTTP. And option 1 is out of our control.
Is it not possible meanwhile a workaround, like writing a different port number in a config file? Or, for instance, can core/homeassistant/components/ecowitt/config_flow.py code file be edited for this type of "hacking"?
Just ran into this issue with a new weather station.
Add me to the list 🙃
Option 2 seems the most reasonable to me as well, because I also don't want to expose the rest of HA on HTTP. And option 1 is out of our control.
Solid agree. 😄
I also recently struggled with setting up simultaneous:
- HTTPS secure web browser access via NGINX proxy
- HTTP webhook access direct to home assistant
I made a guide on how I solved my issue if anyone else is currently lost: https://community.home-assistant.io/t/nginx-tls-proxy-add-on-config-to-allow-simultaneous-https-and-http-access-required-by-ecowitt-integration/589276
Thank you very much @del13r for your excellent guide, very useful to make ecowitt devices working again with home assistant (hoping that in the next future the integration will also allow us to choose the http port number listening for ecowitt messages)
I also recently struggled with setting up simultaneous:
- HTTPS secure web browser access via NGINX proxy
- HTTP webhook access direct to home assistant
I made a guide on how I solved my issue if anyone else is currently lost: https://community.home-assistant.io/t/nginx-tls-proxy-add-on-config-to-allow-simultaneous-https-and-http-access-required-by-ecowitt-integration/589276
@del13r Can you please confirm if your solution will work for Home Assistant OS users IE users who purchased Home Assistant Blue hardware and have a managed operating system?
My solution uses 2 addons. For that reason, if you are running Home Assistant Operating System, you WILL be able to install the addons. If you are running Home Assistant Container, you will NOT be able to install addons.
On this page https://www.home-assistant.io/installation it says:
If you are using the Home Assistant Blue, the Home Assistant Operating System is already installed.
I am confident the solution should work for you as well.
Skimming through the code it looks like the port for the webhook could be made configurable?
https://github.com/home-assistant/core/blob/3fbc026d5a3dbee78778ed42548a0c2d9c0d026c/homeassistant/components/ecowitt/config_flow.py#L46
My GW1000 seems to support adding different ports, just not using HTTPS over whatever port is selected.
This appears to just be the text at the end of setting up the integration and not the actual port used. Making the port selectable and listening on it would be a bit more involved than just modifying that section. Not to say it can't be done, the HACS integration managed to do it without issue.
In the meantime, I have forked the HACS integration and fixed the bug if anybody wants it: https://github.com/veilofsecurity/homeassistant_ecowitt
In my opinion this is a much better option than doing as @del13r or the official HA docs suggest. Exposing HA on HTTP is just a bad security practice.
Exposing HA on 80 is just a bad security practice.
Home assistant http default port is 8123. Nginx https proxy default port is 443.
both of these can be changed to whatever port numbers you like and you only need to publicly expose / port forward the https port and just use the http port internally without exposing/forwarding it.
@del13r RE HAOS
For that reason, if you are running Home Assistant Operating System, you WILL be able to install the addons.
Home Assistant OS supports HTTPS without the requirement of Nginx ergo exposing HA on 443. That's the documented/supported way to do it. See https://www.home-assistant.io/integrations/http/
Using nginx to reverse proxy SSL might be fine(FWIW I use it at lot but not w/ HA) but it's not the core method of supporting HTTPS and as such your documentation should reflect that a user using your documentation may have a degraded user experience or difficulties down the line. A simple warning caveat should suffice.
Also if a user already has HTTPS setup the correct way (as per HA docs) then your workaround wont work.
I do appreciate your contribution and solution though, thanks for sharing!
it's not the core method of supporting HTTPS
I see your point and I will try to make an ammendment.
In my article, I had explained that when I started, I already had HTTPS exclusively setup on default port 8123 using the default instructions for DuckDNS. I also explain that by following the default DuckDNS instructions where "you'll need to configure the Home Assistant Core to pick up the SSL certificates", that this is what upgrades default port 8123 from using http to https. Perhaps I could make that more clear.
Instuctions from https://github.com/home-assistant/addons/blob/master/duckdns/DOCS.md
Additionally, you'll need to configure the Home Assistant Core to pick up the SSL certificates. This is done by setting the following configuration for the HTTP integration configuration in your configuration.yaml:
http:
ssl_certificate: /ssl/fullchain.pem
ssl_key: /ssl/privkey.pem
Also if a user already has HTTPS setup the correct way (as per HA docs) then your workaround wont work.
This is why I start the article by:
- advising to remove the DuckDNS addon and the NGINX addon if also installed,
- remove this section of the http config block which demotes the https server down to a http server and then reboot Home Assistant:
http:
ssl_certificate: /ssl/fullchain.pem
ssl_key: /ssl/privkey.pem
- delete any certificates in the ssl folder
I do appreciate your contribution and solution though, thanks for sharing!
Thanks for the recognition :)
Exposing HA on 80 is just a bad security practice.
Home assistant http default port is 8123. Nginx https proxy default port is 443.
both of these can be changed to whatever port numbers you like and you only need to publicly expose / port forward the https port and just use the http port internally without exposing/forwarding it.
This is correct. I meant "Exposing HA on HTTP is just a bad security practice" regardless of port used. The point still stands though, even using HTTP internally is not a good idea. You can never assume your internal environment is free of threats. I have updated my comment to avoid confusion.
even using HTTP internally is not a good idea
I agree, hence why I originally exclusively used only HTTPS on port 8123.
The problem begins and ends with the ecowitt device only supporting http for sending webhook data. This has a knock on effect which causes the native ecowitt integration to require that I expose my home assistant core using http so it can receive the http webhook data from the ecowitt device.
If you want to receive data from the ecowitt device using the native integration, this is where you have to make some choices:
- Demote your home assistant core from https to http to suit the ecowitt device and just leave it at that.
- Additionally install NGINX proxy addon to give you both https via the addon as well as http access via core.
I chose to do both.
To be honest, I haven't evaluated or even looked at any of the HACS alternatives yet, but I assume they will function differently to the native ecowitt integration.
The HACS one simply opens a new listener for http on a different port, only to receive this specific webhook. Which solves this problem elegantly and without drawbacks. It's the best native integration path, because it neither requires exposing the rest of hass via http, nor to run a custom reverse proxy in front of it.
You make a fair point. I only got my ecowitt device last week. I thought I would get the native integration “working” first and decided to document my journey to help me and others understand what to do make the native integration work. I may spend some time evaluating HACS options in the future
@raucao
Which solves this problem elegantly and without drawbacks.
I'm in agreement with the caveat that the drawback is that you are opening up an additional TCP port (and potentially another attack vector) and also that it's possible when you replace your router you miss adding this port forward. I'm nitpicking though ;)
Most core integrations don't open a new TCP port so it sort of makes sense that HA core wanted to do it this way, ultimately Ecowitt are the party here who need to get their act together and support HTTPS/SSL.
Has anyone actually reached out to Ecowitt for comment?
If it's helpful to anyone else, I've written a very simple Home Assistant add-on which will listen on HTTP and forward the request to the Ecowitt webhook. This hasn't been tested super thoroughly, just in my simple configuration. Input welcome.
https://github.com/ChrisRomp/addon-ecowitt-proxy
@ChrisRomp Thanks for sharing your little add on!
But couldn't get it up and running sadly. I created an issue in the repo.
With a little hint from @ChrisRomp it works now.
If somebody else wants to give it a try: But I can't get it to work. This is how I have installed it:
- In HA go to Settings
- Add Ons
- Add On Store
- Three little dots on the top right corner -> Repositories
- Add the URL: https://github.com/ChrisRomp/addon-ecowitt-proxy
- reload the Add On Store page and the Ecowitt Proxy Add On shows
- Install :)
- crate a Ecowitt device in the Ecowitt Integration
- copy the webhook id and paste it in the Ecowitt Proxy ID field
- select an free port
- safe the config and start the proxy
- set up the Ecowitt app
- device
- three dots top right corner
- Others
- DIY Upload Servers
- Customized
- Ecowitt protocol
- http url: your internal hostname
- path: log/ha
- port: 8081 <- config of proxy ignores other port settings
- save
- go back
- go back
- save again
Definitely still some bugs to work out. As I mentioned in the other repo, I'm wondering if this would be better presented as a generic insecure webhook proxy for Home Assistant, but I'll need to understand the security implications, first, since it uses the supervisor token to talk to HA (unauthorized error without it, even though webhooks don't require auth externally).
Thanks for this @ChrisRomp !!! I'm not sure that the complicated installation description by @ascheucher above is necessary. I installed the Ecowitt Proxy add-on and then just did the normal Ecowitt integration installation and everything is OK.
