Re: SSL_CLIENT_CERT header bad format
On Wed, Mar 22, 2006 at 08:28:35AM +0100, Marc Stern wrote:
It seems that the PEM-encoded certificate coming out of OpenSSL (0.9.8a in
my case) contains new lines without leading space, which is interpreted as a
new HTTP header.
In what configuration does this happen? If you are using
%{SSL_CLIENT_CERT}s with mod_headers then it should be OK; mod_headers
will already convert CR/LF in SSL variables to spaces.
joe
Re: SSL_CLIENT_CERT header bad format
I use %{SSL_CLIENT_CERT}e with 2.0.54 (patched to get mod_ssl headers).
Is this the problem ? Was it fixed after 2.0.54 ?
- Original Message -
From: Joe Orton [EMAIL PROTECTED]
To: Marc Stern [EMAIL PROTECTED]
Cc: Apache development list dev@httpd.apache.org
Sent: Wednesday, March 22, 2006 9:57 AM
Subject: Re: SSL_CLIENT_CERT header bad format
On Wed, Mar 22, 2006 at 08:28:35AM +0100, Marc Stern wrote:
It seems that the PEM-encoded certificate coming out of OpenSSL (0.9.8a
in
my case) contains new lines without leading space, which is interpreted
as a
new HTTP header.
In what configuration does this happen? If you are using
%{SSL_CLIENT_CERT}s with mod_headers then it should be OK; mod_headers
will already convert CR/LF in SSL variables to spaces.
joe
Re: SSL_CLIENT_CERT header bad format
On Wed, Mar 22, 2006 at 11:44:08AM +0100, Marc Stern wrote:
I use %{SSL_CLIENT_CERT}e with 2.0.54 (patched to get mod_ssl headers).
Is this the problem ? Was it fixed after 2.0.54 ?
Yes, 2.2.0 has the %{...}s support which does this properly. There's a
backport for 2.0 here:
http://people.apache.org/~jorton/mod_headers-2.0-ssl.diff
but it might be stale w.r.t. the latest 2.0.x releases.
joe
Re: SSL_CLIENT_CERT header bad format
Maybe a stupid question, but the function name apr_pstrdup() lets me think
we duplicate a string.
If so, don't we introduce a memory leak ? Is there any automated cleaning
afterward ?
Can't we modify the 'hdr' variable immediately ?
Also, a little performance concern: is the first if(...) really useful ?
Doesn't it take more time to check in the whole string if there's a CR, then
a LF than simply trying to replace them ?
+static const char *unwrap_header(apr_pool_t *p, const char *hdr)
+{
+if (ap_strchr_c(hdr, APR_ASCII_LF) || ap_strchr_c(hdr, APR_ASCII_CR)) {
+char *ptr;
+
+hdr = ptr = apr_pstrdup(p, hdr);
+
+do {
+if (*ptr == APR_ASCII_LF || *ptr == APR_ASCII_CR)
+*ptr = APR_ASCII_BLANK;
+} while (*ptr++);
+}
+return hdr;
+}
- Original Message -
From: Joe Orton [EMAIL PROTECTED]
To: Marc Stern [EMAIL PROTECTED]
Cc: Apache development list dev@httpd.apache.org
Sent: Wednesday, March 22, 2006 2:21 PM
Subject: Re: SSL_CLIENT_CERT header bad format
On Wed, Mar 22, 2006 at 11:44:08AM +0100, Marc Stern wrote:
I use %{SSL_CLIENT_CERT}e with 2.0.54 (patched to get mod_ssl headers).
Is this the problem ? Was it fixed after 2.0.54 ?
Yes, 2.2.0 has the %{...}s support which does this properly. There's a
backport for 2.0 here:
http://people.apache.org/~jorton/mod_headers-2.0-ssl.diff
but it might be stale w.r.t. the latest 2.0.x releases.
joe
SSL_CLIENT_CERT header bad format
It seems that the PEM-encoded certificate coming out of OpenSSL (0.9.8a in
my case) contains new lines without leading space, which is interpreted as a
new HTTP header.
Even more important, the last empty line leads to 2 new lines without
leading space, which is interpreted as the end of all HTTP headers.
This could be fixed by removing all new lines in the PEM-encoded
certificate, in ssl_engine_vars.c:
static char *ssl_var_lookup_ssl_cert_PEM(apr_pool_t *p, X509 *xs)
{
...
BIO_free(bio);
+ /* remove all new lines (CR LF) */
+ {
+ char *source, *target;
+ for ( source = target = result; *source; source++ ) {
+ if ( (*source != 0x0A) (*source != 0x0D) ) *target++ = *source;
+ }
+ *target = NUL;
+ }
return result;
}
Remark: the test
if ( (*source != 0x0A) (*source != 0x0D) )
could also be replaced by a more general one:
if ( *source = ' ' )
