Re: SSLRequire UTF-8 characters backward compatibility
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
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
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
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
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
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
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
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
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
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
