Bug 500180 - [PEM] reader takes only 8 characters long passwords while loading a private key
Summary: [PEM] reader takes only 8 characters long passwords while loading a private key
Keywords:
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: nss
Version: 10
Hardware: All
OS: Linux
medium
medium
Target Milestone: ---
Assignee: Elio Maldonado Batiz
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Depends On:
Blocks: 501138
TreeView+ depends on / blocked
 
Reported: 2009-05-11 14:35 UTC by Michael Cronenworth
Modified: 2018-02-09 11:04 UTC (History)
5 users (show)

Fixed In Version: 3.12.3.99.3-2.10.4.fc10
Doc Type: Bug Fix
Doc Text:
Clone Of:
Environment:
Last Closed: 2009-07-19 10:25:47 UTC


Attachments (Terms of Use)
testcase (6.41 KB, application/x-gzip)
2009-05-12 20:43 UTC, Kamil Dudka
no flags Details
proposed patch (609 bytes, patch)
2009-05-13 21:28 UTC, Kamil Dudka
no flags Details | Diff

Description Michael Cronenworth 2009-05-11 14:35:57 UTC
Description of problem: The following passwords are considered too "weak" to be used in conjunction with libcurl and PEM certs:
A!mj8z$mc
A!m(8z$mC
A!m(89$mC
cS^FMuwjN(?6Z#b
fb7GtHJ&`<
(and on and on and on, these are just examples)

Somehow this password works just fine:
asDF89*(


Version-Release number of selected component (if applicable): nss-3.12.2.0-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.

Comment 1 Kai Engert (:kaie) (inactive account) 2009-05-12 13:07:23 UTC
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?

Comment 2 Michael Cronenworth 2009-05-12 13:14:11 UTC
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.

Comment 3 Kamil Dudka 2009-05-12 14:42:22 UTC
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?

Comment 4 Kai Engert (:kaie) (inactive account) 2009-05-12 15:01:57 UTC
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.

Comment 5 Kamil Dudka 2009-05-12 15:19:16 UTC
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 NULL;
  else
    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.

Comment 6 Elio Maldonado Batiz 2009-05-12 18:07:42 UTC
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.

Comment 7 Rob Crittenden 2009-05-12 20:00:06 UTC
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.

Comment 8 Michael Cronenworth 2009-05-12 20:04:35 UTC
(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:
test

Four characters are also rejected. Please read bug 453612 as some of this I am repeating.

Comment 9 Kamil Dudka 2009-05-12 20:43:02 UTC
Created attachment 343662 [details]
testcase

Comment 10 Rob Crittenden 2009-05-12 21:43:36 UTC
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.

Comment 11 Kamil Dudka 2009-05-12 22:23:07 UTC
I think it's about the password length. Only 8 characters password seem to work well.

Comment 12 Kamil Dudka 2009-05-12 22:26:13 UTC
I can see some magic eights within pem_mdSession_Login(). Maybe we want to replace one of them with strlen(pin->data)? (just guessing)

Comment 13 Kamil Dudka 2009-05-13 05:56:15 UTC
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.

Comment 14 Kamil Dudka 2009-05-13 21:28:30 UTC
Created attachment 343877 [details]
proposed patch

patch ready

Comment 15 Elio Maldonado Batiz 2009-05-13 22:25:16 UTC
Thank you Kamil for the patch. Your test is passing for me. Let me play with this a bit more.

Comment 16 Elio Maldonado Batiz 2009-05-16 20:54:46 UTC
(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.

Comment 17 Kamil Dudka 2009-05-16 21:15:28 UTC
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.

Comment 18 Elio Maldonado Batiz 2009-05-16 21:30:14 UTC
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.

Comment 19 Fedora Update System 2009-06-23 04:06:16 UTC
nss-3.12.3.99.3-2.11.3.fc11 has been submitted as an update for Fedora 11.
http://admin.fedoraproject.org/updates/nss-3.12.3.99.3-2.11.3.fc11

Comment 20 Fedora Update System 2009-06-27 02:39:13 UTC
nss-3.12.3.99.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

Comment 21 Fedora Update System 2009-06-27 02:57:00 UTC
nss-3.12.3.99.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

Comment 22 Fedora Update System 2009-07-19 10:25:17 UTC
nss-3.12.3.99.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.

Comment 23 Fedora Update System 2009-07-19 10:26:22 UTC
nss-3.12.3.99.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.


Note You need to log in before you can comment on or make changes to this bug.