[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
