User-Agent: Opera/9.64 (Windows NT 6.0; U; it) Presto/2.1.1 Build Identifier: In source file security/manager/ssl/src/nsPKCS12Blob.cpp (nsPKCS12Blob::unicodeToItem): 513 item->data[2*i ] = (unsigned char )(uni[i] << 8); The function erroneously shifts to the left, instead of the right. Therefore, (unsigned char )(uni[i] << 8) is always zero, and this mangles all passwords containing codepoints above U+00FF Reproducible: Always Steps to Reproduce: 1. Export a key pair in PKCS#12 format from another application (for example, the Windows certificate manager), using a password that contains characters above U+00FF (for example: "黒い") 2. Attempt to import the key pair in any Mozilla application, using the same password Actual Results: Importing the key pair fails because of a password error Expected Results: Importing the key pair succeeds This is a security issue, since it effectively halves the password strength, although luckily it's the highest 8 bits that are lost. It affects Mozilla 1.8 as well (the code is identical). It's a sneaky issue because the same, broken algorithm is used both to encrypt and decrypt, so roundtripping works fine Technically, this is easy to fix. In source file security/manager/ssl/src/nsPKCS12Blob.cpp (nsPKCS12Blob::unicodeToItem), replace this line: 513 item->data[2*i ] = (unsigned char )(uni[i] << 8); with the following: 513 item->data[2*i ] = (unsigned char )(uni[i] >> 8); For backwards compatibility with broken PKCS#12 containers generated by previous releases, the broken behavior could be kept as another "flavor" of password in the PKCS#12 importer (like there already are two flavors of empty passwords)
Michele: Would be helpful to know which version of Firefox you are running here - is it Firefox 188.8.131.52? Thanks.
Tried and verified on: Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:184.108.40.206) Gecko/2009042316 Firefox/3.0.10 (.NET CLR 3.5.30729) Mozilla/5.0 (Windows; U; Windows NT 6.0; en-US; rv:1.9.1b3pre) Gecko/20090223 Thunderbird/3.0b2 Mozilla/5.0 (Windows; U; Windows NT 6.0; it; rv:220.127.116.11) Gecko/20090302 Thunderbird/18.104.22.168 Further proof: I tried exporting a key pair from Mozilla using the password "黒い" (U+9ED2 U+3044), and then I tried importing it in Windows. The correct password doesn't work in Windows, but the mangled form "ÒD" (U+00D2 U+0044) does, both in Windows and all Mozilla applications above (i.e. to Mozilla, "黒い" and "ÒD" are identical as far as PKCS#12 is concerned)
Assignee: nobody → kaie
Component: Libraries → Security: UI
Product: NSS → Core
QA Contact: libraries → ui
Version: trunk → 1.9.0 Branch
Status: UNCONFIRMED → NEW
Component: Security: UI → Security: PSM
Ever confirmed: true
QA Contact: ui → psm
I tried to test the proposed fix but there is still a problem. Interchange of certs still doesn't work between windows and ff when there is a unicode password. I will investigate further.
Assignee: kaie → nobody
Whiteboard: [sg:low] → [sg:low][psm-cert-manager][psm-logic]
Whiteboard: [sg:low][psm-cert-manager][psm-logic] → [sg:low][psm-cert-manager][psm-logic][psm-backlog]
AFAICT this was fixed in Bug 1082346.
Status: NEW → RESOLVED
Last Resolved: 2 years ago
Resolution: --- → DUPLICATE
Duplicate of bug: 1082346
You need to log in before you can comment on or make changes to this bug.