[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: man-in-the-middle



--- Bob Snyder <rsnyder@toontown.erial.nj.us> 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
> NFS
> > 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
> if
> > it even could?  If there's a patch or hack, I don't think debian will
> be
> > 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
> subnet?
> 
The comment I was replying too was OT.

> Bob
> 
> 
> -- 
> To UNSUBSCRIBE, email to debian-firewall-REQUEST@lists.debian.org
> with a subject of "unsubscribe". Trouble? Contact
> listmaster@lists.debian.org
> 
> 



		
_______________________________
Do you Yahoo!?
Declare Yourself - Register online to vote today!
http://vote.yahoo.com



Reply to: