httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Todd" <todd_...@yahoo.com>
Subject Re: Patches and Enhancements for a SSL-Proxy Based on Apache 2.0 (mod_ssl, mod_proxy, mod_headers)
Date Fri, 19 Sep 2003 00:12:38 GMT
I'm just looking for a fix to this problem. Granted that this
is a security issue specifically in this case b/c the header
turns out to be a Client Cert.

I am not sure where the bug is, my guess is it's in mod-headers
if that is the case, a plain HTTP header that is multi-line 
would be corrupted as well.


--- In new-httpd@yahoogroups.com, "William A. Rowe, Jr." <wrowe@r...> 
wrote:
> At 06:17 AM 2/14/2003, Graham Leggett wrote:
> >Maik Mueller wrote:
> >
> >>Putting arbitrary 8bit characters into headers makes me feel a 
bit uneasy
> >>but I couldn't find a quote that this is forbidden.
> >
> >Looking at this further, the header value is defined as TEXT. TEXT 
is defined as OCTETs that are not control characters. An OCTET is an 
8 bit character. As far as I can see it should be up to the entity 
putting data into the header to make sure it does not contain control 
characters. In your case, base64 would thus be safe.
> 
> I believe base64 (or a base95) encoding is vastly preferable to 
arbitrary octets.
> There are already modules that attempt to 'fix' the charset from 
the client, e.g.
> from an english client to a russian server, or dealing with the 
eastern character
> sets with utf-8.
> 
> >>What do you think about my proposal to add the "E" option with 
the described
> >>behavior to the Header and RequestHeader directive?
> >>Keeping in mind that HTTP 1.0 still warns:
> >>
> >>>However, folding of header lines is not expected by some
> >>>applications, and should not be generated by HTTP/1.0 
applications.
> >
> >HTTP 1.0 is obsolete - Apache follows HTTP/1.1, defined in RFC2616.
> 
> Not only that, but these headers are sent *to* an Apache backend 
server that
> does expect those folded lines.  I'm not reading that your encoded 
SSL datum
> would be passed back to any arbitrary client.
> 
> Finally, I'm really concerned about the security aspect.  Folks 
might not realize
> that by enabling this feature and neglecting to put the backend box 
behind the
> dmz (or even, passing this arbitrary new header through HTTP) - 
they would 
> expose the backend server to fradulent credentials.  Before we 
adopt this patch
> I'd the security aspect of the SSL-proxy -> credentials -> backend-
server to see 
> that resolved in the 80/20.  We don't need a repeat of the HTTP 
port 25 proxy
> issue (a config issue - but that egg has landed in *our* face, not 
the admins
> of those open relays.)
> 
> Bill


Mime
View raw message