Re: man-in-the-middle
On Thu, Oct 07, 2004 at 06:25:59AM -0700, Mike Mestnik wrote:
> > 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.
Right, it wasn't my intention to say it would. The URL given was an example
of port specification, not of an example of how this would work.
If you want an example of how it would work,
-------- ------------- ---------------
|client|------------|squid proxy|----------------|remote.server|
-------- ------------- ---------------
Assume client has no direct network connectivity to remote server.
Client wants to establish a ssh connection to remote server.
Client would open a TCP connection to port 3128 on the squid proxy,
where the proxy is listening.
Client would send "CONNECT remote.server:22 HTTP/1.0" and perhaps a few
other HTTP headers if authentication to the proxy is needed.
squid proxy would connect to remote.server on TCP port 22.
squid proxy would return a 2xx code to client, and begin tranferring
bytes back and forth, relaying traffic as if the client had actually
connected to port 22 on remote.server.
Of course, many proxies will restrict CONNECT to ports other than 443.
> > 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. :)
True. But you can specify what port, point it to localhost and a port
you've set up a wrapper on, and it should work to some degree. I haven't
tried it, and lockd and friends would probably be an issue.
None of this should be taken to say doing this is a good idea. It may
be possible, though. :-)
Bob
Reply to: