SSL Certificate verification

[Ulrar]

Hi,

It makes me a bit uncomfortable to leave ssl verification off, but I see that for some reason Access has it's own API port with a different certificate from the regular UI.

I had a quick read through the documentation and they don't explain where that cert comes from, but it seems to be valid from Tue, 14 Feb 2023 20:20:51 GMT until Thu, 06 Feb 2053 20:20:51 GMT, which is quite a bit. Makes me wonder if it's the same cert on all the consoles ? The sha1 on mine is 97:72:62:6C:7E:DD:F9:4D:9F:76:D1:DF:DF:C2:D5:54:E3:F0:A5:31, can someone see if it's the same on theirs ?

If it is then the integration could just ship with the crt for validations, and if it's not I suppose there could be an option for the user to paste it in on setup maybe, at least optionally. WDYT ?

[imhotep]

@Ulrar I totally understand the need to validate SSL certs in an enterprise setting or perhaps any type of crowded setting (like hotel, restaurant etc..) but for the average home user (which is what this integration is for) do you think most people would care much? I know I personally don't. My SSL cert expires around the same time but the signature is different. It suspect it gets self-generated whenever you install Unifi Access on a controller. I could add an option to paste an SSL cert in the config dialog but I also don't want to over complicate the setup process so I am torn...See issue #1 it seems like it's already confusing as it is.

[DefenestrateIT]

Copy the other Unifi Intergrations.

Host: (This is the host the Unifi Access is hosted on [UDW/UDM/UNVR/CloudKey]) API Token: (get this from Security -> Advanced -> API Token) Port: (Default Port 12445) Verify SSL certificate: (tick the box if you have a valid SSL certificate installed on the host [default off])

Yes, A lot of people will care about SSL & even Port.

I believe you are looking at your self-signed certs, you need to install a cert from a certificate authority like Let's encrypt

[Ulrar]

You can't copy the other integrations, Access for some reasons has its own API port with its own self signed certificate, it doesn't work the same way unfortunately.

I agree this isn't essential, but it does unlock my front door so it'd be nice to be able to verify the certificate if at all possible.

The chance of someone getting in the middle to grab the token is basically 0 so this is certainly not important and wont stop me, or likely any home user from using this, but at the same time checking the certificate is pretty much free so IMHO why not have it as an option.

I hear the complexity argument, I wonder if it could simply be hidden in a collapsed menu in the config flow ?

[DefenestrateIT]

"Connect using the specified port number (12445) and establish an HTTPS protocol for a secure connection."

1/ Most people who know what they are doing, and who have segregated networks/VMs/Container-Stations will want control over port numbers that are used. Everyone should use segregated networks, but most people don't because they get complicated quickly.

2/ SSL does not work correctly if it is not verified; yes, most people don't care, so they should be using HTTP, not HTTPS, but since Unifi Access API only uses HTTPS, give the user the option to use it correctly by verify it.

Your UDM has IDS/IPS, so running HTTPS blocks their ability to check that it isn't being compromised!

"The chance of someone getting in the middle to grab the token is basically 0 so this is certainly not important and wont stop me, or likely any home user from using this"

I think that in every system that has been compromised by A on-path attack, the admins said that about their system. If you have a self-signed cert, anyone who gains access to your network will be able to impersonate your controller, & thus get your API token.

"2.6 API Host The Open API Server is hosted on port 12445 and can be accessed via HTTPS at https://console-ip:12445. The server certificate is self-generated and untrusted."

[Ulrar]

1/ I agree but that's not something this integration can do anything about, that's something for Ubiquiti to change

2/ No, I do have a valid certificate on my UDM Pro. The Access API does not share it, no idea why Ubiquiti made it that way but sadly nothing this integration can do here. Maybe there's another way to change the Access API cert, but someone will have to figure that out and that wouldn't fall in this integration IMHO

The only thing that can be done here is verify the certificate isn't changing, maybe it could just store it on setup and then verify against that ? That'd be transparent to the user, although that's assuming Access never regenerates it

[Ulrar]

If you have a self-signed cirt, anyone that gains access to your network will be able to impersonate your controller, & thus get your API token.

Well you can still verify the certificate itself, regardless of who signed it, so this isn't in itself a problem. But regardless for a home user the chance of that happening, realistically, is basically 0. Someone going to that length will break your window to get in anyway

Again, I'm all for verifying it, but it's not a huge issue and doesn't need to be priority 1, I created the issue so it could be tracked, discussed and considered

