Support HTTP Proxy

Feature Requests
1

Hi,

I want to use HTTP proxy with HomeAssistant. It seems aiohttp supports reading HTTP_PROXY env var by setting trust_env=True when creating the client in https://github.com/home-assistant/core/blob/dev/homeassistant/helpers/aiohttp_client.py#L70 .

I can create a pull request but I was unsure.

Thanks

2

I added this trust_env and it works. I would be glad if someone else suggests if this is a good idea or not.

As @frenck said in here the above suggestion may not work in all situations as there is no control over third party libraries and they way they make HTTP requests.

But I think at least we can have this option so that the official and most of the add-ons will support HTTP proxy and if an add-on will not work someone reports an issue and can fix it. Also python-requests library respects HTTP_PROXY by default without any configuration.

2 Likes
3

Agree.

IMHO, for a open-platform like HomeAssistant and others which support plugins, we have no way to make sure a solution could work in all situations for all plugins. In such case, what we should do is build a best practice for all plugin devs and publish it to all.

Anyway, we should go forward and shouldn’t stop here just because others don’t go.

4

Honestly I don’t see a reason to have a solution work for ALL plugins. HTTP[S]_PROXY is such a generic thing and really should be implemented alongside trusting self signed certificates.

HASS presents such an open platform, yet it’s missing core homelab configuration options…

2 Likes
5

For those of us with limited bandwidth/metered connections, adding that pull down large amounts of data every time they research can be problematic. Not only that, it can be very slow!

I would love the ability to use a local http caching proxy, like squid, and the ability to install our own root certificate so that https requests can be proxied.

This is pretty deep in the weeds, but I think the right move here is allow admins to

Integrations with http libraries that are ignore environment variables will behave, addons will behave by default due to Docker handling the networking, and adding a trusted root cert is pretty straightforward across the board, unless an integration/addon is using a custom SSL/TLS implementation. In which case, we should burn it with fire and banish the ashes to the far ends of the earth.

Thoughts?

6

I’m thinking that last bullet point might be a bit overkill.
Perhaps it could be a checkbox option to force redirect all outbound requests (via iptables or whatnot), or to simply no do that. I personally hate iptables, so from my perspective this would be a hard thing to properly implement, especially since docker adds it’s own rules and whatnot. A way simpler solution would be to enable the transparent proxy feature in squid for that specific HASS VLAN interface.

As for the force redirect option, in my use case it wouldn’t be as required, since my proxy works on a whitelist basis. So if a container/hassOS tries to talk to the outside, they simply won’t be able to. Though it might be a problem if I wanted the container/hassOS to talk to a couple of domains on the outside… but the container is not honoring the proxy variables, then that’s when I’d need that checkbox to make the container go through the proxy. (Again, unless I enable spliced transparent proxy - Bump won’t work since containers don’t trust the self signed CA from the host)

As for the ability to import a self signed root CA on hassOS, and set http_proxy variables (including the docker daemon config.json file) - Yes, those features are the ones we truly need.

7

mkcert makes it easy to create a Certificate Authority, and use self-signed certs. no arcane openssl incantations, though, unclear if you can provide it with a certificate to install…

So, @TurfFiber Your idea is that instead of iptables, we use the router to pass everything through a proxy?

So: hass->router->redsocks->squid->router->internet

I think having squid and redsocks live in an addon makes sense, not sure how you’d do the iptables rules…

8

Also, proxychains-ng should make routing tcp to a proxy straightforward.

9

Also, this: GitHub - tazihad/ProxifierLinux: Proxifier alternative for linux using redsocks. Proxify all linux applications through SOCKS4/5, HTTP proxy

the relevant iptables rules

10

Yeah I use the same thing, HassOS just doesn’t have an option to import it.

So: hass->router->redsocks->squid->router->internet

Not sure if you need redsocks… On my pfsense box, squid has the ability to redirect 443 transparently, to itself. Meaning no fancy shenanigans required on HassOS side, except

  • the ability to import the Self Signed CA
  • and also, if people don’t have / don’t want the transparent proxy option, it would be required that HTTP[S]_PROXY variables are configurable and respected by HassOS, including the configuration of docker’s config.json, which you linked.

The 2 above bullets seem like a great start, and should be quite simple to implement.

1 Like
11

Hello,

I’m also looking for HTTP Proxy support because I’d like to use HA at work with my students.

Install is blocking when trying to download updates. So I’m wondering if there is a chance to find a workaround by simply configuring NetworkManager with nmcli commands using Terminal HassOS.

I’m thinking to do something like

nmcli connection edit <con-name>
print
set proxy.method auto
set proxy.pac-url pacman.domain.fr

where pacman.domain.fr download a PAC file (proxy auto configuration file)

I’m also looking for a way to directly be able to put a configuration file on SD card of RasperryPi to set proxy. Is it currently possible ?

2 Likes
12

I’ve tried nmcli commands but it doesn’t help (unfortunately). Any idea?

13

I got it working by following the instructions in the link

proxy server configuration using NetworkManager nmcli

14

I used a workaround by setting proxy in .gitconfig. You can have a try.