TLS/SSL Passthrough

[vetch101]

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

[jpillora]

Not super clear about what you want to do though: In general, chisel makes two TCP endpoints equivalent. This is separate from TLS. In most cases, TLS only requires one thing: the hostname (SNI) to match the returned certificate.

So you can do:

`my-server.com:443` chisel client -> chisel server `remote-server.com:443`

As long as you serve remote-server.com certificate on my-server.com it should work

[vetch101]

Thank you for coming back to me! Looking back at this, I see that I'm not being super clear. Sorry!

So to provide a bit more detail, the servers are running filebeat and pointing to chisel client which proxies via chisel server to the logstash server.

I think what would be ideal would be for the TLS connection from the filebeat instance to be "passed through" the chisel proxy to the logstash server with the traffic still encrypted so that logstash can authenticate the filebeat instance based on the key, rather than establishing the TLS connection with the chisel client by exposing the logstash server certificate...

Does that make sense?

(BTW - loving that you're working on adding UDP support! Very cool!)