Bug 1369251

Sorry, bug 631000 ... or maybe bug 614531? Either way, not actually fixed... :)

nss-pem currently accepts headers like this:

-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: DES-EDE3-CBC,89CFC0A0B653CBDF

... where the decryption parameters are taken directly from the text whereas for PKCS #8 we need to use an ASN1 decoder to get them.  Do I understand the problem correctly?

Yep. Your torture tests should include keys generated/mangled in a variety of ways...




# PKCS#8 encrypted (PKCS#5 v2.0), HMAC-SHA1
openssl pkcs8 -topk8 -in key.pem -out key-pkcs8-crypt.pem -v2 aes258 -v2prf hmacWithSHA1
-----BEGIN ENCRYPTED PRIVATE KEY-----

# PKCS#8 encrypted (PKCS#5 v2.0), HMAC-SHA256
openssl pkcs8 -topk8 -in key.pem -out key-pkcs8-crypt.pem -v2 aes258 -v2prf hmacWithSHA256
-----BEGIN ENCRYPTED PRIVATE KEY-----

# PKCS#8 unencrypted
openssl pkcs8 -topk8 -in key.pem -nocrypt
-----BEGIN PRIVATE KEY-----

# PKCS#1 unencrypted
openssl rsa -in key-pkcs8-crypt.pem -out key-pkcs1.pem
-----BEGIN RSA PRIVATE KEY----

# PKCS#1 (legacy OpenSSL encrypted)
openssl rsa -in key-pkcs8-crypt.pem -out key-pkcs1-crypted.pem -aes128
-----BEGIN RSA PRIVATE KEY-----
Proc-Type: 4,ENCRYPTED
DEK-Info: AES-128-CBC,03C0E0115419AD1EFE79C6B0D304A5EB

openssl rsa -in ke2.pem -out ke3.pem

# PKCS#12
openssl pkcs12 -export -out foo.p12 -inkey foo -in cert -certfile ca.cert -chain 

We really should expand https://fedoraproject.org/wiki/PackagingDrafts/SSLCertificateHandling to suggest that apps should automatically handle all of these, not *just* RFC7512 IDs.

And those just for RSA, of course. We should cover other types of keys too, ideally.

*** Bug 873858 has been marked as a duplicate of this bug. ***

I have spent some time debugging NSS internals and found some ASN1 templates that helped me to extract decryption parameters out of PKCS #8 key files.  The output looks like this:

    Encryption Algorithm: PKCS #12 V2 PBE With SHA-1 And 3KEY Triple DES-CBC
        Parameters:
            Salt:
                2f:46:98:4e:f2:90:ee:17
            Iteration Count: 2048 (0x800)

... or this:

    Encryption Algorithm: PKCS #5 Password Based Encryption v2 
        Encryption:
            KDF: PKCS #5 Password Based Key Dervive Function v2 
                Parameters:
                    Salt:
                        30:57:b8:36:8a:0c:16:e1
                    Iteration Count: 1 (0x1)
            Cipher: DES-EDE3-CBC
                Args:
                    04:08:8a:a4:bb:6e:43:2e:95:53

... or this:

    Encryption Algorithm: PKCS #5 Password Based Encryption v2 
        Encryption:
            KDF: PKCS #5 Password Based Key Dervive Function v2 
                Parameters:
                    Salt:
                        58:2b:65:6e:20:96:68:01
                    Iteration Count: 2048 (0x800)
            Cipher: AES-128-CBC
                Args:
                    04:10:0f:af:03:9e:87:85:8e:ab:1d:ea:67:78:e8:a4:
                    6c:7b

I am not sure if there is a generic enough way to decrypt them using NSS API, though, and do not feel like (re)implementing all the code myself.  Anyway, I am attaching my experimental patches for both nss and nss-pem in case someone wants to experiment further with that.

Created attachment 1194072 [details]
[PATCH] secutil: extract decryption parameters out of PKCS #8 key files

Created attachment 1194073 [details]
[PATCH] nss-pem: extract decryption parameters out of PKCS #8 key files

NSS can already do all this, can't it? Because it already has support for PKCS#12 objects, and those can *contain* PKCS#8 objects. Perhaps the way forward is to expand the existing NSS support for PKCS#12, to also handle PKCS#8 directly?

Or maybe in nss-pem you could construct a PKCS#12 'wrapper' to contain the PKCS#8 object you're trying to decode, but that's a little horrid.

Not exactly, NSS has problems handling PKCS#12 files with new options: bug 1220573

Hm, thanks. I'll add those to my tests at http://git.infradead.org/users/dwmw2/openconnect.git/blob/HEAD:/tests/Makefile.am

We should add non-RSA key types and add passing that test suite to the Fedora packaging guidelines for packages which can use SSL certs.

But still we only want to add the missing bits *once* to NSS not in multiple places.

I am confused by the difference between PEM and PKCS#12 handling... for PEM we have nss-pem but NSS has native support for importing PKCS#12 files -- and can presumably import them with CKA_TOKEN=CK_FALSE so that they are purely session objects,  not actually *stored*. Why the difference?

well, I'm talking about using PKCS#12 files to store private keys, that means encrypted private keys, so to use them you need to be able to decrypt them

