HTTPS for local access?

[Pavlos1]

Is there a way to set up an encrypted connection to JetKVM over the local network?

My interim solution is to use SSH tunnelling, which works well but requires manually enabling the loopback interface. (i.e. SSH'ing in to JetKVM and running ifconfig lo up)

[Nevexo]

It's not currently possible to enable HTTPS for the Web UI, it will be soon, though.

Rest assured that WebRTC (and by extension, video & control) channels are encrypted in-flight.

[Pavlos1]

Ah, so keystrokes sent to the remote machine are encrypted as well? That would clear up my primary concern.

A https option would still be a good mitm defence, so happy to hear that it's on the roadmap.

[Nevexo]

Ah, so keystrokes sent to the remote machine are encrypted as well

Yeah that's all safe. If you capture traffic between your machine and the JetKVM you'll see DTLS traffic (https://webrtc-security.github.io/)

[tutman96]

I would hesitate to call it “safe” since the original webrtc exchange does happen in plaintext, so could be intercepted by a malicious actor on your network. This is the same risk as if you were using unsigned certificates for TLS as well. As a note, the cloud-based access is fully e2e encrypted.

[xedoc64]

As a workaround I would suggest to place an nginx or Apache as reverse proxy in front of the JetKVM. Works for me perfectly.

[merashallan]

As a workaround I would suggest to place an nginx or Apache as reverse proxy in front of the JetKVM. Works for me perfectly.

Are you running nginx on the JetKVM? If so where did you get a compatible (arm7l) executable?

[xedoc64]

As a workaround I would suggest to place an nginx or Apache as a reverse proxy in front of the JetKVM. Works for me perfectly.

Are you running Nginx on the JetKVM? If so where did you get a compatible (arm7l) executable?

No, I ran it on a NAS which acts as a reverse proxy anyway

[mircea-vutcovici]

Encryption should be as close to each endpoints as possible to avoid MITM attacks. The SSL endpoint must run on JetKVM.

[vladak]

I assume there will be a way to set host certificate + key along with the CA cert chain, supplied as files through the UI. I wonder how would you approach the bootstrap ? Generate the host certificate with IP address (either in SAN or using the iPAddress alternative name format) and regenerate it whenever the IP address changes ? (perhaps using host based CA so that one does not have to confirm the security exception every time)

[kpieckiel]

@vladak, re: bootstrap, I do appreciate your thinking about ways to solve the problem, and I'd like to suggest a different approach. Rather than expend effort developing a certificate regeneration mechanism when the IP address changes, I think dev cycles are better spent on static IP support and standard certificate configuration options. I wouldn't put the IP address in the cert as a SAN or otherwise anyway, and I've not run into anyone that does so on a corporate production network. When static IP addressing is added, this will be a non-issue regardless.

As for HTTPS support in general, yes, the cert + key would have to be supplied, but I think the cert chain can be optional. (I'd be happy with putting the files in place via SSH now and add web UI support later, but I think setting up certs should eventually be in the web UI if not included right away.) There's no (or very little) point to adding HTTPS support if we can't provide our own signed certs--either publicly signed or signed via corporate CA--although I think self-signed certs should probably be an option for the home users that don't set up a local CA or want to buy a cert. An embedded (optional-use) signing certificate can be included or generated upon initial setup to take care of those users, and the cert can be downloadable so it can be added to the local certificate store if desired.

[Gunni]

What if you use a similar method to what Plex uses.

AFAIK they get a wildcard cert for *.<serverid>.plex.direct so that they can use f.ex <ip, with dashes>.<serverid>.plex.direct securely.

I assume they do a cert request via their infrastructure somehow, I haven't looked into how it works but they have every server accessible via https by default.

Now, we don't want KVMs accessible publicly, so instead maybe we could do a dns validation via a domain you (you being JetKVM) own, kvm sends you a csr from itself, you verify the device identity matches the csr, and add to dns, dns validation proceeds and you get a cert back, which you give to us. Key never leaves the KVM.

Maybe the default/main webserver should redirect to the hostname we got a cert for? not sure, but you need to be able to discover the secure name somehow... f.ex you connect from 192.0.2.1 to the jetkvm via ipv4, it returns a redirect to (either return the ip from the same subnet the client conected from or the default route ip) https://192-0-2-42.dfgtyhujnyhgtrfgtbyh.jetkvm.example.com and jetkvm.example.com should of course be HSTS preloaded. IPv6 could work similarly, just fe80-blabla.dfgtyhujnyhgtrfgtbyh.jetkvm.example.com.

This might hit DNS rebinding protections, but so does Plex. HTTPS is worth it!

Ofcourse you should be able to upload&configure your own domain/cert/let's encrypt config, imo but the above lets you get there securely.

[tomtrostel]

While the communications may be secure after a session is established the initial password login happens in clear text which gives me some concern. Does it not? Feel free to disagree.

[Gunni]

While the communications may be secure after a session is established the initial password login happens in clear text which gives me some concern. Does it not? Feel free to disagree.

If the method I proposed is used, then only the http request for jetkvm.local is http, it then redirects the user to the https hostname as I explained above.

Credentials do not pass over http.

[agoodkind]

Any update on this?