-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Toni Mueller wrote:
| 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... Hi Squid is different. Usually, it doesn't do SSL itself, but just passes the connection on. With FTP the problem is that there's information exchanged over the control channel that is used in establishing the data channel (esp. the PORT command in active or the ip address + port tuple in passive mode). You might be able to code around that by terminating two distinct sessions on the gateway, and have the gateway read the data channel, but then you would as well break authentication (i.e. certificates can't be checked anymore as the proxy needs to present its own certs and accept the original client's and server's ones). And if there's a stateful firewall or other stateful device between the proxy and server, it'll just not know the ports negotiated on the control channel and drop the data channel even if configured to allow ftp (except for the rare case where a firewall admin will have opened ports 1024-65536). Plus, afaik there'n no provision in the FTP protocol for proxied connections, but that problem isn't specific to ssl'ed connections. -----BEGIN PGP SIGNATURE----- iD8DBQFDFzqU8BX/d8pVi/cRArzrAJ96nV5d/MZgo6eTldj0k/GwOvVU7ACeOKyx nqvJ5Ra3Nq+3guAtD7DJGEM= =udbo -----END PGP SIGNATURE-----
