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:[EMAIL PROTECTED]] >Sent: Tuesday, February 11, 2003 11:26 AM >To: [EMAIL PROTECTED]; [EMAIL PROTECTED] >Cc: [EMAIL PROTECTED] >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 >
