You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Maik Mueller <ma...@hw1464.wdf.sap-ag.de> on 2003/02/11 20:25:47 UTC

Patches and Enhancements for a SSL-Proxy Based on Apache 2.0 (mod_ssl, mod_proxy, mod_headers)

Hello All,

I want to provide updated information to my earlier described scenario using
mod_ssl + mod_proxy + mod_headers:
Component:	Web Browser --- Proxy (mod_proxy)       --- Web Server
SSL Role:	SSL Client  --- SSL server | SSL Client --- SSL Server

The following discussion focuses on Apache 2.0.43 and 2.0.44.

I have implemented a solution to transfer the Web browser's client
certificate (and other SSL information) to the backend Web server:
Component:	Web Browser --- Proxy (mod_proxy)       --- Web Server
SSL Role:	SSL Client  --- SSL server | SSL Client --- SSL Server
				Client Cert (and other SSL information) --> Transfer as HTTP Headers

The problem was that mod_headers' RequestHeader directive didn't really
matched the requirements.
RequestHeader set SSL_CLIENT_CERT %{SSL_CLIENT_CERT}e is not a practical
solution to
forward the client's certificate to the backend server for the
following reasons:
1. SSL_CLIENT_CERT produces multi-line output and the RequestHeader
directive isn't able to transfer it into a correct multi-line HTTP header.
2. The "decorations" (-----BEGIN/END CERTIFICATE-----) and the multi-line
format are not very useful in this scenario.

Therefore I have introduced the option "E" in addition to "e" for putting
environment variables in headers. The "E" has the following meaning:

%{FOOBAR}E	The base64 encoded content of the environment variable FOOBAR.
If the environment variable already contains a base64 encoded body (e. g.
SSL_CLIENT_CERT) the body will be set as the value of the header variable.

The result is in any case a single line of base64 characters only.

This behavior serves two requirements:
1. There is no problem escaping special characters when putting other SSL
information in HTTP headers. In many cases, SSL_CLIENT_S_DN will probably
contain characters that have to be escaped.
2. Reduces the overhead produced by "decorations" and multi-line format.

Here is an example for forwarding the SSL Client Certificate and other SSL
information:
    RequestHeader set SSL_CLIENT_CERT         %{SSL_CLIENT_CERT}E
env=SSL_CLIENT_S_DN
    RequestHeader set SSL_CLIENT_CERT_CHAIN_0 %{SSL_CLIENT_CERT_CHAIN_0}E
env=SSL_CLIENT_CERT_CHAIN_0
    RequestHeader set SSL_CLIENT_CERT_CHAIN_1 %{SSL_CLIENT_CERT_CHAIN_1}E
env=SSL_CLIENT_CERT_CHAIN_1
    RequestHeader set SSL_CIPHER_USEKEYSIZE   %{SSL_CIPHER_USEKEYSIZE}e
env=SSL_CIPHER_USEKEYSIZE
    RequestHeader set SSL_CIPHER_SUITE        %{SSL_CIPHER}e
env=SSL_CIPHER

To make this work I also patched two other things:
1. mod_headers' RequestHeader directive wasn't able to take an env clause as
a forth argument in contrast to the Header directive. I don't know the
reason
for that behavior, but env clause seams to work fine with the SSL
environment
variables for RequestHeaders. This was necessary to avoid an empty header if
the environment variable isn't present.
If there are objections, let me know.
2. SSL_CLIENT_CERT_CHAIN_n is broken. To me it seems that somebody has tried
to change SSL_CLIENT_CERT_CHAINn to SSL_CLIENT_CERT_CHAIN_n. However, the
introduction of the "_" wasn't quite consistent. I patched that and now I
can see the intermediate CAs as SSL_CLIENT_CERT_CHAIN_0 to
SSL_CLIENT_CERT_CHAIN_n in the environment.

Last but not least I have updated the mod_headers documentation with the new
option "E" and an example for forwarding the Web browser's client
certificate and some other SSL information.

I think the described patches and enhancements are quite reasonable and I
would like to make them part of the standard Apache distribution. I have
already produced a patch file that works for Apache 2.0.43 and 2.0.44. I
would appreciate guidance on how to proceed.

Comments welcome!

Regards,
	Maik

Maik Mueller
Development Architect
SAP