|Summary:||ssl-cert.eclass should use more secure defaults for crypto functions / keylengths|
|Product:||Gentoo Linux||Reporter:||Roman Žilka <roman.zilka>|
|Component:||Eclasses||Assignee:||Max Kalika (RETIRED) <max>|
|Severity:||minor||CC:||base-system, bertrand, eras|
|Package list:||Runtime testing required:||---|
Description Roman Žilka 2013-02-14 00:13:05 UTC
Many crucial applications - Apache, above all - make use of the ssl-cert eclass. I noticed it defaults to generating 1024b RSA which is not top-notch security nowadays. I think the eclass should be revised with today's security demands in mind. If nothing, the hardened profile(s) should get an upgrade. For "openssl x509 -req" there could be an explicit call for a SHA-2 hash. For "openssl genrsa" keylength could be set to 2048/4096 b (the latter for hardened). Etc.(?) Reproducible: Always
Comment 1 Roman Žilka 2013-02-14 00:17:24 UTC
Umm, s/^Many/A few/ :)
Comment 2 Jeroen Roovers 2013-02-14 04:23:13 UTC
# @MAINTAINER: # @AUTHOR: # Max Kalika <email@example.com> Someone should fix that.
Comment 3 Eray Aslan 2013-02-14 15:35:22 UTC
For people using self-signed certs, 1024 bit rsa is pretty strong at 80 bits. Let's not follow the herd and install 2048 (or higher) bits by default. A case can be made perhaps for 1280 bits which has about 89 bit security and does not incur the performance penalty of 2048 bit rsa (which has a gnfs factoring cost of 2^110). Not everything is a desktop. If you need a different security model, just generate your own certs. My vote would be WONTFIX although I believe 1280 bits would be a reasonable choice as well.
Comment 4 Roman Žilka 2013-02-14 19:04:04 UTC
You're right after all, 1024b RSA and SHA1 (currently used in the eclass IIRC) are safe for the time being. If the default profiles are to stick with these, so be it. But for hardened this could be bumped today - hardened shouldn't restrain itself with handheld devices for the common user and the common app (if that's what you meant by not everything being desktop). 1024xSHA1 means living on the edge. Unexpected stuff in cryptanalysis happens; upgrading certs could take admins days to years. ... Yeah, perhaps even the default profiles... It's true that not everything is a desktop, but most things do are a desktop and the minority of admins can still make the simpler certs manually.
Comment 5 Roman Žilka 2013-02-14 19:09:51 UTC
But then, we're talking self-signed certs here, as you fittingly put. Well, I'm giving this a "minor", quitting any more arguments and leaving it to your decision.
Comment 6 SpanKY 2013-02-19 06:49:28 UTC
as long as the certs only get used for self signing, i don't see any value in increasing things the certs also include values which don't make sense to try and get publicly signed ("localhost", "For Testing Purposes Only", etc...). that means people will have to generate their own cert from scratch (and thus it'll be up to them to pick the right bit size). i don't think they'll look at the existing cert as any sort of input for picking values. if people don't have contradictory thoughts, i'll WONTFIX this.
Comment 7 Toralf Förster 2015-11-01 14:40:22 UTC
(In reply to SpanKY from comment #6) > as long as the certs only get used for self signing, i don't see any value > in increasing things > If there's use case (for whatever reason) to trust a self-signed certificate then users should get a sufficient level of security IMO. B/c there otherwise there would be no special reason to even use 1024. 768 bits would be still enough too for testing purpose only. So what's about at least to mention this topic by putting a comment line like "#SSL_BITS=4096" in make.conf ?
Comment 8 SpanKY 2015-11-07 19:03:45 UTC
(In reply to Toralf Förster from comment #7) do you have an actual use case where the trust is required ? i don't mean setting up a test apache instance and verifying things on your LAN. if you want the certs to be used beyond your two systems, you need to generate your own.