Quesion: Can SSLproxy be configured to not re-encrypt the traffic?

[lemur117]

I'm exploring if this will work for my application. Actually, I'm hoping to use two instances of SSLproxy in the following manner:

Server A is my HTTPS server with my certificate and private key
Client A is my client that will connect over SSL to my HTTPS server
Router A will route the traffic (based on Server A destination) to Proxy A
Proxy A will be a decryption-only proxy that will have a copy of Server A's certificate and private key, so it can decrypt the traffic. Then it will route the decrypted packets back to Router A with layer-3/4 transparency (source will still be client IP/port and destination will still be server IP/port. Maybe tproxy and IP_TRANSPARENT will be needed for this part?)
Router A will route the decrypted packets through a chain of programs, each which will route back to Router A with layer-3/4 transparency.
At the end of the chain of programs, Router A will route the decrypted packets through Proxy B.
Proxy B will encrypt the traffic and route back through Router A with layer-3/4 transparency and Router A will send the encrypted traffic to Server A.

The return traffic will go through all the same hops as above, but in reverse order. E.g. Proxy B will receive the encrypted traffic from Server A and will decrypt it before sending back through Router A.
(I'm using the term "route" a little loosely above, as most of it will by L2 switching.)

Can SSLProxy be used in such a scenario, where one instance is only decrypting the traffic, and one instance is only encrypting the traffic? I see from the documentation that SSLProxy can itself invoke the external programs on the decrypted traffic, but I don't think that will work in my application since "Router A" will be making the decisions of which programs to invoke, and it needs to have the decrypted traffic to do so.

[sonertari]

Short answer: I don't think SSLproxy can help you do that, at least as you describe it. As described in its README, SSLproxy can decrypt and divert packets to other programs, and the listening programs must return those packets back to SSLproxy.

I guess you don't have much control over the Router A in your description, perhaps it is one of those closed source commercial products. And I guess that is why you cannot directly use sslproxy to do all of these. Because otherwise SSLproxy is designed to do this as Router A in your design. (Btw, sslproxy does not invoke listening programs, it just diverts packets to them, but I guess you already understand that.)

Also, note that once you divert a packet to another program at L3/4, the source and destination addresses of the packet will be lost. And the only way the listening program to know those addresses is by processing the info in the SSLproxy line in the first packet diverted to it, as described in README. Accordingly, note that even if the second (imaginary) sslproxy which was supposed to reencrypt the packets in your design were possible, that second sslproxy would have to process the SSLproxy line inserted by the first (imaginary) sslproxy decrypting the packets. SSLproxy is a MiTM proxy, and I don't know how this can be done at L2.

Also note that the packets generated in mirror logging are pseudo packets sent to mirror targets at L2, just for logging purposes, so that mirror logging does not help either.

[lemur117]

Thanks for the quick response! How difficult would it be for me to modify the source code to where the outgoing traffic is not encrypted? I've only started perusing the code, and I saw IP_TRANSPARENT and TPROXY are present in some of the files. That's making me hopeful that I could maintain the client's source IP/port in the outgoing (server-bound) packets, similar to how the squid proxy can use tproxy to masquerade as the client. If I can disable the server-side encryption, then I could have a trivial mirroring application that sslproxy diverts the decrypted packets to, and it just sends them back to sslproxy (maybe iptables could perform the rerouting so it doesn't even hit an external application, but merely flows straight back to sslproxy's source port)?

[sonertari]

If you can develop a listening program, then sslproxy can divert the decrypted packets to it. The first packet will contain the SSLproxy line which will include the source and destination addresses you will need. Once you obtain that info, you can do whatever you want with that packet.

If you don't return the packets to sslproxy (from the listening program or somewhere else, but you should return it to the dynamically assigned port reported in the SSLproxy line), the connection will eventually time out (the timeout period can be configured). Normally, this should never happen, because we try to close the connections as soon as possible to reduce resource usage (but it happens with persistent connections, such as those to Github).

But I have no idea if this will help you in any way. Because, for example, after receiving a connection from a client, sslproxy connects to the target server first, so that it forges the certificate of the server to use with the connection to the client. As should be obvious, if you don't return the packets to sslproxy, another program (for example, the second imaginary sslproxy) should open another connection to the server to reencrypt and send the packets to the server. This does not sound right to me.

So, I am not too hopeful that you can modify the source code of sslproxy to achieve what you describe. Perhaps you can understand better once you are more familiar with its source code. Perhaps you can find a way, but the modifications needed would be quite considerable, imo.