Last Updated on January 19, 2024 by theadmin

HTTP – IP Authenticated Proxies

This is the first part in a series of articles explaining how proxies authenticate users.  It will include the correspondence between server and client including status codes, request headers and response headers which are used to illustrate the proxy authentication process.

This site is primarily concerned with the ability to hide and control your IP address so we can protect our privacy and operate effectively online.  Having one single, ISP assigned IP address is extremely restrictive for even normal web browsing but makes running an online business or even surfing internationally very difficult.  One of the key tools we have for both maintaining our online privacy and freedom are of course proxies.    We can use proxies for all sorts of purposes but primarily to maintain different identities using residential addresses, routed through mobile proxy gateways or simple private proxies designed for speed and security.

However if these proxies have to remain secure and useful, there obviously needs to be some restrictions on who can use them.  After all you don’t want to share your super fast private proxy network with a load of freeloaders who route their traffic through them for free.  So an important aspect of using any paid proxy service is the ability to authenticate you account.  It’s especially important when you’re using these servers alongside automated tools and bots like Jarvee or any other promotional too.  The software needs the facility to authenticate against the proxy server too, ideally automatically unless you relish the idea of typing in passwords every few minutes.

HTTP Authentication

The basic authentication systems incorporated into HTTP include two distinct mechanisms.   One is used to authenticate a user to their final destination, the origin server.  The second is used to authenticate the user to an intermediate server like a proxy, which is not the end destination.   Both of these authentication mechanisms operate in a similar way – both require a request header, a response status code and finally a response header.  However all these codes and header statuses will be different depending upon the type of authentication which is taking place.     What’s more these authentication requests could be operating at the same time between both origin and intermediate servers.

Both of these authentication methods form the basis of the HTTP framework for authentication.  However it is important to remember that this is just the basic capacity for authentication, there’s nothing to stop additional, more sophisticated authentication methods being placed on top of this framework.     The specification of HTTP Authentication also includes two important definitions of ‘Basic’ and ‘Digest’ Authentication which will be explained in a later article.   You should be aware of both of these especially if you’re investing in expensive proxy accounts supplying residential IP addresses.

Standard Server Authentication

The basic authentication process follows these steps:

• Original server receives a request without any proper authentication details in the Authorization: header.  It would respond with a a status message – 401 (authentication required) and a WWW-Authenticate header to the client, within this would be details about how the authentication could be performed.
• The client would receive the 401 status code and check the WWW-Authenticate header which would prompt for example for a username and password from the user.
• Client would the resend the request and including a proper Authorization: header which should include the required credentials for authentication.

Proxy Server Authentication 

Authentication for a proxy server follows basically the same framework however it uses different status codes and headers.

The proxy authentication follows these steps:

• Proxy server will receive a request but missing the required proxy authentication credentials in the Proxy-Authorization: header field.  In response to this  it will issue a 407 status code which means Proxy authentication required.  In addition to this their will be a response header Proxy-Authenticate: which will specify details on how the proxy authentication should be performed.
• Client will receive the 407 code and check the Proxy-Authenticate: header and prompt the user for a username and password.
• Client would then resend the request to the proxy server although this time including the Proxy-Authenticate: header which contains the required credentials.

Basic HTTP Authentication

As you can see the ‘Basic’ authentication scheme is very straight forward and it’s actually the only scheme defined directly by HTTP specification.  It also is inherently insecure ad there is no encryption involved and the only security applied to the username and password is pass it in a printable encoded format.  This is obscured but so easily deciphered that it is effectively sent in the clear.  When Basic authentication is used, the server will repond with a 401 status code where it is specified by using the WWW-Authenticate: header.  Here the scheme would state @Basic’ and a string displayed informing the user of the ‘realm’ which is actually an indication of who is asking for the authentication credentials.

Example:

• HTTP/1.0 401 Unauthorized
• Server:  IIS Server/2.0
• Date: Sun, 24th June 2013 09:20:23 GMT
• WWW-Authenticate: Basic realm=”Active Directory Root Domain”

Form this point the client will attempt to get the credentials by prompting the user for a username and password.  It will generally use base-64 printable encoding, a basic security measure designed more to obscure that really protect the credentials.   The format is  as follows  – username:password but encoded.

IP Authenticated Proxies

The encoded string will actually be specified in the Authorization: header field along with the specification of the authentication scheme used – i.e. ‘Basic’.  The request will then be reissued to the server, however this time it will also include the authentication details supplied by the user.

• GET /root/payment.html HTTP/1.0
• User Agent: Mozilla/5.0
• Accept: text/html, image/jpeg, image/gif
• Authorization: Basic VGGFDFDFDFDGF+=

When considering these authentication exchanges remember that the authentication doesn’t simply happen in the first exchange and then is remembered by the server.   This does not happen, instead the client software will ‘cache’ the username and password and include the Authorization: header on subsequent requests in that session.   This is important as there is no pass through or facility for the server to cache the credentials – authentication takes place in every request with the server.