Re: Destination server/port to tunnel www?

From: Richard E. Silverman (res_at_qoxp.net)
Date: 05/28/04 

Date: 28 May 2004 12:13:04 -0400

>>>>> "TN" == Toby Newman <google@asktoby.com> writes:

>>> What should I use as a destination IP/port for HTTP?
>> Your HTTP proxy server.

    TN> I'm not aware that I use a proxy server.

Darren's point is that now you need to, if you want to tunnel your HTTP
requests. A static SSH forwarding has a single target socket. You are
making HTTP requests to various hosts as you browse the web, so a single
static forwarding will not allow you to talk to more than one web server.
Even that may not work properly, as you will have to change the hostname
in your url's to reach the forwarded port
(e.g. http://localhost:port/...), which will often not be accepted by the
web server in question. Even if you were just forwarding directly to a
single web server to browse its content, you would set the SSH-forwarded
socket to be your browser's HTTP proxy -- it would just only work for
url's hosted by that server. To browse the web in general, you'll need to
forward to a real HTTP proxy server, e.g. squid.

In theory, a better way to deal with this is Darren's other suggestion:
so-called "dynamic forwarding" via SOCKS (OpenSSH -D forwarding): this
allows the browser to make TCP connections to multiple arbitrary
destinations through a single SSH-forwarded socket, and removes the need
for an HTTP proxy server, having to proxy each protocol separately
(HTTP/HTTPS/...), etc. However there are sometimes practical problems
with this. If there are split namespaces (DNS etc.) on either side of the
SSH connection, then you want to use socks5 and have the client pass the
names through for resolution on the far side. Unfortunately, many
browsers do local name resolution anyway even when set to use a socks5
proxy, limiting the usefulness of this feature. Even if the namespace is
not split and this works, part of the point of the whole setup may be
lost. If you wanted browsing privacy in the vicinity of the client, then
this is partially compromised: the DNS traffic from the client reveals the
web servers it's talking to, even though the actual HTTP traffic is
protected by SSH. 

-- 
  Richard Silverman
  res@qoxp.net