We keep telling you that we’re listening. And we are. I was talking with @RRodman and @markus about what we would like to see in terms of privacy and security. Cores will also be utilizing SSL certificates and https. Since Wireguard is a part of our kernel we started thinking about how you, our users, would use this feature. That being said, is there anything else that would be nice to have?
The first obvious use case is hosting a VPN server via Wireguard for remote management of CC, and could expand to your entire network based on how the network is setup.
What specifically do you mean? What other security/privacy features would be nice to have or something else?
What do you want it to mean? When you read that, what comes to mind? In context, of course.
I was more just referring to what you want feedback on beyond what has been provided in the Wishlist thread.
Then I would have to say, yes, security is the question here.
1 Like
The reason wireguard was a must for us 
Basically we want to know what aspects and abilities related to privacy/security are most important or usefull to you the user.
Example: would it be important to you for us to have it so all cloud related traffic from your core gets sent through one of our servers first in order to anonymize any contact you do have to have with the cloud?
2 Likes
-
For front-end security: Biometric login (multiple user ideally) for dashboards would be nice and maybe even 2FA, but that may be unnecessary for a local network honestly.
-
For back-end security: I have no clue if this is feasible due to meshing and signal strength, but what comes to mind would be emulating how zigbee and z-wave work and have wifi devices connect directly to a network broadcasted from CC segregating them from the normal network.
That is an interesting idea, however I would definitely want that to be optional, not sure if I would prefer opt-in or opt-out though, because yes it would be anonymizing to the outside world, but your servers would still know, and some people may not want the extra hop.
1 Like
The ability to turn it all off! Including any ET style phone home “check-in’s”. Running all my own firewall, VPN, VLAN, security, and would rather not have that “ability” built into the device at all. I certainly would not want the overhead, when there’s a dedicated machine to do that heavy lifting. Not a fan of “all-in-one solutions”, but that’s just me.
2 Likes
I’m probably lacking imagination, but can’t think of a way to use this feature. Are folks doing VPN tunnels within their lans? Is the CC device intended to be exposed directly to the internet? Sorry, I can’t quite come up with a purpose for a VPN server.
Just one guy’s 2c but personally I would say it’s important to not do that. Personally am looking to reduce 3rd party (MITM) involvement, not increase it. Although I do get the point, it’s a decision for each user to make, I guess no worries if the ability is offered, so long as it’s optional.
1 Like
Oh no it’s not! I’m right there myself.
Me neither since I have a VPN for my entire network I won’t use a second, more specific one. However, I can see where some who don’t already have a VPN may want to use a dedicated one to CC.
I would say this more than anything for me.
This additional feature has to be configured by the user. It’s not active out of the box.
6 Likes
You’ve got my vote for making VPN available with off as the default setting.
I would not want to see traffic to 3rd parties going through your servers though. I want my hub to continue working even if your company ceases to exist and the servers are turned off (something we’re hoping won’t happen of course).
1 Like
For security, allow users to use self-signed certificates at a minimum, plus the ability to generate and install full SSL certificates. What would be even better would be to include the certbot daemon to support LetsEncrypt in the base OS and having a UI to configure it. This will allow users the option to use real SS certs without the technical expertise, hassle, or expense of doing it on their own.
3 Likes
Uhm … maybe I should have been more specific in my original post. When I mentioned SSL certificates and https, I assumed you would know that I considered all of that a part of SSL certificates.
3 Likes
I thought so, but in my line of work, omitting details leaves things dangerously open to interpretation. 
4 Likes
Another Mars VS Venus issue my house runs into all the time 
4 Likes
I know enough about certs to be dangerous. That said.
-
It seems that SSL certs are rough to use when you’re not using a dedicated “domain name” that you own. You can generate self-signed ones with some work–but they can also trip up some checks (e.g., browsers that aren’t trusting of them). While you can add trusted certs to WIndows, that can be rough to do for some devices. So, one supposes your system would allow us to control the trusted cert/CA lists?
-
As for VPN stuff. That can be a royal PITA if you have to manage things (It took me a while to figure out how to generate certs for OpenVPN that didn’t expire every 30 days!). Esp for novices–so tools, good documentation, etc. are important.
-
If you could allow use of some “Dynamic DNS” service thru the hub to accommodate normal ISP use of dynamic IPs–then have remote apps able to point to a Dynamic DNS provider to get the current IP address, that would be great.
-
Allow using an SSL protected VPN tunnel to connect to the hub remotely (from mobile apps, etc.), incorporating the necessary dynamic DNS lookup (with provisions for NOT using the VPN when on the same, local network–but, allowing optional VPN use if desired).
-
Ideally, your remote/mobile apps would have the OpenVPN client built-in, so they could automatically connect to the hub securely, remotely.
-
BUT ALSO: it would be great if your hub’s OpenVPN server allowed pretty much ANY authenticated device to connect. That way, I could (for example) create an OpenVPN profile on my laptop and just browse right to it–so I could manage the device remotely in by browser.
-
Your OpenVPN server on the hub will need to support the use of client certificates and passwords (i.e., super tight security) so that simple hacking of passwords doesn’t let you in from outside.
Much of the above should allow direct control without you having to “cloud serve” anything. You could offer the Dynamic DNS lookup–but, it would be great if you also could use OTHER providers (e.g, DynDNS).
And, if your device surfaces an OpenVPN tunnel, you could remotely access the full capabilities of the device.
The trick is doing things to make the OpenVPN stuff less than obtuse (it took a fair amount of wrangling and stumbling across some great posts/documentation/etc. on generating certficates, configuring OpenVPN, etc. to get my Asus one working properly).
And. The. Key. Issue. Support/updates. If this sucker is going to have an “ear to the WWW/wild wooly world”, the OpenVPN software and anything else needs to be super secure, patched RAPIDLY for all the vulnerabilities the come along. And, it needs to “keep up” with compatibility for newer OpenVPN clients, etc.
2 Likes
I had the same struggles with ovpn that you did and I fully agree with your concerns. However, I don’t recall the OLL folk saying anything about ovpn. Wireguard is the only VPN that will come with CC AFAIK.
1 Like