Trusted_networks and X-Forwarded-For

Configuration
1

Using Trusted Networks, Conclusions…

Test 1:

use_x_forwarded_for: True
Using reverse proxy - Bypassed Login
Without reverse proxy - Bypassed Login

Test2:

use_x_forwarded_for: False
Using reverse proxy - Bypassed Login
Without reverse proxy - No bypass

Test3:

No use_x_forwarded_for in configuration file at all
Using reverse proxy - Bypassed Login
Without reverse proxy - No bypass

The bypass is caused when using reverse proxy (which most users configure in order to secure connection with SSL)

The documentation is vague (for a non-technical user):

trusted_networks (Optional): List of trusted networks, consisting of IP addresses or networks, that are allowed to bypass password protection when accessing Home Assistant. It should be noted that if you use a reverse proxy, all requests to Home Assistant, regardless of source, will arrive from the reverse proxy IP address. Therefore in a reverse proxy scenario this option should be used with extreme care.

I am sorry but this is vague and it should be highlighted in BOLD RED with an exclamation mark as a warning
So it seems that if you are using reverse proxy you should not enable trusted networks.

2

This doesn’t make sense to me

If the header can be easily forged, why would I tell HA to use it?

3

Indeed, the docs say:

You should only enable this in a trustworthy network environment, as clients passing that header could easily spoof their source IP address. Defaults to False.

Which is the exact opposite of what you’re saying, @NightRanger?

4

@anon43302295 @

If you are using trusted networks you must add the “use_x_forwarded_for” to your configuration in order to prevent someone from spoofing your trusted network.

The documentation is confusing and not explaining the security risks properly it’s just a side note.

Without the use_x_forwarded_for setting in the config file i was able to bypass the login by spoofing the IP of a trusted network in the X-Forwarded-For header well maybe it should be false but it worked with true as well strange…

Anyway I’ll do some more tests and will update this post

5

I’ll test it again, just to make sure

6

I would say that the documentation is very clear, and says the exact opposite of what you’re saying, which is what I’m concerned about.

Please let us know the results of the tests.

7

That’s why I edited my post, it looks like it behaves differently when using reverse proxy so maybe that’s why I was able to login to my HASS instance without a password from a different network with spoofed address.

I’ll do more tests without the reverse proxy later and will post the results

8

@anon43302295 @gpbenton

OK, Conclusions…

Test 1:

use_x_forwarded_for: True
Using reverse proxy - Bypassed Login
Without reverse proxy - Bypassed Login

Test2:

use_x_forwarded_for: False
Using reverse proxy - Bypassed Login
Without reverse proxy - No bypass

Test3:

No use_x_forwarded_for in configuration file at all
Using reverse proxy - Bypassed Login
Without reverse proxy - No bypass

So basically it matches the documentation and I was mistaken, the bypass is caused when using reverse proxy (which most users configure in order to secure connection with SSL)

The documentation is vague (for a non-technical user):

trusted_networks (Optional): List of trusted networks, consisting of IP addresses or networks, that are allowed to bypass password protection when accessing Home Assistant. It should be noted that if you use a reverse proxy, all requests to Home Assistant, regardless of source, will arrive from the reverse proxy IP address. Therefore in a reverse proxy scenario this option should be used with extreme care.

I am sorry but this is vague and it should be highlighted in BOLD RED with an exclamation mark as a warning
So it seems that if you are using reverse proxy you should not enable trusted networks.

3 Likes
9

Thanks for explaining that. It all makes a little more sense now.

1 Like
10

This is a bug. It shouldn’t be this way. I have opened an issue at: