Bug 1062444 - certificate generation uses deprecated SHA-1 hash algorithm for signing
Summary: certificate generation uses deprecated SHA-1 hash algorithm for signing
Status: CLOSED ERRATA
Alias: None
Product: Fedora
Classification: Fedora
Component: crypto-utils
Version: rawhide
Hardware: Unspecified
OS: Unspecified
unspecified
unspecified
Target Milestone: ---
Assignee: Joe Orton
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords: FutureFeature
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2014-02-07 00:05 UTC by Peter Backes
Modified: 2014-09-23 04:23 UTC (History)
4 users (show)

(edit)
Clone Of:
(edit)
Last Closed: 2014-09-23 04:23:08 UTC


Attachments (Terms of Use)
patch to use SHA-2 hashes (3.84 KB, patch)
2014-08-29 23:15 UTC, Adam Williamson
no flags Details | Diff
patch to use SHA-2 hashes, v2: apply to CSR as well as self-signed cert creation on NSS path (5.09 KB, patch)
2014-08-30 00:49 UTC, Adam Williamson
no flags Details | Diff

Description Peter Backes 2014-02-07 00:05:27 UTC
Description of problem:
When you run genkey, you get a certificate with SHA-1 signature. SHA-1 is insecure and should not be used anymore according to NIST Special Publication 800-131A (http://csrc.nist.gov/publications/nistpubs/800-131A/sp800-131A.pdf) Use at least SHA256. See p. 14: "SHA-1 shall not be used for digital signature generation after December 31, 2013." Also, hash strength should match RSA strength. See http://www.keylength.com/

Version-Release number of selected component (if applicable):
crypto-utils-2.4.1-48.fc20.i686

How reproducible:
always

Steps to Reproduce:
1. genkey localhost.localdomain

Actual results:
you always get a certificate with SHA-1 signature

Expected results:
RSA <= 3072 bits yields SHA-256 signature
3072 < RSA <= 7680 bits yields SHA-384 signature
7680 < RSA yields SHA-512 signature

Comment 1 Peter Backes 2014-02-14 23:43:29 UTC
I disagree that this is a RFE. SHA-1 is broken and deprecated for signatures. In addition, using SHA-1 makes larger RSA key lengths quite pointless. Hence, this is a bug, IMO.

Comment 2 Peter Backes 2014-08-21 00:32:04 UTC
There you have it, it's soon going to cause real trouble:

https://groups.google.com/a/chromium.org/forum/#!msg/blink-dev/2-R4XziFc7A/YO0ZSrX_X4wJ

pls consider fixing this now.

Comment 3 Adam Williamson 2014-08-29 17:37:33 UTC
note that the older Makefile method in /etc/pki/tls/certs , which calls openssl , uses SHA-256, at least in Fedora 21 (I believe both tools inherit the defaults of their helper apps, 'certutil' for genkey and 'openssl' for Makefile).

Comment 4 Adam Williamson 2014-08-29 18:34:08 UTC
grr, actually crypto-utils uses its own 'keyutil' tool for some stuff, as well as calling certutil. i'm trying to work up a patch for this.

Comment 5 Elio Maldonado Batiz 2014-08-29 19:03:38 UTC
certutil -Z (for signature hash) is undocumented see
https://bugzilla.mozilla.org/show_bug.cgi?id=1058870
keyutil uses SHA1 but that can be changed. keyutil is a stripped down certutil like tool to support writing pem files. Hope this info helps you some.

Comment 6 Adam Williamson 2014-08-29 20:24:57 UTC
OK, I think I have a handle on this now, testing patches.

Note that kaie has a patch in review to change the default of NSS's 'certutil' tool to SHA-256:

https://bugzilla.mozilla.org/show_bug.cgi?id=1058933

when that change goes into nss, genkey's 'nss' path would get fixed for free. The 'openssl' path still needs fixing in genkey. I think I'll still include a genkey-level fix for the 'nss' path in my submission, though, so this doesn't have to wait for a new nss release or package to get fixed.

Comment 7 Adam Williamson 2014-08-29 23:15:21 UTC
Created attachment 932826 [details]
patch to use SHA-2 hashes

This is a git-formatted patch (against the package git master branch) to make genkey use SHA-2 hash functions by default: SHA-512 if the key length is > 7680 bits, SHA-384 if the key length is > 3072 bits, and SHA-256 otherwise. It has a fairly detailed git commit message and in-line comments in the source files touched. I've tested it on both paths, with an F20 scratch build, generating 2048-bit and 4096-bit keys and ensuring the appropriate functions are used in the generated certificates.

Comment 8 Adam Williamson 2014-08-30 00:16:56 UTC
Hum, that version only handles generation of self-signed certs, not CSRs, on the NSS path. I'm testing a new version which handles both now (by creating a helper function for figuring out the appropriate hash function and calling it after setting the key length).

Comment 9 Adam Williamson 2014-08-30 00:49:44 UTC
Created attachment 932828 [details]
patch to use SHA-2 hashes, v2: apply to CSR as well as self-signed cert creation on NSS path

Here's an updated version of the patch, which should be more comprehensive. There would be a few different ways to do this, I'm not really used to the somewhat old-fashioned style of genkey.pl so I wasn't sure which would be considered cleanest. you *could* use only a single getHashForKeyLength() function if you really crowbarred it in somewhere (top of getRandomDataWindow() , for instance) but that seemed ugly. I'm not entirely sure if it's best practice to only set the default value of $hashalg once (at the top of main, when first asserting the variable), or set it both there and in the getHashForKeyLength() function as well, as I do in this version. please do review carefully, I'm only the QA monkey :) again, I've tested this on both paths with both 2048 and 4096 bit keys (not 8192, life's too short, but I did test that once with an earlier version just to make sure 'SHA512' does actually work, and it was fine).

