This service will be undergoing maintenance at 00:00 UTC, 2017-10-23 It is expected to last about 30 minutes
Bug 500180 - [PEM] reader takes only 8 characters long passwords while loading a private key
[PEM] reader takes only 8 characters long passwords while loading a private key
Status: CLOSED ERRATA
Product: Fedora
Classification: Fedora
Component: nss (Show other bugs)
10
All Linux
medium Severity medium
: ---
: ---
Assigned To: Elio Maldonado Batiz
Fedora Extras Quality Assurance
:
Depends On:
Blocks: 501138
  Show dependency treegraph
 
Reported: 2009-05-11 10:35 EDT by Michael Cronenworth
Modified: 2009-07-19 06:26 EDT (History)
5 users (show)

See Also:
Fixed In Version: 3.12.3.99.3-2.10.4.fc10
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2009-07-19 06:25:47 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


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

  None (edit)
Description Michael Cronenworth 2009-05-11 10:35:57 EDT
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) 2009-05-12 09:07:23 EDT
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 09:14:11 EDT
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 10:42:22 EDT
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) 2009-05-12 11:01:57 EDT
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 11:19:16 EDT
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 14:07:42 EDT
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 16:00:06 EDT
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 16:04:35 EDT
(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 16:43:02 EDT
Created attachment 343662 [details]
testcase
Comment 10 Rob Crittenden 2009-05-12 17:43:36 EDT
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 18:23:07 EDT
I think it's about the password length. Only 8 characters password seem to work well.
Comment 12 Kamil Dudka 2009-05-12 18:26:13 EDT
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 01:56:15 EDT
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 17:28:30 EDT
Created attachment 343877 [details]
proposed patch

patch ready
Comment 15 Elio Maldonado Batiz 2009-05-13 18:25:16 EDT
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 16:54:46 EDT
(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 17:15:28 EDT
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 17:30:14 EDT
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 00:06:16 EDT
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-26 22:39:13 EDT
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-26 22:57:00 EDT
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 06:25:17 EDT
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 06:26:22 EDT
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.