Securing the Web Dashboard

Hello there,

I try to secure the access to the web dashboard using SSL and a BasicAuth.
I plan to use it in the evil wild world web :wink:
My first thought was to use a reverse proxy to get the job done.

The process to install and configure a reverse proxy which deliver let’s encrypt certificates was pretty straight forward. I could also setup a basic auth there but i think that it would be useless there as the important thing to secure is on the 5950 port !

I can already access the frontend through an SSL connexion.

But from there, i realize i can’t get anywhere ! :frowning:
As the web client does’nt establish any connexion to the backend server 5950 (firewall is ok, proxified or not).

I’ve not dig the javascript code further and just decided to ask for guidance here :wink:
Hoping someone could drive me in the right direction.

I think a basic auth under SSL would be a great addition to the web client.

Dear Hoxca,

webdashboard doesnt have SSL support. You can use a simple VPN to secure the connection if you need like IPVanish or OpenVPN. OpenVPN is also free or you can use the VPN on your router/modem, many router have inside OpenVPN system just to configure.

You cannot use a SSL proxy because communication are on 5950 port not in web.

All the best
LO

I’ve read this constraint in the documentation.

And, i know that i could use a VPN to secure the whole Lan.
But for now, it’s not possible as my ISP box does not support VPN or an IPSec ikev2 VPN pass through.

As far as i known gRPC use HTTP/2 protocol for transport and could work with an SSL layer ?

We plan a VPN in our final observatory destination.
But for now i can only do a port-forwarding and expose the web interface to the evil side of the network. which is bad :frowning:

Nevertheless, there are a bunch of observatory where they don’t use VPN but a simple secure TeamViewer interface and it would be good to have a solution over SSL for the Web Dashboard.

Excuse me, as i read the documentation further (http://www.starkeeper.it/voyager/VoyagerAS.pdf)…
I discover that the communication between client and server is done thru json-rpc 2.0 and not gRPC.

Anyway json-rpc 2.0 is also a HTTP transport and should support SSL tunneling ?

SSL tunneling work … infact VPN work fine with JSON-RPC is a simple text
But is not based on HTTP transport and dashboard are under websocket … same server … different answer based on client

Best solution is VPN … we can release HTTPS server instead of actual HTTP but this mean user must manage the certificate in some cases

All the best
LO

I’m not sure i clearly understand you, as far as websocket is also an upgraded HTTP connection.

My initial thought for the WebDashboard was a connection to front (443) and connection to the backend 6950 should be done in HTTPS (SSL client)
there will be no change on voyager the server side
a reverse proxy (with SSL) handle to connection and forward to the backend voyager server (from 443->80 and 6950->5950)

But Ok, i will try to install a p2p OpenVPN for my temporary setup.

For the record, management of certificate is not a problem nowaday since let’s encrypt provide us a convenient API to provide and manage certificates for free :wink:

Usually on linux i defer this headache (of certificates management) to traeffik but for this windows instance where i run voyager… I’ve used lets-proxy2 (https://github.com/rekby/lets-proxy2) without trouble.

All of this does not make really sense without a basic auth…
because we are not going to use MutualTLS authentication !!! :wink:


Regards

Hugues

Server are one . .answer protocol depend on client : Websocket with Json-RPC inside or full Json-RPC direct
Some our tools use direct Json other like Webdashboard use websocket so if we have https we have solved your question dashboard side… problem is manage the SSL certificate … actually i dont know API about Let’s Encrypt … so not all users are able to manage this itself.

In the user side, is it really different from an OpenVPN server configuration ?

SSL with let’s encrypt will be limited to users exposing the voyager server to Intenet (this should be protected).

On the server side there are 2 options:

  • Configure a reverse-proxy to handle the SSL+Let’s encrypt certificats and forward to the voyager backend
  • Configure voyager to manage SSL with let’s encrypt (kind of RFC8555)
    That’s definitly more work !

I could document the installation of a let’s-proxy2 setup for the voyager community.

2 ports exposed via SSL 80 and 5950.
In my screencapture, i already have 443 -> SSL reverse Proxy -> 8080 (voyager web server) (as port 80 is already used for let’s encrypt challenge response)
but the WebDashboard does not allow/manage SSL from the webclient to 5950 via the reverse proxy.