Comment 10 Peter Backes 2014-08-30 01:53:14 UTC
Looks fine to me.

Minor note, I forgot to mention that RSA = 2048 with SHA-224 is still deemed "acceptable" by NIST, so you can add this one, if you like.

Comment 11 Adam Williamson 2014-08-30 10:37:12 UTC
Thanks.

FWIW, saying this is going to cause 'real problems' is stretching things a bit. Well, I can see one very specific corner case, but the common cases, no. The two things that wind up with SHA-1 hashes are:

1) self-signed certificates
2) CSRs

So far as I can see both the practical and theoretical impact of 1) for server certificates is "very close to nothing". self-signed certificates are already treated as untrusted by browsers in any case - the browser experience when visiting a site with a self-signed cert with an SHA-1 hash is probably going to be exactly the same as the browser experience when visiting a site with a self-signed cert with an SHA-2 hash. in theoretical security terms, with my in-depth wikipedia-gleaned understanding of public-key cryptography, I believe that given what a self-signed server certificate *is*, it doesn't matter much what the hashing mechanism is. running a hash collision attack on a self-signed server certificate gains you nothing at all.

Ditto for 2). I dug out the explanation of why CSRs are signed at all from the RFC (OK, OK, from the RFC by way of wikipedia...): "Note 2 - The signature on the certification request prevents an
   entity from requesting a certificate with another party's public key.
   Such an attack would give the entity the minor ability to pretend to
   be the originator of any message signed by the other party.  This
   attack is significant only if the entity does not know the message
   being signed and the signed part of the message does not identify the
   signer.  The entity would still not be able to decrypt messages
   intended for the other party, of course." , from 
https://tools.ietf.org/html/rfc2986#page-4 . So again, compromising the signature on a CSR really doesn't get you anywhere very significant. I don't think it's an 'attack' vector that's going to cause anyone any lost sleep.

Now, I think there is one unusual case where there could just arguably be a 'real' impact. genkey has a mode for generating a CA certificate - genkey --makeca . It's supposed to be used for setting up a private CA. This goes through the affected functions and so generates a CA certificate that uses SHA-1 hashing. Such a cert *is* potentially vulnerable to hash collision attacks. It still seems fairly unlikely that all the requisite elements for such an attack to be viable would be in place in any situation where someone had set up a private CA using genkey, but it's theoretically possible, I guess. (Also note that it's not like SHA-1 is known to be practically vulnerable to attack right now, it's only supposed to be really *gone* by 2017, and genkey's default lifetime for a CA cert is only two years).

Comment 12 Peter Backes 2014-08-30 15:05:01 UTC
By "real problems" I meant that a popular browser will soon begin to nag users about it (and rightly so).

We both don't know the exact impact of the hash algorithm. Things go wrong in places that one overlooks and doesn't expect to be a problem. Too much time has been wasted in the past, and is still wasted, by discussing whether things are still practically secure despite of the allegedly merely theoretical possibility of a security problem. I can only recommend not to that, but simply to fix the problem. Given enough effort, time and money, most security issues, however remote and theoretical, can be exploited (cf. http://slashdot.org/story/14/08/26/2233257/project-zero-exploits-unexploitable-glibc-bug). We need to fix those issues, not speculate about their exploitability. That should be the the key insight of the Snowden age.

Comment 13 Adam Williamson 2014-08-30 17:40:39 UTC
"By "real problems" I meant that a popular browser will soon begin to nag users about it (and rightly so)."

My point is that browsers already nag you anyway if you're using a self-signed certificate, and that's the only kind of certificate genkey produces. It's not like CAs are signing other people's certificates using genkey, it's not even capable of that.

Comment 14 Peter Backes 2014-08-30 20:16:04 UTC
Yes, but it's a different nag screen.

I have to finish a paper for VMCAI and I want to waste my braincells on that rather than an attempt to refute your conclusion that there's no problem with the weak hash for the relevant use cases.

Comment 16 Joe Orton 2014-09-02 15:48:06 UTC
Thanks for the patch Adam!

Comment 18 Fedora Update System 2014-09-02 16:32:03 UTC
crypto-utils-2.4.1-56.fc21 has been submitted as an update for Fedora 21.
https://admin.fedoraproject.org/updates/crypto-utils-2.4.1-56.fc21

Comment 19 Fedora Update System 2014-09-06 01:01:14 UTC
Package crypto-utils-2.4.1-56.fc21:
* should fix your issue,
* was pushed to the Fedora 21 testing repository,
* should be available at your local mirror within two days.
Update it with:
# su -c 'yum update --enablerepo=updates-testing crypto-utils-2.4.1-56.fc21'
as soon as you are able to.
Please go to the following url:
https://admin.fedoraproject.org/updates/FEDORA-2014-10225/crypto-utils-2.4.1-56.fc21
then log in and leave karma (feedback).

Comment 20 Fedora Update System 2014-09-23 04:23:08 UTC
crypto-utils-2.4.1-56.fc21 has been pushed to the Fedora 21 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.