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 [EMAIL PROTECTED], "William A. Rowe, Jr." <[EMAIL PROTECTED]> 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
