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