4

I am wondering if there is a practical way to establish a secure, encrypted network connection through an MITM proxy given the ability to communicate secrets out-of-band with a second, external proxy. Let’s say the MITM is part of a corporate firewall, a filtering ISP, or it’s set up by a dictatorial government.

If the only way to establish an initial connection is by accepting the certificate presented by the MITM, then the proxy can monitor the contents of the entire exchange. This question suggests:

Clearly SSL-over-SSL-over-SSL-...-over-SSL works most of the time for corporate firewalls and the like, but it relies on security by obscurity and the handshake would take forever.

I understand why the handshake would take a long time, but I don’t understand why it ‘works.’ If the MITM can read the traffic, would it not intercept nested certificate and key exchange as well?

But let’s assume that I can set up a trusted proxy outside, on the other side of the MITM, with a preshared key. Is there an easy way to establish an encrypted tunnel through the untrusted connection? I am imagining that by using a symmetric cipher I could skip the certificate check and key exchange, which the MITM would catch, and just start transmitting encrypted data. Then through this second tunnel, I could establish a trusted connection, ideally SSH.

I imagine that a determined MITM could potentially deduce the encryption scheme and key by observing the traffic over a long period of time, but I am not concerned about such a drawback. The ability to do this would be useful on a short-term basis, and the ability to rotate the preshared key out-of-band would allow somewhat longer-term use.

I’m interested in a practical, immediate solution. Is this feasible? Is there existing software (preferably OSS for linux) that does this? If not, is there a library that would make such a solution easy to build?

1

2 Answers 2

2

With regard to:

But let’s assume that I can set up a trusted proxy outside, on the other side of the MITM, with a preshared key. Is there an easy way to establish an encrypted tunnel through the untrusted connection?

Yes. One simple way to do this is to setup a SOCKS5 proxy, which allows you to tunnel your connection through an SSH server. The topography would look like this:

client <-> MITM <-> SSH Server <-> Host Server

This sets up an encrypted tunnel between the client and the SSH server, which 'passes through' the MITM. This tunnel is secured using the SSH server's public key, which can be pre-shared in advance with the client. Request from the client are sent through the tunnel to the SSH server, which then forwards these to the host server. Then, responses from the host server are sent back to the SSH server, which forwards these back to the client through the tunnel.

Being that the tunnel is secured using the SSH server's public key, the MITM is unable to 'listen in' or tamper with the requests and responses sent through the tunnel. Of course, when the MITM sees an encrypted connection passing through it, which it is unable to intercept, it can simply drop all the packets passing through the tunnel, and essentially block the connection altogether.

Of course, presumably you would have another layer of encryption end-to-end between the client and the host server. For example, if the client and the host server are communicating by HTTPS, this would be TLS. So, you would have an 'inner tunnel' between the client and the SSH server (the SOCKS5 tunnel), inside an 'outer tunnel' between the client and the host server (the TLS tunnel). The 'outer tunnel' prevents the SSH server from listening in or tampering with requests and responses between the client and the host server. Also, the handshake and key exchange parameters used to setup the outer tunnel cannot be seen by the MITM, because these are sent through the inner tunnel.

Setting up a SOCKS5 proxy is fairly simple using Linux. All that is needed is an SSH client on the client, and an SSH server on the server. On most modern Linux distributions, these are installed by default. Once the SSH server is configured to allow connections from the client (e.g. typically using client public key authentication), then setting up the SSH tunnel is just a matter of running a simple command on the client. See https://ma.ttias.be/socks-proxy-linux-ssh-bypass-content-filters/ for a good write-up on how this is done.

2
  • Indeed, a SOCKS5 server over SSH was my intention, although this project seems even more promising. I am not sure I understand why you describe the TLS connection as the ‘outer tunnel,’ since it is going through the SSH tunnel, so I would have thought it is the other way ’round. Commented Mar 3 at 19:26
  • In any case, as you point out the MITM may not allow SSH (in my case it was blocked). My question was if there is a way to tunnel the SSH (or some other form of encrypted traffic) through an untrusted connection. Commented Mar 3 at 19:34
2

If the MITM can read the traffic, would it not intercept nested certificate and key exchange as well?

Just because it is possible does not mean it will be done. Instead of deeper and deeper inspection tunneling TLS inside TLS could simply be blocked because the user is not supposed to do this. And this can be the case for everything which does not look like expected traffic - either it will be passed through without further analysis (less restricted environment) or it will be blocked (more restricted environment). Intercepting proxies in less restricted environments are easier to bypass for employees trying to ignore company security policies, but are unfortunately are also easier for attackers.

I’m interested in a practical, immediate solution

One way would be to use a VPN or proxy over Websocket. Given that Websocket has contrary to HTTP much less expected structure (basically just the framing of the payload) it often is just passed through without further inspection. See for example wstunnel.

Please note that it is not a good idea to use such tools to deliberately bypass corporate security measures. This is very likely against the company policy and for a reason since it weakens the company security. Don't assume that nobody will find out.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .