[Feature Request] Support for using TLS/HTTPS

[Karbust]

Hello,

Adding support for using HTTPS would be great.

I use NGINX as a reverse proxy and entrypoint of my house to the world, only available on port 443 for everything.

I tried to use it but then got this error when try to login:

Went ahead and opened the port 80 and was able to login but would would also need to open the port 8188 (would use unsecure WebSockets), I'm not willing to keep unsecure ports open, so my solution is just use ZeroTier and access through it on HTTP.

Thank you

[owendelong]

+1 for needing HTTPs support. In this day and age, not supporting TLS/HTTPs is kind of absurd. I've deployed one of these in a datacenter with a public address and intend to deploy more. However, it's a non-starter if I have to send my access credentials over an insecure channel and I don't want to have to mess with additional dependencies beyond my very basic OOB network setup because the whole point of this is "holy shit, everything is broken, let's get on the console and see what we can do". If enough stuff is working to get the VPN and everything else going, then I probably can just SSH in.

Yes, I could probably SSH tunnel HTTP direct to the KVM, but again, kind of an extra overhead step at a time when I don't need that hassle.

I'm sure you have your reasons for using your own web server instead of NGINX or APACHE, but if you used either of those, then TLS support would basically come along for free.

[owendelong]

I looked at this a little bit today in the BLIKVM-webserver repo. It looks like it should require some fairly trivial changes to the initialization of SWOOLE_HTTP server. I may take a stab at implementing. Some questions...

What are the preferences in terms of implementation:

Option 1: HTTP server simply redirects to HTTPs and does not function as a KVM server. (This would be my preference) Option 2: HTTP and HTTPs server are both accessible and behave identically. (This would be maximum backwards compatibility, but also the most risky choice from a security perspective, so I discourage it) Option 3: Provide some configuration mechanism for the administrator to select between option 1 and option 2, in which case I would strongly encourage that option 1 should be the default behavior. If this is the desired choice, where/how would that configuration mechanism be implemented?

If I do implement, I'll leave a hard-coded placeholder in the code pointing to a fixed filesystem location where default "snake-oil" certificate, key, and ca-chain files will be installed with recommendation that those files be replaced with a real certificate, key, and ca-chain. It may be desirable (long-term) to provide a web-UI mechanism for uploading/configuring certificate management (though I have reasons for thinking that might not be the best idea).

Do the core developers have a preference for where I put the PKI files? Absent input, I'll probably create /usr/share/ssl if it doesn't already exist and place them there.

[owendelong]

Some code examples that are relevant are in this SWOOLE issue: https://github.com/swoole/swoole-src/issues/2047

[twu2]

add following setting to nginx will make login work. add_header Content-Security-Policy "upgrade-insecure-requests";

but, it will also force 8008 video stream using https, so you also need to change kvmd-video.sh to using another port (like 8188), then add proxy in nginx for https 8008 to http 8188.

above change will make https work. but http video not working anymore.

so, I unpack kvm-link, modify the code to listen 8080 for web, and using 8018 for video streaming, repack it as kvm-link-ssl (in the attachment). then keep kvmd-video.sh to using 8008 port for video stream. modify kvmd-web.sh to execute kvm-link-ssl after kvm-link. then in nginx, proxy https 443 to http 8080, and proxy https 8018 to http 8008

this will make both http and https work. kvm-link-ssl.zip

[owendelong]

I'm hoping to do this with direct HTTPs support in the BliKVM daemons rather than using some hacked proxy and all the additional overhead that comes with that.

I don't really need HTTP to work and would prefer that it is just there to produce redirects to HTTPs connections.

[twu2]

here is better solution to support https via Nginx.

1. unpack kvm-link
2. change video_stream_url() in dist/built-package/index.6b657291.js (filename might changed for different version) from: video_stream_url(){return`http://${yn.video_host}:${this.mjpeg_port}/stream?advance_headers=1`} to: video_stream_url(){let port=this.mjpeg_port+(location.protocol==='https:'?10:0);return`http://${yn.video_host}:${port}/stream?advance_headers=1`}
3. zip dist folder to dist.zip
4. repack kvm-link
5. replace /usr/bin/blikvm/kvm-link with modified kvm-link
6. in Nginx, add server to proxy port 443 to port 80 and proxy port 8018 to port 8008 like this:

server {
        listen 443 ssl http2;
        server_name kvm.localdomain;

        include conf/ssl.conf;

        add_header Content-Security-Policy "upgrade-insecure-requests";

        location / {
                proxy_redirect off;
                proxy_pass http://127.0.0.1:80;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
                proxy_set_header Host $http_host;
        }
}

server {
        listen 8018 ssl http2;
        server_name kvm.localdomain;

        include conf/ssl.conf;

        add_header Content-Security-Policy "upgrade-insecure-requests";

        location / {
                proxy_redirect off;
                proxy_pass http://127.0.0.1:8008;
                proxy_http_version 1.1;
                proxy_set_header Upgrade $http_upgrade;
                proxy_set_header Connection "upgrade";
                proxy_set_header Host $http_host;
        }
}

attach is the modified kvm-link of 1.3.9 version. kvm-link.zip

[erlendoyen]

will these changes to the change video_stream_url make it into a new release?

[xenago]

Any updates on the status of this @ThomasVon2021 ? HTTPS is pretty critical

[ThomasVon2021]

Any updates on the status of this @ThomasVon2021 ? HTTPS is pretty critical

https://github.com/ThomasVon2021/blikvm/issues/41#issuecomment-1970588148

[owendelong]

It would still be nice to get native HTTPs support in the shipping package rather than having to cobble NGINX in front of it as a proxy.

[xenago]

Any updates on the status of this @ThomasVon2021 ? HTTPS is pretty critical

#41 (comment)

Is this link an error? It just seems to link to my comment above

[owendelong]

I suspect he was saying that is the solution so far. I agree with you that it is not ideal.

[ThomasVon2021]

It would still be nice to get native HTTPs support in the shipping package rather than having to cobble NGINX in front of it as a proxy.

You will get it.

[owendelong]

It would still be nice to get native HTTPs support in the shipping package rather than having to cobble NGINX in front of it as a proxy.

You will get it.

Awesome... Thanks!!

[ThomasVon2021]

You can update to 1.4.4 alpha to test. https://wiki.blicube.com/blikvm/en/https/

[erlendoyen]

You can update to 1.4.4 alpha to test. https://wiki.blicube.com/blikvm/en/https/

thanks, that works.