Henrik, just to recap the goal: I have: - non-proxy aware clients (not controlable) - non-transparent aware proxy (not controlable, and even not on Linux, it is not in-housed)
an in the middle: - one (or more) default gateway, the netfilter box. => goal: 1) HTTP: rewrite the HTTP requests (PDU) so that they can be handled by the proxy. 2) HTTPS: insert the CONNECT transactions so that the proxy can create its https tunnel to the orig-server. (and there is no mitma issue) 3) for both: keep the source ip addresses of the clients in the modified forwarded packets, so that the proxy can do simple source based authentication (possibly with the collaboration of exteral elements such as radius, but athentication is out of scope here). I appreciate your propositions, but since we don't see the origin-server, since we are forced to pass the requests through the proxy, since the proxy is not controlable, since the PDU needs to be rewritten, and since the stream itself needs to be modified (https), none of them (CONNMARK or GRE tunnel) seems to be applicable. The big issue is point 3 above, given that 1 and 2 needs to be handled. nonlocal_bind or contextual SNAT could be the solutions... But my NF level of experience is too weak for the moment to see how it could be achieved, or how to reuse existing mechanisms. (i.e: how to make NAT and REDIRECT collaborate, or how to crack nonlocal_bind protection). best regards. ----- Original Message ----- From: "Henrik Nordstrom" <[EMAIL PROTECTED]> To: "Jean-Michel Hemstedt" <[EMAIL PROTECTED]>; "Balazs Scheidler" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, 20 March, 2002 00:12 Subject: Re: TPROXY > [cannot claim I have been following the thread closely, mostly > guessing on what you are actually trying to acheive here.. so I may > be way off] > > On Tuesday 19 March 2002 12:19, Jean-Michel Hemstedt wrote: > > > REDIRECT could work in case of collocated proxy, and only if we > > have control on the proxy, i.e. Apache; > > (btw: I'm curreltly trying to find a clean and reusable way to > > extend transparent > > HTTP mod_tprox and add HTTPS transp proxy to Apache for Linux). > > REDIRECT works only if the you have a user space proxy is running on > the machine doing REDIRECT. This is per definition of REDIRECT. > > > But I'm afraid REDIRECT doesn't fit for remote proxies which rely > > on the originam > > source ip ofthe client to perform some checks. In that case we need > > the 50080/50443 > > applications of your example to forward the modified requests to > > the remote proxy > > with the source.ip of the original client. > > If the remote proxy is on the same LAN segment or if you can set up a > GRE tunnel or something similar to the proxy server then you can use > CONNMARK for this purpose to route the packets unmodified to the > proxy and then do the final interception there. When you see the NEW > session in mangle, mark it, then use fwmark based routing to route > the packets of that session to the "close by" proxy. > > > 1) the 50080/50443 applications use libipt and for each new client > > request, before doing > > a new connect() to the remote proxy, they create a new iptable rule > > doing SNAT based > > on the --sport they choosed for their bind(). And when the > > connection is released, they > > remove the created rule. This solution is very inefficient, and not > > scalable. > > Yuck. > > I would rather go for a single daemon using a custom protocol to > forward the information to the origin server, such as the > (incidentally) named TPROXY extension I was once playing with for > Squid, archived somewhere on my "old Squid patches" page > <http://devel.squid-cache.org/hno/patche-old.html> on how to manage > remote interception of traffic. > > But sure, this is a limitation of the "transparent proxy" > capabilities of the current iptables framework. > > I think some aspects of SOCKS can also be used for this purpose. > > > 2) the 50080/50443 applications rely on TPROXY framework and uses > > nonlocal_bind. > > Except that nonlocal_bind do not yet work in TPROXY, does it? > > > 3) ??INTERCEPT?? = REDIRECT(PREROUTING)+SNAT(OUTPUT/POSTROUTING?) > > i.e: > > A:pclient1 <> [REDIRECT--dport80] <>Bserver:50080<>Bclient:pclient2 > > <> [SNAT(--to A:pclient)] <> C:80 > > => > > the INTERCEPT would REDIRECT the packets from the client to the > > local stack and pass a 'rdmark' to the user space application > > retreivable via getsockopt(rdmark). > > Then, the application rewrites the packets and in order to forward > > them to the remote > > proxy, it creates a new client socket to the remote-proxy and uses > > setsockopt(rdmark) > > to instruct netfilter to do SNAT on the outgoing packets > > (OUPUT/POSTROUTING?). Netfilter uses the 'rdmark' to retreive from > > the redirect table the '--to' information (the > > source.ip before the redirect). > > When a packet comes back from the remote-proxy the reverse SNAT > > redirects the packets to the local client, which pass the packet to > > the local server which sends > > back to the original client the modified packets... > > Very much sounds like CONNMARK is what you are after here.. Allows > you to selectively reroute individual tracked sessions without > needing to rely on NAT. But if you need to rewrite the payload then > CONNMARK obviously won't help you.. > > > > Zorp supports HTTPS, but it doesn't encapsulate it into CONNECT. > > > It simply decrypts ongoing traffic, checks HTTP within it, and > > > sends it on reencrypted. But for this to work you'd need to run > > > Zorp on your firewall (where it was meant to run) > > At the cost of totally invalidating SSL in terms of proxying. > > - Client can no longer verify the authenticity of the origin server > further than the proxy. > - Servers can no longer authenticate or verify the client. > > Typical man-in-the-middle scenario. > > I assume we are talking about what is nominated by the IEFT WREC > group as "surrogate" servers rather than proxies here.. If not then > decrypting proxied SSL traffic is a serious breach of security. > > Regards > Henrik Nordström > >
