httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefan Fritsch ...@sfritsch.de>
Subject Re: Fwd: [users@httpd] SSLRequire & UTF-8 characters
Date Sun, 19 Dec 2010 00:58:27 GMT
On Monday 29 November 2010, Dr Stephen Henson wrote:
> On 24/11/2010 07:07, Kaspar Brand wrote:
> > On 20.11.2010 20:24, Stefan Fritsch wrote:
> >> On Fri, 19 Nov 2010, Joe Orton wrote:
> >>> We could support this better by having a new set of exports:
> >>>   SSL_{CLIENT,SERVER}_{I,S}_UTF8DN_*(_n)?
> >>> 
> >>> (or something similarly named)
> >>> 
> >>> which works the same as _DN_ but exports the attributes as a
> >>> UTF-8 byte seequence regardless of the underlying ASN.1 type;
> >>> this would be a relatively simple hack.
> >> 
> >> Or have a (per vhost) directive that enables conversion for all
> >> SSL_*_S_DN_* and SSL_*_S_DN to UTF8. IMHO, this could even be
> >> enabled by default in 2.4.
> > 
> > I prefer the latter approach, yes (there's already an awful lot
> > of SSL_* something variables).
> > 
> > Given the fact that mod_ssl's current behavior with non-ASCII
> > characters (i.e., outside the 0-127 range) is mostly undefined
> > and/or sometimes even erroneous (a BMPString in the subject or
> > issuer DN will end up as an empty SSL_*_*_DN_* variable, due to
> > the initial null byte), I would suggest the following solution:
> > 
> > - for all SSL_{CLIENT,SERVER}_{I,S}_DN_* variables, use UTF-8 by
> > default
> > 
> >   (i.e., adapt ssl_engine_vars.c:ssl_var_lookup_ssl_cert_dn() to
> >   convert TeletexString, UniversalString and BMPString types to
> >   UTF8String)
> > 
> > - for SSL_{CLIENT,SERVER}_{I,S}_DN, don't use X509_NAME_oneline()
> > 
> >   any more and switch to X509_NAME_print_ex() instead. What flags
> >   should be used is probably debatable - I would recommend to go
> >   with XN_FLAG_RFC2253 (note that using XN_FLAG_ONELINE with
> >   X509_NAME_print_ex doesn't produce the same string as
> >   X509_NAME_oneline, so this will break backward compatibility
> >   in any case)
> > 
> > - add another parameter to the SSLOptions directive which allows
> > 
> >   re-enabling the "old" string rendering for
> >   SSL_{CLIENT,SERVER}_{I,S}_DN (so the new default would be to
> >   rely on X509_NAME_print_ex - even for 2.2 -, but people could
> >   restore the current behavior through this option)
> 
> It's a very good idea to avoid X509_NAME_oneline() wherever
> possible as it is highly broken, can produce ambiguous output (of
> the Bobby Tables variety) and at other times be just plain wrong
> (BMPStrings is one of many examples).
> 
> We have to retain it in OpenSSL for backwards compatibility though.
> I'd throw it out tomorrow if I could get away with it.
> 
> You can get a UTF8String from most string types using
> ASN1_STRING_to_UTF8(). This should be adequate for most purposes:
> it doesn't handle the more bizarre TeletexString shift conversions
> but those are rarely encountered in practice.

I have come up with the attached patch which more or less implements 
Kaspar's suggestions. I am using
"XN_FLAG_RFC2253 & ~ASN1_STRFLGS_ESC_MSB" as flags for 
X509_NAME_print_ex() for SSL_{CLIENT,SERVER}_{I,S}_DN. This changes

/C=US/ST=California/L=San Francisco/O=ASF/OU=httpd-
test/CN=ca/emailAddress=test-dev@httpd.apache.org

into

emailAddress=test-dev@httpd.apache.org,CN=ca,OU=httpd-test,O=ASF,L=San 
Francisco,ST=California,C=US

Is this what we want? We could use XN_FLAG_DN_REV to keep the old 
order. I haven't tried UTF8 characters, yet.

Instead of an SSLOption (which would require a request_rec to lookup), 
I have implemented a per-vhost option for restoring compatibility.

Mime
View raw message