Certificate Based Client Authentication

One of the most important features of SSL is it’s ability to authenticate based on SSL certificates.  Often people fail to understand that this certificate based authentication can only be used when SSL is functioning, it is not accessible in other situations.    Take for example the more common example on the web of insecure HTTP exchanges – this means that SSL certificate based authentication is not available.  The only option here is to control access by using basic username password authentication.  This represents possibly the biggest security issue on the internet today because this also takes place in clear text too!

Another common misconception is with regards the SSL sessions themselves.  SSL sessions are established between two endpoints.  The session may go through a SSL tunnel which is effectively a forward proxy server.    However secure reverse proxying is not SSL tunnelling it’s probably better described as HTTPS proxying although this is not a commonly used term.   In this example the proxy acts as an endpoint of one SSL session, accepting the endpoint of one SSL session and forwarding the request to the origin server.

The two sessions are distinct except of course they will both be present in the cache and memory of the proxy server. An important consequence of this is that the client certificate based authentication credential are not relayed to the origin server.   The SSL session between the client and the reverse proxy server authenticates the client to the proxy server.  However the SSL session between the origin server and the proxy authenticates the server itself.   The certificate presented to the origin server is the reverse proxy’s certificate and the origin server has no knowledge of the client and it’s certificate.

Just to summarise this is the ability to authenticate the client to the origin server though the reverse proxy server.

In these situations where client based certificate based authentication and access control are required, the role would have to be performed by the reverse proxy serve.  In other words the access control function has been delegated to the proxy server.  Currently there is no protocol available for for transferring access control data from the origin server to the reverse proxy server.    However there are situations in advanced networks where the access control lists can be stored in an LDAP server for example in Windows Active directory domains.   This enables all unverified connections to be controlled, e’g blocking BBC VPN connections from  including outbound client requests to the media servers.

The reverse proxy could be described in this situation as operating as a web server.  Indeed the authentication required by the reverse proxy is actually web server authentication not proxy server authentication.    Thus crucially the challenge status code is HTTP 401 and not 407.  This is a crucial difference and a simple way to identify the exact authentication methods which are taking place on a network if you’re troubleshooting.


Uses of Reverse Proxy Servers

There are actually quite a lot of reverse proxy servers in use through large corporate networks performing a variety of purposes.     However there are two distinct roles for which they are commonly used –

  • replicating Content to geographically dispersed areas
  • replicating content for load balancing

It’s a function that is not always considered for proxies, however content distribution is a logical function for any proxy server.  In fact a reverse proxy server can even be used to establish multiple replica servers of a single master to diverse locations.  Take for example if you have a multinational company with offices in countries all over the world.

It would be difficult for a single server with company wide data like templates, policies and procedures to server the entire company yet it is imperative that the integrity of any ‘copy’ is maintained.  The reverse proxies could be set up in each branch server with a slightly different address, perhaps including location in name.   These reverse proxies would pull their data from the master ensuring they were all identical.

This is quite an efficient use of the proxy in reducing bandwidth requirements across the network.  However the reverse proxies must be configured to pull changes from the master very frequently in order to ensure any changes are replicated quickly.  In fact it would be usually safer for the master server to push changes to the reverse proxies in order to ensure this.

The configuration can be complete by updating specific DNS entries in each zone.  This would mean that you could resolve – www.master.com from all of the physical locations.   That is to resolve london.master.com to point at the master server instead.

As mentioned the main issue is ensuring that changes are replicated efficiently and accurately.  In fact replication is perhaps a little too advanced a term as really the proxies are merely caching information and updating them.  So the master server has some modification to it’s content then it would push out the changes to any of the proxies online.  So messages would be sent to the uk online proxy here, then to the asian proxy and so on.

THe other main use is of course load balancing for something like a heavily loaded web server.  Any request received from a client will be distributed back to the multiple reverse proxies by using methods like DNS round robin.  This ensure that the requests are spread out evenly and one of the reverse proxies doesn’t become overloaded with requests too.  This often happened if static lists were used in rotation as the same proxy servers would be receiving the requests too frequently.

John Severn often sneaks off work to travel somewhere hot.  After all he just needs to change ip address to United Kingdom and no-one will notice his emails are coming from the Costa del Sol next to a pool.