Client communication and Admin GUI Ports

[x64-julian]

When using SSL, both the client communication and the Admin GUI are served over the same ports to benefit from SSL transport encryption.

It should be possible to use different ports for the Admin GUI and the client communication.

[scudette]

It is already possible to use different ports.

When using let's encrypt certificates in the same server process then both front end and GUI need to share the same port because let's encrypt only supports issuing certificates for port 443. This is a let's encrypt limitation.

If you still want to use let's encrypt and not expose the GUI port you can deploy a multi server deployment with the minion having a let's encrypt certificates ( minions do not have a GUI at all). The master node can then be served on a different host name for the GUI.

[x64-julian]

Sorry, I should have been more clear. I specifically meant when using the Let's Encrypt Certificates. I think it's fine to issue certificates on port 443, however it should be possible to then set the Admin GUI to another port (let's say 4443) so that access can be restricted to specific IP ranges. This allows the clients to communicate on 443, but the GUI to be accessibly only from authorized networks via whatever the alternate port is.

Thanks, I'll review the multi-server deployment method!

[scudette]

When not using let's encrypt we need to use a self signed cert which triggers a browser warning. While in Velociraptor in reality a self signed cert is actually more secure (because velociraptor pins the ca in that case) but the whole point is to remove the browser warning.

So it doesn't make sense really to have the clients connect on port 443 and have the GUI on another port because we will still get browser warnings. If the main goal is to separate the ports and you don't mind the SSL warning on the browser then just use self signed mode.

[x64-julian]

I've been able to generate Let's Encrypt certs and use them on different ports in other situations. I'm not sure I'm understanding why in this case the Let's Encrypt cert couldn't be used on another port.

For example, I've used certbot to generate certs with Let's Encrypt over 80/443, then simply configured other services (on different points) to leverage those certs that were generated.

I agree that removing the browser warning is better. It would be the optimal state if we could have both, no browser warning and separate ports for GUI and clients.

[scudette]

We use HTTP validation which does not support other ports than port 443.

You can use dns validation with certbot as described here https://www.digitalocean.com/community/tutorials/how-to-acquire-a-let-s-encrypt-certificate-using-dns-validation-with-acme-dns-certbot-on-ubuntu-18-04

and then you can use this cert on any port you like - it is just not managed by Velociraptor itself. I think you will need to restart the server every 3 months or so to roll the certs over.

You can specify an externally managed certificate in the config file here https://docs.velociraptor.app/docs/deployment/references/#Frontend.tls_certificate_filename

[scudette]

There isnt anything for us to do here - it is all working as intended, so closing.