--- Bob Snyder <firstname.lastname@example.org> wrote:
> On Thu, Oct 07, 2004 at 05:37:52AM -0700, Mike Mestnik wrote:
> > Sorry, squid uses NFS for remote storage. This is not like being an
> > server, that a client could connect to. Since there is no way for a
> > client to connect, how would squid know it should connect to a server
> > it even could? If there's a patch or hack, I don't think debian will
> > shiping it in the squid package.
> Squid (or most any other https proxy) can usually be set up to tunnel
> aribitrary TCP streams, assuming it allows users to specify port
> numbers, like https://www.example.com:4000/
If there was a squid server running on port 4000 of www.example.com this
URL won't work or do anything at all.
> The only thing needed is to send the appropriate CONNECT string after
> the connect to squid is opened. After the CONNECT string, squid just
> passes bytes back and forth.
NFS Client's, even the TCP ones, DON'T do this. :)
I'm sure there may be TCP nfs client's that could be configured to use a
proxy, but that won't help an MITM attack.
> I'm not sure I understand the original problem... Two hosts configured
> to be on seperate subnets but on the same wire? Two hosts with some kind
> of layer 2 device blocking connectivity between them but on the same
The comment I was replying too was OT.
> To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
Do you Yahoo!?
Declare Yourself - Register online to vote today!