and to decrypt you need to understand the encryption format

for PKCS#12 files there are to encryption formats (they differ in how the password is transformed to encryption and MAC key), NSS doesn't support the new format

and yes, fixing NSS is preferable

There are *plenty* of variants which we need to support. You haven't even touched on the OpenSSL bugs with the key derivation, and the fact that non-ASCII passphrases may need to be treated differently to account for that.

Here's an attempt at collecting the cases that need to be supported. My plan is to expand the existing Fedora packaging guidelines (for which NSS patches already exist, to load the right PKCS#11 tokens and accept RFC7512 PKCS#11 URIs), to cover these rules too. Feedback would be very much welcomed:

http://david.woodhou.se/draft-woodhouse-cert-best-practice.html

In comment #11 I've already mentioned my torture test suite which exercises a lot of the problematic use cases. We should try those with curl when built against NSS, and see what fails.

oh, yes, there are multitude of formats and encryption ciphers, not to mention non-standard but common or common buggy implementations that should be supported, but we need to start somewhere. And that somewhere is, I think

now, for a bit of a off-topic:

In the best practice document, I haven't noticed you writing about any configuration options of the PKCS#12 or PKCS#8 files except the bulk cipher and key derivation method, IOW, there's no mention of the HMAC used, salt size, iteration count or hash used for key derivation. For PBES2 all of that is variable (and some of it may actually be variable for PBES1 too, though my memory is fuzzy about that).

other, minor item, is that not only DSA above 1024 bit is undefined for TLS, it is in practice undefined completely for TLS 1.2 (yes, implementations do interoperate in specific configurations, but it's more of a good will on their part than result of some standard).

In general, I really like your approach and goal, feel free to contact me if you want to discuss it further (I'm also on Freenode on #fedora-security and #fedora-admin) or hit some roadblocks (I'm the head crypto QA on the RHEL side, so I may be able to poke the developers and maintainers in harder to avoid way :) ).

*** Bug 1410569 has been marked as a duplicate of this bug. ***

Since the PKCS#12 uses the same identifiers and the same options, the file options from this https://github.com/redhat-qe-security/keyfile-corpus are mostly applicable, even if basically all files there are PKCS#12 files.

python-exabgp-4.0.0-1.fc26 has been submitted as an update to Fedora 26. https://bodhi.fedoraproject.org/updates/FEDORA-2017-9aca13bcc7

This message is a reminder that Fedora 24 is nearing its end of life.
Approximately 2 (two) weeks from now Fedora will stop maintaining
and issuing updates for Fedora 24. It is Fedora's policy to close all
bug reports from releases that are no longer maintained. At that time
this bug will be closed as EOL if it remains open with a Fedora  'version'
of '24'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version'
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not
able to fix it before Fedora 24 is end of life. If you would still like
to see this bug fixed and are able to reproduce it against a later version
of Fedora, you are encouraged  change the 'version' to a later Fedora
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's
lifetime, sometimes those efforts are overtaken by events. Often a
more recent Fedora release includes newer upstream software that fixes
bugs or makes them obsolete.

Still not implemented.

This bug appears to have been reported against 'rawhide' during the Fedora 27 development cycle.
Changing version to '27'.

This message is a reminder that Fedora 27 is nearing its end of life.
On 2018-Nov-30  Fedora will stop maintaining and issuing updates for
Fedora 27. It is Fedora's policy to close all bug reports from releases
that are no longer maintained. At that time this bug will be closed as
EOL if it remains open with a Fedora  'version' of '27'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 27 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

This bug appears to have been reported against 'rawhide' during the Fedora 30 development cycle.
Changing version to '30.

This message is a reminder that Fedora 30 is nearing its end of life.
Fedora will stop maintaining and issuing updates for Fedora 30 on 2020-05-26.
It is Fedora's policy to close all bug reports from releases that are no longer
maintained. At that time this bug will be closed as EOL if it remains open with a
Fedora 'version' of '30'.

Package Maintainer: If you wish for this bug to remain open because you
plan to fix it in a currently maintained version, simply change the 'version' 
to a later Fedora version.

Thank you for reporting this issue and we are sorry that we were not 
able to fix it before Fedora 30 is end of life. If you would still like 
to see this bug fixed and are able to reproduce it against a later version 
of Fedora, you are encouraged  change the 'version' to a later Fedora 
version prior this bug is closed as described in the policy above.

Although we aim to fix as many bugs as possible during every release's 
lifetime, sometimes those efforts are overtaken by events. Often a 
more recent Fedora release includes newer upstream software that fixes 
bugs or makes them obsolete.

Fedora 30 changed to end-of-life (EOL) status on 2020-05-26. Fedora 30 is
no longer maintained, which means that it will not receive any further
security or bug fix updates. As a result we are closing this bug.

If you can reproduce this bug against a currently maintained version of
Fedora please feel free to reopen this bug against that version. If you
are unable to reopen this bug, please file a new report against the
current release. If you experience problems, please add a comment to this
bug.

Thank you for reporting this bug and we are sorry it could not be fixed.

I am afraid this is WONTFIX.  I do not have time to work on this myself and nss-pem does not have any other contributors these days.  Feel free to reopen with link to an upstream pull request that implements it.