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.