Allow users to bypass certificate validation

[lgrn]

Hi,

Let me start by saying that this looks like a really interesting and polished project, and this is not so much a bug report as a request for feedback, or perhaps a feature request.

I'm experimenting with self-hosting sshx-server, which doesn't seem to be documented from what I can find, but I've pieced together what might be necessary from the Dockerfile and the development instructions. I've got the server running just fine, I can connect to it with sshx and I get a Link that opens successfully in the browser, but I then get crypto.subtle is undefined in the Firefox dev console.

From this question I gather that the reason might be that crypto.subtle refuses to run over HTTP, which I guess makes sense.

The problem is that my instance of sshx-server needs to run over unencrypted HTTP over a VPN, and there is no CA infrastructure set up that allows me to establish "green" TLS connections in this environment. I appreciate that in normal use-cases, it would be insane to run an sshx server over HTTP, but in this case it's not a problem because only connections over the VPN are allowed anyway, and they are already encrypted and authorized.

Questions:

1. Would it be possible to make this work without making changes to sshx-server? My initial thought was that maybe using something like nginx to reverse proxy the traffic could at least allow me to use self-signed TLS, but this would require sshx to take some kind of --insecure flag similar to curl to allow the certificate verification to fail, and the browser can then separately choose to connect "insecurely".

2. Any other ideas on how this could be made to work without having to set up an entire CA infrastructure for the VPN?

[lgrn]

I got it to work decently, I think.

I set up caddy on the node running sshx-server and simply told it to:

[vpn-dns]:443 {
    tls internal
    reverse_proxy [vpn-ip]:8080
}

This works with the caveat that the sshx binary itself will refuse to connect to https://[vpn-dns] since the certificate is self signed. Therefore, when connecting you need to make sure you're using regular http:

sshx --server http://[vpn-dns]:8080

Since this isn't the URL you want back in your response link, you also need to run the server component with --override-origin like this:

sshx-server --listen [vpn-ip] --port 8080 --override-origin "https://[vpn-dns]"

The response given when running sshx then correctly has [vpn-dns] in the link.

In summary, I guess a very minor feature request could be to add an --insecure flag to sshx as it would make setup a bit easier.

[ekzhang]

I'm experimenting with self-hosting sshx-server, which doesn't seem to be documented from what I can find

It is actually mentioned in the README that this is unsupported!

Glad you were able to get it to work for your use case though. Trusting self-signed certificates seems like a reasonable option to have for now. Would #31 fit your use case?

[lgrn]

Well that explains why I didn't find anything!

It wouldn't really help in this case unfortunately since this environment has no independent CA and no current plans to implement one.

While supporting additional CAs is also a good idea, I'd argue that it also makes sense to allow the user to bypass certificate checks for sshx completely if they know what they're doing, much like curl does.

VPN isn't the only use case for this, the connection could also be happening over an SSH tunnel for example, or it could be running on localhost, serving https externally but with no plans to accept external sshx clients. Simply put, it would add a lot of useful flexibility.

[ekzhang]

Makes sense!