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
