Just out of curiosity, what other products you know of implement that functionality?
4 Likes
The usual webservers have the option to hide info about the system its running on, or the possibility to edit the landingpage.
What would you obfuscate?
Yes you want to ‘not give anything more than necessary’ but this would become just an arms race you ‘change’ something, they adapt to the change.
What your web page presents is only one (small) part of fingerprinting a target. Whatever profiles the ports looks at things as esoteric as how a returned TCP packet is arranged to ID the base OS returning. In essence, “oh that’s Debian +foo, ok then let me try this, custom os on Debian, ok i it’s version xxx. And these ports and…”
Basically, the attacker can know it’s HA and probably what hardware you’re running on before ever touching the login prompt just by how the OS responds on the network… Considering that just hitting the URL gives a login challenge to https/443 default we can’t move the URL either… (the other possible obfuscation)
So yes use proper security, don’t give any more than a login prompt. But screwing with the login prompt itself isn’t going to buy much of anything. Ask Microsoft, Google or Amazon if they care what is on one of thier login prompts? (and before someone says yeah but those are well known domains, you have to remember that they also provide federated or SSO login for literally millions of business.)
IMHO I’m all for allowing customized login prompts, but but not for security sake. It doesn’t buy much, if anything for the effort (dev effort is not an unlimited resource) and if rather they focus on keeping NGINX and other things in the chain up to date and tight.
If you want better security put it behind a reverse proxy with SSL termination and review the logs regularly.
6 Likes
You mean apache / nginx? Well those are generic webservers. I meant products exposing a web interface.
Even a security-focused product like keycloak doesn’t have that functionality, afaik. You sure can change the look&feel, but just looking at the landing page source makes it quite obvious what it is, so there is no “obfuscation”.
Thanks for your thoughts and they make sense. My request is simply the option to remove all HA info from the login page, shouldnt be very difficult. It’s a too bad that I’m not a developer myself or else I’d make an addon myself to ‘fix’ this.
If you want better security put it behind a reverse proxy with SSL termination and review the logs regularly.
This, of course, I already have in place 
Proxmox → OPNsense → Nginx → NAXSI → Crowdsec → HA
Removing unnecessary info on the server’s role is just a small improvement.
1 Like
Yeah if there wasn’t already an open feature request (that was initially denied BTW) for federated/WebAuthN/passkey auth… Thats the one I’m throwing my ask behind.
IMHO Every system that exposes a login should be looking at supporting passkeys. That’s a security enhancement I can seriously get behind…
Ooh edit someone did put up a separate passkey request… Go do.
3 Likes
Those two lines in the same request just makes no sense at all.
Home Assistant is not a product hardened for exposure to the internet.
Home Assistant with all its custom thirdparty integrations will never be safe enough for that.
Security Holes have already happened, so it is not just theory, just search for “Home Assistant Disclosure” on Google.
Best practice in network security is to put a proper hardened security product in front of HA, such as a VPN gateway. Not even a reverse proxy would be considered best practice with HA due to the many third party integrations running on the same host and even often on the exact port too.
3 Likes
@WallyR Thank you for your contructive and helpful reply. We indeed didn’t know all that.
Fyi, to access a VPN you’d need to connect it to the internet. Any more useful insights you want to share?
You are supposed to run the VPN gateway on your network, so you control the gateway.
Devices outside then use a VPN client to connect to your gateway and gain access to your network or host.
The VPN gateway is the right tool for the job and provide both authentication and encryption in the hardened interface and access to any other service or port is not possible.
Many higher end routers actually have a VPN gateway built-in and it is often quite good.
My Ubiquiti EdgeRouter 4 comes with a power StrongSwan VPN gateway and on my Android I just download the StrongSwan app and use that. StrongSwan even provide app-specific VPN, so I can have my VPN connected, but only use it with HA (and what else I choose), so all other traffic will still use the normal mobile data gateway.
Security through obscurity? Since when?
4 Likes
STO has been reported at least as early as 2013 if you look at the references on that link.
Sure, I also practice STO, just didn’t know it’s called like that.
It’s common practice in several products: I know that the Admin Url in Prestashop is no longer on ‘/ps-admin’ as in 2010, but on a random url (at least for the postfix).
I use OPNsense with ha-proxy to redirect subdomains to the correct server. If you do not know the subdomain, you can’t access the service. That’s STO as well.
When possible, I disable the server’s SW information (not telling it’s Apache/Nginx).
Fingerprinting a system (with nmap for instance) has its limits - and nmap is one of the tools that allows you to test this.
Using a VPN is clearly an extra layer of security but not easy to setup.
A lot of Home Assistant admins have a public address for their instance and no VPN. Improving STO on Home Assistant would help at least for them.
And maybe go one step further: do not just make it obscure - randomly impersonate the fingerprints of another system. Not being fingerprintable can hint that the service is Home Assistant… .
The biggest problem with security through obscurity is that it isn’t secure.
What people (should) want is security by design which makes obfuscation obsolete.
It was never easier then today actually. With wireguard or even tailscale the knowledge necessary to get a VPN up and running is probably less then set up an HA server.
2 Likes
Can’t. Needs to be /
Also can’t, same reason
Thats great - most tools don’t care. They still know.
And it’s not the only tool
If you are concerned about the login page being exposed on the website root and SSL terminated reverse proxy doesn’t float your boat, then that’s currently the only alternative.
And not being ‘fingerprint able?’ that’s not a thing. Do you plan on rewriting how Network adapter drivers and routers respond at the network layer? Everything is fingerprint able. It’s a matter of how much info you show and no I didn’t just prove you correct because by the time I see your web page wherever it is (and we’ve already established I can’t change the base URL for HA) I already know what and probably who you are.
And that’s just a perfect example why “STO” is bullshit. It’s perfectly possible to enumarte unknown/hidden/obscured subdomains…
2 Likes
I have heard that being said so many times, even by teachers in IT security, but most security in IT is by obscurity, because encryption is just obscurity.
So, now the pissing contest is hopefully over, what about practical solutions?
What practical solution? It’s a non issue. Use an SSL terminated reverse proxy and/or VPN.
Get dev to work on real problems like ensuring the recent NGINX vulnerability is patched. Work on WebAuthN FIDO2 passkeys.
Obscuring something that is immaterial is a waste of time. Whether you agree with sto or not.
2 Likes
Get a REALLY obscure subdomain (like an md5 hash) for your domain, get a wildcard certificate for your domain (so the subdomain won’t show up in the certificate), then let the reverse proxy point at HA when the the correct subdomain was entered, else to some other dummy-site. I have this setup for around 8 years and literally never had an HTTP request in my logs from somebody else than myself (and webhooks of cloud services).
2 Likes
That of course require your authorized adNS servers to not reveal domain setups in requests, like with an AX transfer request.
But in fact with IPv4 the hackers just scan the entire range and all ports with the help of botnets.
Botnets do this regularly and keep a database of fingerprinted system and services, so they can strike fast at zero day security holes.
The problem with obfuscating the HA login page is that it will be fingerprinted easily and have so many other attack surfaces that it will be like hiding your iPhone in your inner pocket to avoid a being robbed, but you still flash your white AirPods in your ears.
1 Like
Correct. In my case no data is leaked. But it’s a paid domain. Not sure how this whould be with dyn-dns solutions.
That’s why I have the honeypot / dummy-site responding when it’s not the correct domain. Works flawlessly. As mentioned above, not a single unwanted request to Home Assistant since I have this setup.
As for obscuring the login page I totally agree. Doesn’t make sense.
1 Like