Keep source IP using TPROXY

[arinc9]

I need the attacked server to see the original source IP. Since I am in the middle, I have control over the route paths of both sides. Traffic from both sides will flow through my router.

A single IP address taking all the TLS connections is going to raise eyebrows.

TPROXY seems to be where this could be possible as it keeps the original destination address and doesn’t rely on NAT.

Is this currently possible with SSLSplit?

I run it with this and I can see on the outgoing packets that the source IP is of the router I run the sslsplit on.

sslsplit -P -Z -t certs/ -l connections.log -S log/ ssl 127.0.0.1 8443 tproxy

[sonertari]

I guess you already know that sslsplit opens a new connection to the server, so the server receives packets from the new source address, which is the external address of the MiTM proxy. So, it's perhaps my lack of knowledge, but I don't how tproxy can help us use the client address while connecting to the server.

[arinc9]

What I understand is we can read the source and destination IP address on the packets intercepted via TPROXY.

Currently (with masquerading)

I'm not sure how exactly masquerading works on SSLSplit, so below is my vague vision of it.

Outgoing traffic (traffic originating from SSLSplit):
Source IP address is translated to the external address, source port is either kept or translated to whatever port is available on the server SSLSplit runs on.

Incoming traffic (traffic coming into SSLSplit from the targeted server):
Traffic for a client is distinguished by the destination port on the incoming traffic. After we figure out which client the incoming packet is supposed to go to, destination IP address is translated to the said client's address, destination port is kept if it wasn't changed on outgoing traffic, or translated to the original if it was.

Would be (without masquerading)

Outgoing traffic (traffic originating from SSLSplit):
Since SSLSplit opens a new connection, packets will leave with the server's external address as the source IP. SSLSplit needs to read the source IP of the intercepted packets and rewrite the source IP when going out of SSLSplit. Source port is kept.

Incoming traffic (traffic coming into SSLSplit from the targeted server):
Traffic for a client is distinguished by the destination address on the incoming traffic. Destination address and port is kept.

[sonertari]

Sslsplit establishes a new connection with the server. There is no address translation in sslsplit. And I have no idea how sslsplit can use the client address to connect to the server (sslsplit and the client run on separate machines).

[arinc9]

Sslsplit establishes a new connection with the server. There is no address translation in sslsplit.

Understood, that's misconception from my part. Although there's a certain mechanism to distinguish traffic intended to go to different clients (which packet should go to which client), similar to what I pictured above, correct? I don't really know how handling clients over transparent proxy works so I had assumed the proxy program would do sort of what the MASQUERADE target does.

And I have no idea how sslsplit can use the client address to connect to the server (sslsplit and the client run on separate machines).

It's technically originating a packet from SSLSplit with a fake IP (which is the address of the client). It doesn't belong in the network MitM proxy is in. So, once the packet with fake IP is delivered to the targeted server, it's going to reply back to that said IP address, which will flow through our device being the MitM. We can easily intercept that and feed it to SSLSplit. Then SSLSplit would do what I explained above to distinguish the packet to a certain client, do the SSL/TLS inspection and send the packet back to that client.

Reading the source and destination address of the intercepted packet from SSLSplit though, that, I do not know. Coding is not my strong suit.

[sonertari]

You apparently have a very special network configuration. Underneath sslsplit is libevent. I don't think libevent can spoof IP addresses. So, in the end, the answer is that sslsplit does not support IP spoofing.

[arinc9]

I wouldn't call it special but rather a specific attack vector. I'm currently writing a research piece about the importance of layer 2 security on hosting providers. I want to point out the catastrophy their carelessness of properly isolating virtual servers would bring upon them.

This gives me the ability to do ARP spoofing attack on the targeted webserver which allows me to get a valid Let's Encrypt certificate for their domain and run SSLSplit with it to sniff client's sensitive information without them seeing any insecure connection warnings.

This process is already completely transparent to the client as the only thing that would give this away is the different certificate but since it's valid, no one would look at it twice.

Webserver side could very easily notice the attack with the current state of SSLSplit. Suddenly, all the traffic they serve over TLS becomes this single IP address. This is why I wanted to hand the traffic to the webserver with the original source as the source IP so the attack would become much harder to detect.

Squid's TPROXY page seems to imply that this is possible via the spoof_client_ip config directive. I basically want the same thing on SSLSplit.

TPROXY seems to support what I want:
https://github.com/darkk/redsocks/blob/master/doc/balabit-TPROXY-README.txt#L28
The doc above also explains the implementation to bind to foreign addresses to listen for connections.

[arinc9]

Here's an answer related to bind() to remote addresses:
https://stackoverflow.com/a/26507847

[matoro]

I also have the exact same network setup and am looking for a way to implement this! Did you ever find anything that would allow you to keep client source IP, if you control the upstream router that any returning traffic would be passing through? I really want to use sslsplit for this for the packet mirror feature, but in my architecture there is a second router upstream of me that is responsible for all NAT, so I don't want to introduce a second layer of NAT, especially with IPv6!

[arinc9]

Unfortunately I didn't. I had to move on to other things at hand and have been handling them since. Life amiright?