On Wednesday 27 March 2002 16.17, Jean-Michel Hemstedt wrote: > - If your proxy allows "CONNECT" requests, then virtually anything > can pass through it, and HTTPS decrypting proxy does not make sense.
A proxy can in theory verify that the supposedly SSL stream looks like a SSL stream and not something else.. The SSL and TLS data streams are quite structured. > It doesn't handle currently any of them. Fragmentation can be solved by > defragmenting incoming packets. (they are destined to the local ip stack > anyway) Defragmentation is defenitely needed for this thing to be used in production. For experimentation conntrack can be used to defragment.. > ICMP can be handled in the prerouting hook looking up possible transparent > proxy entries. Where is the "possible transparent proxy entries" defined? Internally in TPROXY, or in the host IP stack socket table? I guess this would be the rule table telling what should be diverted by TPROXY, which from my understanding would be your iptables ruleset... > > Also, who is responsible for making sure the application protocol is > > NAT:ed properly in TPROXY. > > Of course the proxy itself. Good. > conntrack will not be involved in TPROXY, though I want them to > interoperate. Of course. Just mentioned it as a reference on why I see that one cannot really use netfilter NAT for truly transparent proxying as it is today. Regards Henrik
