From: Toni Mueller [mailto:[EMAIL PROTECTED] > > moreover, when you think about it, ftp w/TLS encrypts the control > > channel, it's the entire point that 3rd parties (like > ftp-proxy) can't > > see or modify what's gpoing on, so this cannot possibly work. > > I can't see why this must be so. HTTPS can be proxied with Squid which > "somehow" handles the crypto stuff after reading the client's "CONNECT > ...", and digging into FTP+SSL suggests that the control channel could > be used to break end-to-end encryption into two pieces, originating or > terminating at the gateway machine. Eg. the client says "AUTH TLS" to > start negotiating SSL...
But to my knowledge, squid has no idea what is happening inside of the HTTPS session, since it is end-to-end encryption, and doesn't proxy the connection like it does vanilla HTTP; i.e. it just passes the connection through and is unable to do content inspection and so forth. Similarly, how would ftp-proxy get around the same limitations? The client will negotiate the TLS based on the certificate presented by the server; if the FTP client is instead negotiating with ftp-proxy, it won't be carrying on a conversation with the trusted certificate presenter. Part of the point of the TLS security is to protect from MITM anyway. Could be mistaken, but I think it just inherently isn't going to work. DS
