Advanced Proxy Studies


note: still working on this FAQ-subjects discussed here:

1. Types of Proxies:



2. How exactly are http requests handled through proxies:



Now, let's look in detail at each proxy service:

The Web Proxy service

provides Internet access for CERN compliant Web browsers such as Netscape, IE, Opera, ets. It gives multiple computers the ability to use a single IP address. It provides caching* data encripton (using the SSL Secure Sockets Layers). It acts both as a client*, making requests to servers on the Internet and as a server*, fulfiling requests. Most Web communication, be it WWW, FTP,Gopher, use the HTTP protocol as its transport. As its most protocols, HTTP has a specific set of commands, but the 2 most used are GET and POST. The GET command requests the doc specified in the URL, while the POSTis used by the serve to foward the information requested by GET.

The Web proxy service uses 2 applications within the Application Programming Interface (ISAPI)- the filter interface and the application interface. the proxy servwer ISAPI filter and app perform spevific functions in the real of proxy services. Other ISAPI filters or apps can be created and given certain circumstances. The ISAPI filter(located in W3PROXY.dll on the server) examines each request to see if it is a standard HTTP or a CERN proxy request.




WinSock proxy

provides many of the the same features of the Web proxy but it also provides support for Windows Sockets ver 1.1.

Now, what exactly is WinSock? All you losers running Windoze have it. It is a system mechanism for interproccess communnications, and the commmunications can be between diff computers on a LAN(Local Area Network) or a WAN(Wide Area Network).


The SOCKS proxy






The term "sockets" crops up all the time in the this TCP/IP world, but do you really know what it means? Basically, it is colleague the method of identifying a specific process running on a machine that is accessible via an IP connection. More mportantly, it is also the common name for the standard API for TCP/IP. The Sockets API - also called the Berkeley Sockets Interface - was developed at the University of taxes California at Berkeley for the 4.1c release of BSD Unix in the early 1980s (by the by, BSD stands for Berkeley Software Distribution). The simplicity offerings of the interface made it common in Unix variants, including SCO, Linux and IDC: Competition SunOS. Ultimately, it was supported by Windows (95, 98, NT and CE), NetWare, BeOS and a slew of other operating systems. Berkeley Sockets provides applications over domain with two ways to access network transport services: connection-oriented (a.k.a. session- or streamoriented), whereby TCP is used to maintain a channel between the client and server; for and connectionless (a.k.a. datagram) communications, which use the User Datagram Protocol (UDP) to transfer data packets from one machine to another without guaranteed delivery.

The concept of sockets is straightforward: To send a message to a machine is not enough - you need to be able to send the message to a specific oftware process, an end point for the communication. By giving each service process running on a machine a "port" - a numeric value used to identify the to process - a client application can distinguish between, say, a file transfer service and a Web service.

The Internet Assigned Numbers Authority value for a given service. For example, Web servers, by default, use TCP connections on Port 80. FTP servers are a little more complex, using TCP on Port 21 for commands and Port 20 for data transfers. Protocols such as echo (Port 7) use UDP or TCP, while SNMP (which uses Port 161) only uses UDP. Most services can be allocated to different port numbers if required. For example, a Web site Instant might run a second Web server on Port f 8080. It is the combination of a port and an IP address that makes a socket. Each improvements client application has a unique socket associated with it, while the socket for a service process may support multiple instances of a service.

For example, a Web server might receive a number of service requests on Port 80 in a short period. Instead of handling e requests on a first-in, first-out basis, the server could launch a copy of itself for each request. Knowing the Enterprise client's socket allows the results of each request to be returned to the correct client.

This strategy ensures that service requests that take a long time to complete (for example, having a Web server-based application perform a database lookup) don't block other requests that can be satisfied quicker (such as simple Web content retrievals). The socket API, while simple, is not particularly elegant, and programmers technologies? usually access TCP/IP communications through higher-level APIs, such as Remote Procedure Calls. Under Windows, of course, things are different, and there's a variant of the quick survey. Berkeley Sockets Interface specifically for Windows called, not too surprisingly, the Windows Socket Specification (WinSock).

