Description of problem: The following passwords are considered too "weak" to be used in conjunction with libcurl and PEM certs:
(and on and on and on, these are just examples)
Somehow this password works just fine:
Version-Release number of selected component (if applicable): nss-22.214.171.124-5.fc10
How reproducible: Always
Steps to Reproduce:
1. openssl rsa -in key.pem -des3 -out key-secure.pem
2. Use one of the problem passwords from above.
3. Use libcurl with curl_easy_setopt( curl, CURLOPT_KEYPASSWD, password );
4. Run program (with verbose enabled) and you will receive:
* Unable to load client key: Incorrect password
* Closing connection #0
* Problem with the local SSL certificate
Actual results: libcurl cannot connect to an HTTPS URL with a client cert.
Expected results: libcurl should connects to a HTTPS URL with client cert.
Additional info: Related bug 453612.
Michael, you say "password is too weak", but in the steps to reproduce, I don't see any output that suggests the password is too weak.
Why did you conclude the password is too weak?
Did you get a message saying so?
It was suggested in bug 453612 in comment 20 that my "incorrect password" messages are due to NSS rejecting the strength of my password prior to it even being used to unlock my PEM key.
Is this report correct? I have not investigated the NSS/libcurl code interaction myself. I am going off of Kamil Dudka's suggestion. If this report is correct, why on earth is NSS checking the strength of passphrases on PEM keys in the first place? People want their keys unlocked not extra layers of bureaucracy. I'd like to know how to disable this check, if the report is true.
It was my conclusion while reading nss_compat_ossl code. The password strength is checked explicitly there by PK11_SetPasswordFunc()/PK11_Authenticate() callback functions. Rob, could you please explain why?
In my understanding, password strength restrictions only happen while the NSS library has been switched into the non-default FIPS mode.
Unless your operation switched to FIPS mode explicitly, even empty passwords should work.
Then it sounds like a PEM reader bug to me. The related curl code just sets PK11_SetPasswordFunc callback to this function:
static char * nss_get_password(PK11SlotInfo *slot, PRBool retry, void *arg)
(void)slot; /* unused */
if(retry || NULL == arg)
return (char *)PORT_Strdup((char *)arg);
And function PK11_Authenticate(slot, PR_TRUE, passwd) then fails for *some* passwords. I don't think curl does something wrong in handling the passwords.
PK11_Authenticate relies on the token to handle the password requirements. On FIPS mode length constraints are enforced but this is done by softoken not by the higher layers or the framework that mediates with the various other PKCS #11 modules. From my reading of the code so far the PEM module does not enforce a minimum nor maximum length of the PIN or any other password requirements. The problem seems to lie elsewhere. I need to dig some more and maybe some actual live tracing.
It jumps out at me that the working password is 8 characters and all the failing ones are longer. So I get the feeling it isn't a matter of strength, but of length.
(In reply to comment #7)
> It jumps out at me that the working password is 8 characters and all the
> failing ones are longer. So I get the feeling it isn't a matter of strength,
> but of length.
I knew this was going to come up (not length but comparing my examples).
Add this password to the list:
Four characters are also rejected. Please read bug 453612 as some of this I am repeating.
Created attachment 343662 [details]
Elio, to debug you'll want to break in pem_mdSession_Login() to trace this.
The problem seems to be in the creation of the DES key. I'm not sure why it is successful in some cases but not others.
I think it's about the password length. Only 8 characters password seem to work well.
I can see some magic eights within pem_mdSession_Login(). Maybe we want to replace one of them with strlen(pin->data)? (just guessing)
Note that PK11_Authenticate() also passes when some garbage is appended at the end of a correct 8 characters long password. It just ignores the suffix in that case.
Created attachment 343877 [details]
Thank you Kamil for the patch. Your test is passing for me. Let me play with this a bit more.
(In reply to comment #14) Kamil, I gave it a + and plan check in the changes in devel and do a buld in Koji soon. I would like first finish reviewing of the other pem module patches you have submitted if you don't mind.
Sure. I'd like the bugfixes to be reviewed separately, but no problem to build it at once. The curl is broken for two years, so it doesn't matter if the update will be released this week or two weeks later. I am going to open a tracking bug against curl to consolidate all these bugs introduced by migration to NSS. Note the nss package is not the only culprit of broken curl. Two one-line patches are pending for coolkey package as well.
Yes, a tracking bug is a good idea.
Earlier when I granted review on this (plus gcc warnings and mutex one), I ended up granting request to myself. Let me reassign the other three (memory leaks ones) to you, please set the request review ? flag and reassign back me so things come out right. Sorry, about that. The other reviews will take me a bit longer. Thanks.
nss-126.96.36.199.3-2.11.3.fc11 has been submitted as an update for Fedora 11.
nss-188.8.131.52.3-2.11.3.fc11 has been pushed to the Fedora 11 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update nss'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F11/FEDORA-2009-6948
nss-184.108.40.206.3-2.10.4.fc10 has been pushed to the Fedora 10 testing repository. If problems still persist, please make note of it in this bug report.
If you want to test the update, you can install it with
su -c 'yum --enablerepo=updates-testing update nss'. You can provide feedback for this update here: http://admin.fedoraproject.org/updates/F10/FEDORA-2009-7017
nss-220.127.116.11.3-2.11.3.fc11 has been pushed to the Fedora 11 stable repository. If problems still persist, please make note of it in this bug report.
nss-18.104.22.168.3-2.10.4.fc10 has been pushed to the Fedora 10 stable repository. If problems still persist, please make note of it in this bug report.