Whats THE difference from running ha in nabu casa than running it yourself :-)? Seen from a Security perspective, given that you use https ofc
Well, first of all, let’s begin with HA doesn’t RUN in NabuCasa.
NabuCasa is an easy way to present your premise infrastructure to other services (including the web dashboard, web sockets, oauth, etc) without having to build out a premise infrastructure for security, including correct implementation of SSL and HTTPS.
It replaces the usual suspects of DuckDns and Let’sEncrypt! (quite honestly services I don’t reccommmend laypersons try to configure as they’re too easy to mess up and messing those up mean an exposed surface for bad actors.)
No, it does not.
Let’s Encrypt is a certificate service that enables SSL encryption for many kinds of connections.
DuckDNS is a service that provide a translation for a domain name to IP address.
None of the two services provide a service that allow access to you network.
nGinx and portforwarding does allow access to your network and might be using the two services above, but NabuCasa is not comparable to nGinx and portforwarding, because there are many security issues with this setup.
NabuCasa is best compared to an on-premise VPN service.
And of since a VPN service needs encryption too, then Let’s Encrypt might be used for that and if you do not have a fixed public IP, then you might need a dynamic DNS service, like DuckDNS.
Ease of use. 60 seconds and your done with remote access, encryption, tts, google, alexa, etc.
Not much at all if you know what you are doing and take the time to set things up correctly. If I took the time to do it, I have no doubt my implementation would be tighter than using nabu casa.
But… if you don’t know what you are doing, then disaster looms.
My thinking is that Nabu Casa is secure enough, brings a lot of convenience, and helps support the project. The “helps support” is the most important part to me, otherwise I’d probably go on my own.
Personal soapbox. Https, despite the “s”, IS NOT REAL SECURITY. It’s encryption/privacy, with some MITM protection thrown in. Plenty of exploits/attacks can be easily carried out through that misnamed “secure” connection. Too many just enable https and blindly think their server is now “secured.”
1 Like
I work as a dev-ops so THE setup wont take Long, i just dont see THE “more Secure Way” when talking Home setup vs nabu casa, currently i use a ipsec/l2tp but thanks guys 
IPsec/L2TP is a VPN setup and not just NGinx with portforwarding.
In this case the only part that really make NabuCasa more secure is that it limits access to only HA pages, but that will also be a downside for some as some addons might be inaccessible with NabuCasa.
As long as the VPN service is a up-to-date one and you know what you are doing, which it sounds like, then I say go ahead.
My beef is really only with the portforwarding all traffic directly to HA and let HA solve the authentication and access restriction with no other secuirty layer.
The problem is many do not do the home setup properly on their own, as evidenced by this post. Many just port forward 8123 and don’t even bother to setup SSL, leaving their install completely exposed wide open on the internet.
So, Nabu Casa is far more secure then an improperly setup home install, and improperly setting it up on ones own is very easy to do. So, I think you will hear many just default to saying that nabu casa is the “more secure way”, and I would have to agree, as that at least guarantees the user some level of security they don’t have to worry about messing up.
Now, if someone has the skills to setup a VPN, reverse proxy, or some other secure solution themselves and make sure they do it right, it can potentially be even more secure to setup then Nabu Casa IF done properly. I’d say the VPN is the most secure, but some integrations need secure access back to your machine through SSL (like Google Google Assistant - Home Assistant ) so a VPN probably wouldn’t work, and you would need a reverse proxy. I actually run both a reverse proxy (SWAG - Nginx Reverse Proxy Set Up Guide – Docker ) and Wireguard as a VPN Wireguard Container . Some hings are exposed through the proxy, other things deeper in the system need the VPN to access. For example, I run a Home Assistant container install, and manage it with portainer. I do not feel comfortable exposing portainer through the reverse proxy since it can access things deep within the system, but I can access it through the Wireguard VPN.
a reverse proxy, like NGinx only encrypt the communication, which only makes the situation secure in the few situations where you are on a network, where others can sniff your data traffic, like WiFi on cafes and restaurants and maybe also libraries, but the normal mobile providers network are already secured.
It is only minimally more than one without reverse proxy.
The big issue here is the authentication process which is with both a simple portforwarding and reverse proxy left up to HA.
The reverse proxy alone might not add much security,
but Swag includes fail2ban which adds additional security to block some attacks before even getting to the Home Assistant instance to attempt to login.
I also have Home Assistant setup with 2fa and to block an IP after 3 unsuccessful login attempts.
That statement is so many years invalid.
Its 2022 and hackers have many years ago rendered that function obsolete by using botnets and distributed computing, where each IP will only try 2 or 3 attempts before the next bot computer will jump in and take over.
This is a fully automated process for the hackers and any server administrator that have dogged just a bit deeper in their server logs will have seen this during the many last years.
2FA is an improvement, but you are still forwarding all request to a host machine that you can not really harden that much, because HA has functionality over internet security in the priorities.
Besides that then it is pretty much impossible for the core HA developers to check all the addons and integrations that are also being served on the web service and just one of them needs a security hole to deflate your entire setup.
Today the best practice is to have security in depth, which means harden dedicated perimeter devices and layers of security behind that also, which means each device is harden as much as possible themself.
In the long gone past you only had harden dedicated perimeter devices, which meant if one of these failed, then all where lost.
A HA setup with portforwarding and maybe reverse proxy can not even be considered a harden dedicated perimeter device.
Running it yourself means forwarding some port (8123, or any other port by choice) on your router, which might pose a security risk if you have not secured your local network.
In case of using NabuCasa, it is HomeAssistant that connects to a port with NabuCasa, without the need of forwarding ports in your router.
So THE difference is:
NabuCasa —> outgoing tcp port (no router configuration required)
Local —> incoming tcp port (a port needs to be forwarded in router)
I think that is the best answer to describe the differences, but doesn’t say anything regarding security, but as others before me stated, that basically hasn’t anything to to with it🤔
The poster have already stated that he wants to run a VPN service and not just a portforward with or without reverse proxy.
A proper set up VPN service can actually be harden more than NabuCasa can, because access to the VPN service can restricted a bit more, if your router or VPN service can filter on IP address, country of origin, protocol (like only IPv6) and other settings. NabuCasa will have to be open to all its users around the world with all the different ways they connect.
Even more when using security certificates for VPN 
So i agree, most secure will be using VPN
i went witht the cloudclare soultions , and just created the google dv app for google home ihntegration, works like a charm 
! but thanks for replys
so is there any serious difference in operations (except for ease of use) between
- a nabu casa account
- an AWS-hosted server with a fixed IP address that is behind a proper security group, which the actual HA instance connects to via a reverse SSH tunnel, and that is fronted by a caddyserver with a zerossl certificate running on a nonstandard https port?
after a year of using nabu casa i’ve put together the configuration above (the server was there, i just added the proper reverse tunnels, the caddy and the certificate) mainly because i’m bringing up my second instance and as we know a nabu casa subscription only allows one instance to be run. my original instance also has a security cam feed via rtmp, and i thought passing that through was a nabu casa feature, but since i’ve wired in my original setup via the AWS server as well, i’m seeing the feed without a problem (probably via websocket tunneling).
are there any other differences, like being able to send elevated alerts (that punch through all DND settings) to a HA client on ios? or is that available for a self-hosted instance as well?
works for me on self hosted…
the only difference between NabuCase and self hosted is that for NabuCase you don’t need to punch any hole in your incoming firewall; it is the HA instance that connects to NabuCase.
When hosting yourself, you need to open up your router for incoming connections to HA.
that’s not even necessary, and in cases, not possible. my original setup was behind a mobile router and that incurs so many levels of NAT it was impossible to open up the ports as NAT happened at the service provider level as well, not just at the router.
however, reverse SSH shell and port forwarding works like a charm – even hidden deep behind multiple layers of NAT --, you just need a bridgehead server with fixed IP address. but this way it’s much simpler to terminate the SSL connections at the bridgehead server and do a reverse proxy there to the SSH tunnel.
i’m wondering if nabu casa works exactly like this.