You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@httpd.apache.org by Stefan Fritsch <sf...@sfritsch.de> on 2010/12/30 13:43:57 UTC
Re: SSLRequire & UTF-8 characters & backward compatibility
On Monday 20 December 2010, Stefan Fritsch wrote:
> > > Can
> > > we reject such certificates somehow? Should we close the
> > > connection if we see such a thing in ssl_var_lookup_ssl_cert?
> > > Or should we try to escape the 0-byte in the variable?
> >
> >
> >
> > The latter. I suggest using ASN1_STRING_print_ex() with
> > ASN1_STRFLGS_RFC2253 & ~ASN1_STRFLGS_ESC_MSB (will escape them as
> > \0).
>
> OK, makes sense.
ASN1_STRING_print_ex escapes a whole lot of other stuff, too. So this
change would also introduce an incompatibility with 2.2.x for all the
SSL_{CLIENT,SERVER}_{I,S}_DN_* variables. For example:
'Snake Oil, Ltd.' versus 'Snake Oil\, Ltd.'
This would then also be covered by the SSLOption LegacyDNStringFormat.
Is this a good idea? I would like to have opinions from other people
before committing this.
For reference, here is the list from RFC2253 what is escaped:
o a space or "#" character occurring at the beginning of the
string
o a space character occurring at the end of the string
o one of the characters ",", "+", """, "\", "<", ">" or ";"
Re: SSLRequire & UTF-8 characters & backward compatibility
Posted by Kaspar Brand <ht...@velox.ch>.
On 02.01.2011 01:04, Stefan Fritsch wrote:
> This will still treat non character string types (such as OCTET
> STRING) incorrectly, but I think we can ignore that problem. Or do you
> think we should add ASN1_STRFLGS_DUMP_UNKNOWN | ASN1_STRFLGS_DUMP_DER,
> too?
I wouldn't recommend to add these, no. First, non-STRING types
are clearly out of scope for those 13 DN attributes which mod_ssl
supports. Second, "dumping" the non-character strings would mean that
everything would always be rendered in hex - an OCTET STRING with "Snake
Oil" would show up as "#536E616B65204F696C" (not really useful for our
purposes, IMO).
Kaspar
Re: SSLRequire & UTF-8 characters & backward compatibility
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Friday 31 December 2010, Kaspar Brand wrote:
> On 30.12.2010 13:43, Stefan Fritsch wrote:
> >>> The latter. I suggest using ASN1_STRING_print_ex() with
> >>> ASN1_STRFLGS_RFC2253 & ~ASN1_STRFLGS_ESC_MSB (will escape them
> >>> as \0).
> >>
> >> OK, makes sense.
> >
> > ASN1_STRING_print_ex escapes a whole lot of other stuff, too. So
> > this change would also introduce an incompatibility with 2.2.x
> > for all the SSL_{CLIENT,SERVER}_{I,S}_DN_* variables.
>
> Good point, I didn't consider this when I came up with the
> suggestion quoted above. My new proposal would be to (only) use
>
> ASN1_STRFLGS_ESC_CTRL | ASN1_STRFLGS_UTF8_CONVERT
>
> for the SSL_{CLIENT,SERVER}_{I,S}_DN_* variables instead. This will
> escape the control characters (0x0 through 0x1f), but not the
> others listed in RFC 2253 - most of which primarily make sense
> when a complete DN is rendered, not single attribute values.
This will still treat non character string types (such as OCTET
STRING) incorrectly, but I think we can ignore that problem. Or do you
think we should add ASN1_STRFLGS_DUMP_UNKNOWN | ASN1_STRFLGS_DUMP_DER,
too?
> > This would then also be covered by the SSLOption
> > LegacyDNStringFormat.
>
> With the proposed change to the ASN1_STRING_print_ex flags, I think
> that we could unconditionally use the new format for the
> SSL_{CLIENT,SERVER}_{I,S}_DN_* variables, as there is no
> incompatibility with "simple" strings (i.e., 7-bit characters
> encoded as
> PRINTABLESTRINGs or IA5STRINGs). For non-ASCII characters, the
> current code produces unusable results in many cases anyway, so I
> would not try to retain that as a "legacy" string rendering.
Sounds good, commited to trunk as r1054323. Please review.
Cheers,
Stefan
Re: SSLRequire & UTF-8 characters & backward compatibility
Posted by "William A. Rowe Jr." <wr...@rowe-clan.net>.
On 1/3/2011 3:06 PM, Stefan Fritsch wrote:
>
> The single octet 0xFF should be converted to some UTF8 character
> according to the string type it occurs in, shouldn't it? Since we are
> only escaping control characters I expect that only the codes in the
> range \00 to \1F can appear in \xx form. Is this correct?
0xFE and 0xFF are entirely invalid UTF-8, there is no character unless you
had converted from a single byte character set.
Re: SSLRequire & UTF-8 characters & backward compatibility
Posted by Kaspar Brand <ht...@velox.ch>.
On 03.01.2011 22:06, Stefan Fritsch wrote:
> On Sunday 02 January 2011, Dr Stephen Henson wrote:
>> I'm thinking here how that might be abused. In the current broken
>> OpenSSL code it doesn't escape a backslash with those options. So
>> the following look identical when printed:
>>
>> 1. The single octet 0xFF.
>>
>> 2. The three character string "\FF".
>
> The single octet 0xFF should be converted to some UTF8 character
> according to the string type it occurs in, shouldn't it? Since we are
> only escaping control characters I expect that only the codes in the
> range \00 to \1F can appear in \xx form. Is this correct?
If the escaped SSL_{CLIENT,SERVER}_{I,S}_DN_* string is processed (by
the CGI script, Webapp, ...) as is, then ASN1_STRFLGS_ESC_CTRL is
probably safe even if the backslash escaping isn't fixed in OpenSSL yet.
On the other hand, if someone tries to unescape such a string again (by
searching for a regex like '\\[0-9A-F]{2}'), then he'll possibly run
into problems. E.g., if the original string includes a sequence like
"\DANGEROUS" - he would mistakenly convert this to ÚNGEROUS.
Adding a caveat about unescaping the SSL_{CLIENT,SERVER}_{I,S}_DN_*
strings again to the documentation would certainly make sense, IMO. Not
sure if it's sufficient, though - maybe there are other traps we didn't
think of yet?
Kaspar
Re: SSLRequire & UTF-8 characters & backward compatibility
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Sunday 02 January 2011, Dr Stephen Henson wrote:
> On 02/01/2011 18:42, Stefan Fritsch wrote:
> > On Sunday 02 January 2011, Dr Stephen Henson wrote:
> >> There is a bug in OpenSSL currently for those options: it
> >> doesn't escape the escape character itself (which it should
> >> treat as a special case and always escape it if any other
> >> escaping is in use). That means some representations are
> >> ambiguous with those options.
> >>
> >> When that is fixed even 7 bit without control characters will
> >> have at least one difference: the backslash will always appear
> >> escaped as "\\".
> >
> > I guess backslashes are very seldomly used in certificates.
> > Therefore, I would just document that change for now and only
> > add a backward compatibility option if the change turns out to
> > be a problem for users.
>
> I'm thinking here how that might be abused. In the current broken
> OpenSSL code it doesn't escape a backslash with those options. So
> the following look identical when printed:
>
> 1. The single octet 0xFF.
>
> 2. The three character string "\FF".
The single octet 0xFF should be converted to some UTF8 character
according to the string type it occurs in, shouldn't it? Since we are
only escaping control characters I expect that only the codes in the
range \00 to \1F can appear in \xx form. Is this correct?
Re: SSLRequire & UTF-8 characters & backward compatibility
Posted by Dr Stephen Henson <sh...@oss-institute.org>.
On 02/01/2011 18:42, Stefan Fritsch wrote:
> On Sunday 02 January 2011, Dr Stephen Henson wrote:
>
>> There is a bug in OpenSSL currently for those options: it doesn't
>> escape the escape character itself (which it should treat as a
>> special case and always escape it if any other escaping is in
>> use). That means some representations are ambiguous with those
>> options.
>>
>> When that is fixed even 7 bit without control characters will have
>> at least one difference: the backslash will always appear escaped
>> as "\\".
>
> I guess backslashes are very seldomly used in certificates. Therefore,
> I would just document that change for now and only add a backward
> compatibility option if the change turns out to be a problem for
> users.
>
I'm thinking here how that might be abused. In the current broken OpenSSL code
it doesn't escape a backslash with those options. So the following look
identical when printed:
1. The single octet 0xFF.
2. The three character string "\FF".
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
Re: SSLRequire & UTF-8 characters & backward compatibility
Posted by Stefan Fritsch <sf...@sfritsch.de>.
On Sunday 02 January 2011, Dr Stephen Henson wrote:
> On 31/12/2010 07:52, Kaspar Brand wrote:
> > On 30.12.2010 13:43, Stefan Fritsch wrote:
> >>>> The latter. I suggest using ASN1_STRING_print_ex() with
> >>>> ASN1_STRFLGS_RFC2253 & ~ASN1_STRFLGS_ESC_MSB (will escape them
> >>>> as \0).
> >>>
> >>> OK, makes sense.
> >>
> >> ASN1_STRING_print_ex escapes a whole lot of other stuff, too. So
> >> this change would also introduce an incompatibility with 2.2.x
> >> for all the SSL_{CLIENT,SERVER}_{I,S}_DN_* variables.
> >
> > Good point, I didn't consider this when I came up with the
> > suggestion quoted above. My new proposal would be to (only) use
> >
> > ASN1_STRFLGS_ESC_CTRL | ASN1_STRFLGS_UTF8_CONVERT
> >
> > for the SSL_{CLIENT,SERVER}_{I,S}_DN_* variables instead. This
> > will escape the control characters (0x0 through 0x1f), but not
> > the others listed in RFC 2253 - most of which primarily make
> > sense when a complete DN is rendered, not single attribute
> > values.
> >
> >> This would then also be covered by the SSLOption
> >> LegacyDNStringFormat.
> >
> > With the proposed change to the ASN1_STRING_print_ex flags, I
> > think that we could unconditionally use the new format for the
> > SSL_{CLIENT,SERVER}_{I,S}_DN_* variables, as there is no
> > incompatibility with "simple" strings (i.e., 7-bit characters
> > encoded as PRINTABLESTRINGs or IA5STRINGs). For non-ASCII
> > characters, the current code produces unusable results in many
> > cases anyway, so I would not try to retain that as a "legacy"
> > string rendering.
> >
> >> I would like to have opinions from other people before
> >> committing this.
> >
> > Yes, please - additional opinions appreciated.
>
> Well it wont be totally compatible with the old format even if it
> only contains 7-bit ASCII characters. For example the tab
> character would be escaped.
I don't think we need to care about control characters. I can't
imagine any legitimate use in certificates.
> There is a bug in OpenSSL currently for those options: it doesn't
> escape the escape character itself (which it should treat as a
> special case and always escape it if any other escaping is in
> use). That means some representations are ambiguous with those
> options.
>
> When that is fixed even 7 bit without control characters will have
> at least one difference: the backslash will always appear escaped
> as "\\".
I guess backslashes are very seldomly used in certificates. Therefore,
I would just document that change for now and only add a backward
compatibility option if the change turns out to be a problem for
users.
Re: SSLRequire & UTF-8 characters & backward compatibility
Posted by Dr Stephen Henson <sh...@oss-institute.org>.
On 31/12/2010 07:52, Kaspar Brand wrote:
> On 30.12.2010 13:43, Stefan Fritsch wrote:
>>>> The latter. I suggest using ASN1_STRING_print_ex() with
>>>> ASN1_STRFLGS_RFC2253 & ~ASN1_STRFLGS_ESC_MSB (will escape them as
>>>> \0).
>>>
>>> OK, makes sense.
>>
>> ASN1_STRING_print_ex escapes a whole lot of other stuff, too. So this
>> change would also introduce an incompatibility with 2.2.x for all the
>> SSL_{CLIENT,SERVER}_{I,S}_DN_* variables.
>
> Good point, I didn't consider this when I came up with the suggestion
> quoted above. My new proposal would be to (only) use
>
> ASN1_STRFLGS_ESC_CTRL | ASN1_STRFLGS_UTF8_CONVERT
>
> for the SSL_{CLIENT,SERVER}_{I,S}_DN_* variables instead. This will
> escape the control characters (0x0 through 0x1f), but not the others
> listed in RFC 2253 - most of which primarily make sense when a complete
> DN is rendered, not single attribute values.
>
>> This would then also be covered by the SSLOption LegacyDNStringFormat.
>
> With the proposed change to the ASN1_STRING_print_ex flags, I think that
> we could unconditionally use the new format for the
> SSL_{CLIENT,SERVER}_{I,S}_DN_* variables, as there is no incompatibility
> with "simple" strings (i.e., 7-bit characters encoded as
> PRINTABLESTRINGs or IA5STRINGs). For non-ASCII characters, the current
> code produces unusable results in many cases anyway, so I would not try
> to retain that as a "legacy" string rendering.
>
>> I would like to have opinions from other people before committing this.
>
> Yes, please - additional opinions appreciated.
>
Well it wont be totally compatible with the old format even if it only contains
7-bit ASCII characters. For example the tab character would be escaped.
There is a bug in OpenSSL currently for those options: it doesn't escape the
escape character itself (which it should treat as a special case and always
escape it if any other escaping is in use). That means some representations are
ambiguous with those options.
When that is fixed even 7 bit without control characters will have at least one
difference: the backslash will always appear escaped as "\\".
Steve.
--
Dr Stephen N. Henson. Senior Technical/Cryptography Advisor,
Open Source Software Institute: www.oss-institute.org
OpenSSL Core team: www.openssl.org
Re: SSLRequire & UTF-8 characters & backward compatibility
Posted by Kaspar Brand <ht...@velox.ch>.
On 30.12.2010 13:43, Stefan Fritsch wrote:
>>> The latter. I suggest using ASN1_STRING_print_ex() with
>>> ASN1_STRFLGS_RFC2253 & ~ASN1_STRFLGS_ESC_MSB (will escape them as
>>> \0).
>>
>> OK, makes sense.
>
> ASN1_STRING_print_ex escapes a whole lot of other stuff, too. So this
> change would also introduce an incompatibility with 2.2.x for all the
> SSL_{CLIENT,SERVER}_{I,S}_DN_* variables.
Good point, I didn't consider this when I came up with the suggestion
quoted above. My new proposal would be to (only) use
ASN1_STRFLGS_ESC_CTRL | ASN1_STRFLGS_UTF8_CONVERT
for the SSL_{CLIENT,SERVER}_{I,S}_DN_* variables instead. This will
escape the control characters (0x0 through 0x1f), but not the others
listed in RFC 2253 - most of which primarily make sense when a complete
DN is rendered, not single attribute values.
> This would then also be covered by the SSLOption LegacyDNStringFormat.
With the proposed change to the ASN1_STRING_print_ex flags, I think that
we could unconditionally use the new format for the
SSL_{CLIENT,SERVER}_{I,S}_DN_* variables, as there is no incompatibility
with "simple" strings (i.e., 7-bit characters encoded as
PRINTABLESTRINGs or IA5STRINGs). For non-ASCII characters, the current
code produces unusable results in many cases anyway, so I would not try
to retain that as a "legacy" string rendering.
> I would like to have opinions from other people before committing this.
Yes, please - additional opinions appreciated.
Kaspar