TLS/SSL Passthrough

Hi All,

I've been playing with Chisel for a while now; love what it does!

Recently, started building some of the forks and made a version with:
#78 client outbound SOCKS support from aus
#79/#85 support for connecting chisel server via socks5 in client from meteorite (though I haven't been able to get daisy chaining of chisels working together)
#84 skip tls certificate verification also from meteorite
... and #129 for TLS serving from server and CA verification to client from mvladev...

All very awesome! Thanks all!

... anyway... I'm using chisel inside Kubernetes, (currently) behind an NGINX ingress.

I have a socks tunnel listening on a management VM, through which multiple client machines can proxy through to the server end to push (non-HTTP/arbitrary TCP) log data to various services on the cluster IPs.

Effectively, the data flow is:

svr 1 -->
mgmt vm chisel client socks--> internet ---> [nginx -->] chisel server --> log server
svr 2 to srv n -->

Ultimately, my goal is to have the end-to-end comms encrypted, but at the moment, comms from server 1 to server n (svr1/svr 2 to srv n on the "diagram") are being sent within the client environment with no encryption.

The log forwarder on svr 1-n and the log server both support TLS with certificate based auth, so theoretically, that would be the optimal approach.

Based on that idea, I'm trying to work out if it's possible for servers 1 to n to be able to use SSL/TLS passthrough for the TLS traffic, via the chisel socks proxy, through the NGINX ingress, through the chisel server, to the log server, so that the log server can authenticate the servers individually based on their certs (and vice versa).

FWIW - I could strip out the NGINX ingress (hence the brackets in the diagram), but it supports SSL passthrough, so (in theory) I don't think that should be necessary.

Is there any way to enable SSL passthrough on the socks proxy? Or, if not, through a chisel proxy port?

If not, perhaps there's a way to put a TLS connection in front of the client serving relevant keys locally, and then forward de-TLSified incoming traffic over the (already TLS/SSH) tunnel?

I suppose that if I could set the client to be fronted with TLS, as per #129 on the server end, that would allow for TLS within the client site, but I'd need to find a way to forward the traffic over the tunnel...

Another approach might be to work out how to get Meteorite's --upstream-proxy working in order to daisy chain the socks proxies...?

Not sure... I've tried several iterations with this; at this point, I'm wondering whether it's possible at all... Is there maybe an issue with trying to send arbitrary TCP traffic over the TLS/SSH tunnel?

Anyone have any suggestions?

Cheers,

J

Start by reviewing the SOCKS proxy and client/server tunnel paths described in the issue, along with the NGINX SSL passthrough arrangement. Determine whether arbitrary TLS traffic and per-server certificate authentication can pass end to end, and document the supported configuration or the missing capability. A reproducible Kubernetes or proxy setup would clarify the result.