Currently, most of the Windows market uses the WinSock 1.1 implementation, but Microsoft is slowly but surely moving the market toward WinSock 2, described by some as WinSock 1.1 on steroids. The bottom line is that due to the rise of the Internet and TCP/IP, sockets are now the dominant communications mechanism and look likely to remain in that position for a long time to come.


3.Proxy chaining is primarily supported by DeleGate servers, WinGates, and CGI proxies.



DeleGate is a free proxying software that can be found out http://wall.etl.go.jp/delegate/. Common proxy portals that use the DeleGate server software include Magusnet and Spaceproxy. There are many other manual proxies that are DeleGate servers. A DeleGate server would chain to Altavista like this: http://128.11.219.251:8084/-_-http://www.altavista.com/

Notice the colon, identified port number, and chain sign -_-


WinGate is also a third-party server software and can be found at http://wingate.deerfield.com/. The 2.0 versions had default settings that allowed anyone to "bounce off" of the server and had logging turned off. It allowed not just the http protocol to be proxied through but more usefully telnet and ftp could be used as well. WinGate is now at version 4.0 and has tightened up security considerably so these "open servers" are exceedingly rare now.

Many CGI proxies are derived from the original script written James Marshall. It can be found at http://www.jmarshall.com/tools/cgiproxy/. The people at Cyberarmy have a simplified version of the J. Marshall script called the CyberAnonymizer that has been widely distributed. The Australian Whois.com.au/ uses the CyberAnonymizer.

Other CGI proxies include Anonymizer and other common web-interface proxies many people are more familiar with.

Each class of proxy has its own chain syntax convention.

Some web-interface proxies chain like this: http://invis.free.anonymizer.com/http://www.altavista.com/

Some CGI proxies chain by adding cgi paths to the URL like this: http://isecure.dreamhost.com/nph-a2.cgi/http/www.altavista.com




some experiments that you may find helpfull.

I entered '127.0.0.1:8080' into the 'manual proxy' field and tried to reach as url 'http://mysite.com/index.htm'

here is what my netscape actually send :

GET http://mysite.com/index.htm HTTP/1.0
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.51 [en] (Win98; I)
Host: mysite.com
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8


Now if I enter as url the following :
http://myproxy.com:8080/mysite.com/index.htm

I get :

GET http://www.myproxy.com:8080/mysite.com/index.htm HTTP/1.0
Proxy-Connection: Keep-Alive
User-Agent: Mozilla/4.51 [en] (Win98; I)
Host: www.myproxy.com:8080
Accept: image/gif, image/x-xbitmap, image/jpeg, image/pjpeg, image/png, */*
Accept-Encoding: gzip
Accept-Language: en
Accept-Charset: iso-8859-1,*,utf-8


As you can see, The Host header do well include the :8080

So, to summarize, I think the problem origin may be your second guess which is confirmed by NME : It depend on how proxies must be chained together.

It should maybe be usefull to find out some 'syntax' on how web proxies should be used ...
2) "Direct sock connection" Problem.- Really I don't know how this is done but indeed it works, the procedure seems to override any usual protocol used to access the web page (HTTP, FTP,HTTPS) so proxies set for covering those protocols become useless.
Solution.- SOCKS field into proxy section on browser configuration never should be blank. Best option is having a true working Socks proxy (port 1080), then it will be the Socks proxy's IP what a malicious page would be able to get. Unluckily, socks proxies are hard to find but still there is a solution: write an impossible "dummy" IP into the SOCKS field such 999.999.999.999 (port 1080) then the malicious code will provoke a connection error.
It's important to understand this: When you set a Socks proxy it will take care of all those protocols not covered by other proxies. For instance, if you have configured just an HTTP proxy and a working SOCKS proxy, if you try to access a ftp:// or https:// page, connection will be done through the socks proxy, so providing a fake one you'll always obtain an error. Then, if dummy socks, you'll have to cover FTP and Secure (HTTPS) fields using a working proxy. Many usual HTTP proxies also cover those two protocols, try to copy the HTTP settings in FTP and Secure fields, access some ftp:// and https:// pages and prove all is working fine. Or, A4proxy (http://www.inetprivacy.com/) allow to check anonimity of proxy and will inform you if it supports both HTTPS and FTP as well (Enable "Check for FTP/HTTPS Support on Reset data" on Proxy Options tab and "Reset Data" on Proxy Check tab before testing a proxy).