From: Spruell, Darren-Perot (Darren.Spruellchw.edu)
Date: Thu Sep 01 2005 - 12:13:24 CDT

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]

From: Toni Mueller [mailto:openbsd-miscoeko.net]
> > 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

• Messages sorted by: [ date ] [ thread ] [ subject ] [ author ]