[DefenestrateIT]

"1/ I agree, but that's not something this integration can do anything about; that's something for Ubiquiti to change."

Ubiquiti Unifi supports segregated networks, "but most people don't use them because they get complicated quickly". You should have your Wifi on a different VLAN to your LAN. Lots of people put their cameras in a separate VLAN. & your IoT devices on another and if you host a public web server in a DMZ.

This stuff is more difficult with the Unifi network App than other systems, but if you use NAT between your VLANs so everything in that VLAN appears as a single machine, then port forwarding & changing port numbers becomes very relevant, the same as if you run your Home Assistant in a VM or container. It is a huge pain if, by some unlucky chance, you get two services wanting to use the same port & neither of the services will let you change the port number from either the client or host. There is also security by obscurity, where changing port numbers makes it hard for adversaries to identify the services.

2/ No, I do have a valid certificate on my UDM Pro. The Access API does not share it, no idea why Ubiquiti made it that way but sadly nothing this integration can do here.

That Cirt you are talking about, I assume, is the one only valid if you use the DNS "ui.com" to access your device, it is not valid for local traffic E.g. 192.168.x.x.

But these things don't need to be in the Alfa version.

[Ulrar]

You should have your Wifi on a different VLAN to your LAN. Lots of people put their cameras in a separate VLAN. & your IoT devices on another and if you host a public web server in a DMZ.

I do have a vlan for iot, and another for protect with port isolation enabled and traffic rules to block inter vlan and internet communications. I also have a network for my servers and another for regular users.

I fail to see what that has to do with this issue however, the Access API port is available from all of them and doesn't seem configurable

Your UDM has IPS detection, so running HTTPS blocks IPS's ability to check that it hasn't been compromised!

Again, I'm not clear on what the point you're trying to make is. This integration connects to the Access application's special port, and isn't configurable so there's really nothing to do here.

But the token exchanged over that connection would let anyone connected to any lan nets control doors, so it better be an encrypted connection, the only thing missing here is validating that the cert isn't changing to prevent MITMs. So either let the user paste it in, or just store it when the integration gets created to validate against later, unless we can find a way to replace that cert on the UDM side but that's out of scope IMHO

But these things don't need to be in the Alfa version.

100%

[DefenestrateIT]

Again, I'm not clear on what the point you're trying to make is. This integration connects to the Access application's special port, and isn't configurable so there's really nothing to do here.

I believe you can't change the port number for any Unifi APIs, so why do you think they give you the ability in the other HAss Unifi integrations?

But the token exchanged over that connection would let anyone connected to any lan nets control doors, so it better be an encrypted connection, the only thing missing here is validating that the cert isn't changing to prevent MITMs.

I'm currently going for my ISC2 Certifications; both of these things matter...

In the end, from the GUI perspective, it is only 2 extra fields that have default values. And from the developer's perspective, or as Picasso said, "A sound artist creates; A great artist steals". Copy the other Unifi integrations.

[imhotep]

I added a "Verify SSL certificate" checkbox just like the Network and Protect integrations are doing. By default and if selected, this would fail for pretty much every one as there is not currently a way to change the SSL certificate generated by the Unifi Access app. It is also not possible to change the default API port.

It does offer the ability though to put the Unifi Access API server behind a reverse proxy (like nginx) that would in its turn trust the SSL certificate. This integration could connect to the reverse proxy and be served a valid cert (and potentially use different port). Do you guys have this kind of setup? I have something like this for my other services but for my unifi stuff, I like to keep things simple.

None of the other Unifi integrations offer the option to paste SSL certs though from what I could see. The underlying library requires the certificates and keys to be actual files on on the filesystem in order for it to trust them which I feel like is out of scope for this integration (or any integration really).

[DefenestrateIT]

It is also not possible to change the default API port.

That is why you need to give the ability to change it from the client side. Just have a field for changing the port, but it has the predefined default value 12445, like the other integrations.

It doesn't matter what port the API uses, when the traffic crosses "what I would call the Layer 3 level" (that's in routers, proxies, vLANs, etc...), port numbers get converted (or corrected) by that system, so the API port doesn't matter.

I totally agree that 99% of people won't care about the port number, it doesn't make the GUI that more complicated to add it, but it makes the integration 65,535 times more flexible.

(I do have my HAss in an isolated network, so what ports I use matters).

Please add the ability to change the port number.

[imhotep]

Added