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

["MATHIHALLI,MADHUSUDAN (HP-Cupertino,ex1)" <ma...@hp.com>]

Cool..

Can you please post the patch to the list, so that ppl can review the code,
and give their comments.

-Madhu

>-----Original Message-----
>From: Maik Mueller [mailto:maiklst@hw1464.wdf.sap-ag.de]
>Sent: Tuesday, February 11, 2003 11:26 AM
>To: dev@httpd.apache.org; modssl-users@modssl.org
>Cc: maik@sap.com
>Subject: 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
>