[noCensorship] Re: [Proxy Elites] Proxies, ports and stuff.....
- From: wayne <wayne@xxxxxxxxxxxxx>
- To: nocensorship@xxxxxxxxxxxxx
- Date: 15 Oct 2002 21:15:25 -0000
> From: Michael Foord <Michael.Foord@xxxxxxxxxxxxxxxxxx>
> To: milhaus@xxxxxxxxxxxx, nocensorship@xxxxxxxxxxxxx
Not CCing Milhaus. He may not want this unsolicited email...
> Subject: [noCensorship] Re: [Proxy Elites] Proxies, ports and stuff.....
>
> Hello milhaus this is an email you did me a *long* time ago which I was too
> much of a novice to really understand.
>
> I`m still quite a novice but have got to the point where I need to know more
> !!
>
> Are you able to answer my questions on this subject or am I better off
> directing my queries elsewhere ?, sorry for not replying to this earlier (I
> must have seemed very ignorant) but I don`t think I properly realised you
> were trying to help - I was quite lost in the subject. There is still a lot I
> don`t understand - like why for example I can`t connect from port 25 on my
> system (which happens to be open - and I know is
> normally reserved for email use) to port 80 on another system.
It's packets *destined* for port 25 on the remote system that are
being allowed out, not packets *from* port 25 on your system.
> It seems a bizarre convention, especially considering that all the `port
> number` can really be is just a number in a header somewhere
More than that; it's the port the remote service has a listening
socket waiting for connections on. SMTP servers listen on 25, POP3
listens on 110, etc...
This is done like this so that a single remote host may listen on
many different ports, offering different services on each one.
> .... hmmmm..... only packets with a number 25 (for example) get out of my
> system - only packets with a number 80 in them get listened to at the site I
> am trying to conenct to - odd and unfortunate.
Not unfortunate, it's as designed.
> However, I suppose if it didn`t work like this the techniques used to block
> would just be
> different and one convention is only as arbitrary as another....
The whole internet works like this, the blocking came along later
and needed to block in this way (and others).
> milhaus van heuten wrote:
>
> > Hi Michael
> >
> > I would highly recommend using httptunnel or something simpler than
> > sockscap and socks2http. If it is
>
> Did get httptunnel working briefly once. Trouble was the proxies I had
> (needing to be maually entered) were very slow and localproxy seemed to do
> the job so much better for http access. At the moment the range of IPs I can
> access is very limited so the chances of finding a CONNECT proxy I can get to
> is pretty small unfortunately. If I find one I might try all this as I really
> want to get news services and filesharing
> working.
Last time we checked, your own proxy was allowing CONNECT.
If you get LP working again, but your manual choice of proxies
doesn't, post some LP logs, or look at the speeds from the GUI,
and select the ones LP is using, to use in things like HTTPort.
It will work for a while, then you will need to get LP to select
for you again :-)
> > possible for you to use external HTTP CONNECT proxies, you can do away with
> > the socks solution altogether, and create a tunnel on your own machine
> > (port 119) to the external news server, via the proxy.
This is confusing.
The tunnel will be from your machine (any port) to the remote news
server (port 119). Your end of the tunnel will listen on a specified
localhost port (which *may* be 119), and your news client needs to
be set up to think there's a news server on localhost on that port.
The advantage of making your end of the tunnel listen on port 119
is that some news clients don't allow the news server port to be
changed (and like OE, sometimes it's hard to find where to change
this).
> All that would be needed to get to the external news service, is to point
> your newsreader at 127.0.0.1 (localhost)
> >
> > This may be confusing if you do not understand ports/tunnels/etc :)
> >
>
> Its the `create a tunnel on your own machine`
Here's exactly how it's done (by LP, HTTPort etc.) (simplified):
0) open listening socket on localhost:119 (say)
1) tcp/ip connect to your proxy 192.168.4.1:8080
2) send command 'CONNECT news.panix.com:119'; proxy obliges
3) news client connects (tcp/ip) to localhost:119 and sends news
server commands.
4) LP (or whatever) hears the connection from the news client,
and reads the commands
5) LP (or whatever) sends those commands out on it's connection to
your proxy which sends them on to it's connection to the news server.
6) news server acts on the commands and sends back news
It works because
0) your proxy is CONNECT capable (will allow this tunnel to be set
up) to remote port 119
1) at no stage do you make any attempt to send packets out through
your firewall (they all go through the proxy).
> that is gobbledygook to me - but I have never checked the httptunnel docs to
> see if I could manage it - as I said at the moment its possibly not worth it
> but is something I would very much like to do in general as this could solve
> my problems.
Httptunnel, last time I looked, was only capable of 'encoding' the
connection from you to a news server inside of normal HTTP (web
type) communications. Your proxy would allow it out, but something
remote must be there to decode it. You needed to use a free decoder
(httptunnel includes this function) running as a decoder, or set
up your own on a host outside.
> Hmmm.... I also want to tunnel udp access - will httptunnel convert that via
> a CONNECT proxy as well... if so it would do for
> filesharing as well which localproxy is not yet capable of.
My info is out of date, but I recall that was not there.
Theoretically possible, but you would still have the problems we
discussed before for p2p stuff (addresses being negotiated inside
of the data stream).
> So if I have a CONNECT proxy I can connect to that from
Not *from*, you mean *to*.
> one of my few open ports (so long as I can find a CONNECT capable proxy that
> works on that port) and use that to point anywhere else on any port - right
> ???
Yes, they often are not CONNECT capable to some ports though;
25 and 110 seem to be being removed from the list these days
(because spammers use them).
> > Each machine using TCP/IP on the internet has 65536 ports (numbers
> > 1 to 65535 I think). Most of the port numbers below 1024 are 'assigned' -
> > meaning, they have an agreed purpose. Port 80 is the standard port for HTTP
> > traffic.
> > A service can listen on a port for incoming connections. If someone
> > attempts to connect to a port on your machine, and there is no service
> > 'listening' on that port, your machine will refuse the connection. If you
> > are running an FTP server on your machine, it will probably be listening
> > for incoming connections on port 21.
> >
> > Every time you browse a web page on the internet, you are actually making a
> > connection to port 80 of the web server in the URL.
Or using a proxy, which makes that connection for you.
*You* connect to ther proxy first, on whatever poort it is
listening on.
> Yet I have to go via my Superscout censoring proxy server. So make a
> connection with that on port 8080 - it then makes the connection to port 80
> on the outside and pipes the result for me (including authentication issues
> and censoring in the mix) ??
Yep. You can't make that port 80 connection directly because your
firewall blocks any outgoing connections destined for that port
(except the ones from your proxy).
> > When you try to make a TCP connection to another machine, you specify an
> > address and a port. Your machine sends a request to the target, requesting
> > a connection on that port. If there is a service listening, it will pick up
> > the connection, and send a TCP handshake. A connection is established and
> > data can flow back and forth in both directions.
> >
>
> Right - (sorry to labour the issue) so a machine will only ever connect from
> port 80 to port 80 or port 1080 to port 1080 etc ??
No. From *any* port on your machine to the listening port on the
remote machine. Your originating port is usually chosen sequentially,
starting around 1025 on Windows machines, but that's unimportant
from your point of view. Firewalls are capable of blocking on this
too though, but the dest port usually indicates the protocol in
use more directly.
> This matters because most of my ports are blocked, 8080 is proxied (to port
> 80 on the outside ??)
To whatever port you tell the proxy to make the request to.
Your browser may send a request to http://somehost.com:1111/ if
it needs to; the proxy then connects to somehost.com which should
be listening on 1111.
> and a couple are open (probably by mistake).
Not likely - someone there doesn't know how to proxy email :-)
Or they don't want to pay for an email server on the firewall.
> So if I want to use a proxy I have to find one that will listen on either
> the open ports
Yes.
> or one I can get through to on port 80 that isn`t censored (which is a *very*
> restricted range of IPs - although I can `social engineer additions!!).
StatProxy showed that you can't get through to anywhere on port 80.
All you can do is make the proxy get through to somewhere:80 for
you, and then you need to be able to live with the proxy's
interference with your comms. Either by making a tunnel first, or
by encoding in some way. BTW, LP's commStrat 2 is just encoding too,
but in a way that the remote web servers can decode for themselves;
you don't need an extra decoder out there.
> > A HTTP connection is very simple. Your PC connects to the remote server on
> > port 80, and sends the following (example):
> >
> > GET /index.html HTTP/1.0 (followed by two carriage returns)
> >
> > The remote HTTP server understands that command and looks in its /
> > directory for the index.html file. If it finds it, it sends back to your
> > browser:
> >
> > HTTP/1.1 200 OK
> >
> > <contents of index.html file>
> >
> > Your browser, being a HTTP client, knows what to do with this information
> > and displays the file appropriately. The connection is then closed, and
> > this process is repeated for any other pages you browse on the website.
> >
> > FTP traffic looks very similar, with simple commands in plain english such
> > as GET file, PUT file, CHDIR, MKDIR, QUIT, LIST, DELETE, etc.
> >
> > Proxies are similar to HTTP servers except, instead of serving up local
> > files, they allow you to GET other websites. ELITE proxies have a command
> > called CONNECT that makes a full connection to a secondary IP and port.
> >
> > You can play with all of this stuff by using TELNET. Simply telnet to a
> > webserver or FTP server and start issuing some of the commands in this
> > email. Don't worry, you won't hurt it ;)
> >
> > try :
> >
> > Telnet www.blah.com 80
> >
> > when it connects, type:
> >
> > GET / HTTP/1.0 (followed by ENTER twice)
> >
>
> Can`t do that because the telnet program doesn`t cope with authentication -
> so *ALWAYS* fails.
True - usually.
Did we try authenticating with the browser and then running
this stuff (or statProxy, for example)? That often works with these
cheap firewalls.
> > This is basically what your browser is doing in the background.
> >
> > I cut and paste some of this from a website so sorry if it's a bit long ;)
> >
>
> Hmmm cool - I don`t suppose you remember which website ?
The RFCs (a link you have, IIRC) are the ultimate reference for all
of the protocols; a bit hard to read though :-)
RFC1180 is a damn good tcp/ip tutorial, 1945 is on HTTP 1.0, etc.
Google will find them for you.
> > cheers
> >
> > .milhaus.
>
> Many Thanks
>
> Michael
--
wayne@xxxxxxxxxxxxx
http://proxytools.sourceforge.net/
===8<============== noCensorship community ===============
List's webpage: //www.freelists.org/webpage/nocensorship
List's archive: //www.freelists.org/archives/nocensorship
To unsubscribe: nocensorship-request@xxxxxxxxxxxxx with 'unsubscribe' in the
Subject field.
Moderator's email: nocensorship-moderators@xxxxxxxxxxxxx
===8<============== noCensorship community ===============
Other related posts:
