[openssl-dev] [PATCH] Support broken PKCS#12 key generation.

[David Woodhouse]

On Mon, 2016-08-29 at 23:01 +0200, Andy Polyakov wrote:
> > 
> > So let's try a better example. The password is "ĂŻ" (U+0102 U+017b),
> > and the locale (not that it *should* matter) is ISO8859-2.
> When it comes to locale in *this* case you should rather wonder what
> does your terminal emulator program do and how does it interact with
> your shell. Because these two are responsible for composing the string
> that OPENSSL_[asc|utf8]2uni gets.

Right. And for the purpose of my example I have moved to eastern Europe
and fallen through a time-warp into the 20th century, so I'm using an
ISO8859-2 locale.

> > The correct rendition is 01 02 01 7b.
> Yes. And now note that it's passed as 'c4 82 c5 bb' to openssl pkcs12 as
> argument or console input under an UTF-8 locale. Otherwise it would have
> been passed as 'c3 af'.

No. My locale is ISO8859-2 so the password "ĂŻ" *is* passed as 'c3 af'.

Old OpenSSL will ignore the fact that the locale is ISO8859-2, and
perform an ISO8859-1 to UCS16BE conversion using the doubly-misnamed
OPENSSL_asc2uni() function. So it'll use '00 c3 00 af'.

New OpenSSL will ignore the fact that the locale is ISO8859-2, and
perform a UTF-8 to UCS16BE conversion using the only singly renamed
OPENSSL_utf82uni() function. So it'll use '00 ef'.

You had a bug because you made assumptions about the input data and
didn't properly convert from the locale charset to UTF16BE as you
should have done. Instead of fixing the bug, you just changed the
assumption you made to one that's slightly more likely to be valid in
today's world.

Leaving the rest of us with *two* buggy behaviours to try to work
around.

> > 
> > The "old buggy OpenSSL" rendition, in the ISO8859-2 locale, would be
> > to *convert* to ISO8859-2 (giving c3 af).
> No, no conversion from UTF-8 to ISO8859-x or any other conversion was
> *ever* performed. Nor is it performed now. It was and still is all about
> how string is composed by *somebody else*. That's why I said that "we
> assume that you don't change locale when you upgrade OpenSSL".

I'm talking about how other libraries should attempt to read the
PKCS#12 files created by OpenSSL. In my code I have the string "ĂŻ"
which the user has provided as the password. It doesn't matter what
charset it's in, as long as I *know* what charset it's in, and haven't
wantonly thrown that information away and started making *assumptions*
about how to interpret the stream of bytes.

So in order to try to emulate the old OpenSSL bug and read the file, I
need to convert to ISO8859-2, then "forget" that it's ISO8859-2 and
treat it as ISO8859-1 for the purpose of converting to UTF16BE and
trying to decrypt. Which gives me the '00 c3 00 af' as above.

And in order to emulate the new OpenSSL bug and read the file, I need
to convert to ISO8859-2, then "forget" that it's ISO8859-2 and treat it
as UTF-8 for the purpose of converting to UTF16BE and trying to
decrypt. Which gives me the '00 ef' that current OpenSSL will use.

This latter buggy behaviour hasn't actually been released yet, has it?
Is it too late to fix it properly?

-- 
dwmw2

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/x-pkcs7-signature
Size: 5760 bytes
Desc: not available
URL: <http://mta.openssl.org/pipermail/openssl-dev/attachments/20160830/0432a067/attachment.bin>