openssl update: default key length reduced to 1024

padeen · 10-15-2014, 07:37 PM

The openssl update today (Oct 15) has changed the openssl.cnf file:

Code:

--- openssl.cnf 2014-08-29 22:14:23.386912705 +0800
+++ openssl.cnf.new     2014-10-16 01:21:04.000000000 +0800
@@ -103,8 +103,7 @@
 ####################################################################
 [ req ]
-#default_bits          = 1024
-default_bits           = 2048
+default_bits           = 1024

I'm hesitant to do this, I want longer keys. I did read the security fix and this is not mentioned specifically, but I suspect it may be related to the buffer overflow or miscrafted packets fixes.

What are the implications of keeping my default key length at 2048 bits?

sag47 · 10-15-2014, 11:27 PM

1024 bits is not considered a high enough bit depth to be secure. Several certificate authorities mandate a minimum of 2048-bits. I am highly disturbed by this change.

http://www.thawte.com/resources/2048-bit-compliance/
https://blogs.comodo.com/e-commerce/...-dec31st-free/
http://www.symantec.com/page.jsp?id=...-migration-faq

I could link you more but instead simply google "minimum bit certificate". You'll be provided with plenty more examples.

ponce · 10-16-2014, 12:01 AM

(I can be wrong as I just woke up, but) that setting in openssl.cnf is the default as provided by upstream, and it hasn't changed with the last update.

maybe you should refer to the openssl fellas for some safer defaults: here, I got the habit to specify 4096 bits (on the command line or using gnomint) for my self-generated ssl keys...

astrogeek · 10-16-2014, 12:08 AM

**** UPDATE: This is now covered much better in another LQ thread, here.

Could the OP's concern be related to this? (Link removed, see above thread)

Twilio is advising...

Quote:

We are urging all customers to disable SSLv3 on hosts interacting with the Twilio service as soon as possible and upgrade to use Transport Layer Service (TLS).

Owing to many clients and servers with which Twilio interacts currently do not support TLS, we have not immediately turned off SSLv3, but are providing a mitigation path for SSLv3 as defined below.

I just saw this in my email and have not investigated yet.

sag47 · 10-16-2014, 03:44 AM

Quote:

Originally Posted by astrogeek

**** UPDATE: This is now covered much better in another LQ thread, here.

I don't believe this non-sane default (1024bit keys) and that vulnerability (POODLE) have anything to do with each other.

GazL · 10-16-2014, 03:57 AM

Quote:

Originally Posted by sag47

1024 bits is not considered a high enough bit depth to be secure. Several certificate authorities mandate a minimum of 2048-bits. I am highly disturbed by this change.

It's not a change, so no need to be disturbed. Mine, which is unmodified, is already set that way prior to the Oct 15th update. If padeen's is set to 2048, then it is because he, or someone else responsible for that system has changed it at some point in the past.

Whether 1024 is a wise default to start with is another matter of course, but don't think that its been downgraded by this latest update, because it hasn't.

sag47 · 10-16-2014, 04:05 AM

Quote:

Originally Posted by GazL

Whether 1024 is a wise default to start with is another matter of course, but don't think that its been downgraded by this latest update, because it hasn't.

Ah fair enough, I didn't really look into the change much. Thanks for the update.

padeen · 10-16-2014, 06:14 AM

GazL is right, I did change this when I was generating some self-signed certs. Normally I make a comment and date when I change system defaults, I must have forgotten.

Sorry for the noise, although it may prompt anyone reading whether they want to keep the default or change it.

kikinovak · 10-16-2014, 09:30 AM

Quote:

Originally Posted by padeen

The openssl update today (Oct 15) has changed the openssl.cnf file:

Code:

--- openssl.cnf 2014-08-29 22:14:23.386912705 +0800
+++ openssl.cnf.new     2014-10-16 01:21:04.000000000 +0800
@@ -103,8 +103,7 @@
 ####################################################################
 [ req ]
-#default_bits          = 1024
-default_bits           = 2048
+default_bits           = 1024

I'm hesitant to do this, I want longer keys. I did read the security fix and this is not mentioned specifically, but I suspect it may be related to the buffer overflow or miscrafted packets fixes.

What are the implications of keeping my default key length at 2048 bits?

After today's update, I checked openssl.cnf on my public server, and I have the same thing:

Code:

default_bits = 1024

Should I 1. be worried ? 2. Leave that value as is ? 3. Change it ?

ponce · 10-16-2014, 10:54 AM

Quote:

Originally Posted by kikinovak

After today's update, I checked openssl.cnf on my public server, and I have the same thing:

Code:

default_bits = 1024

Should I 1. be worried ? 2. Leave that value as is ? 3. Change it ?

1. no.
2. it won't hurt.
3. if you like.

that value means that when you will generate openssl keys (for a ssl certificate) it will use that as the default number of bits for the key, but you can specify that number also at generation time: like I wrote above, I usually do that, and it's the common practice.

kikinovak · 10-16-2014, 11:22 AM

Quote:

Originally Posted by ponce

1. no.
2. it won't hurt.
3. if you like.

that value means that when you will generate openssl keys (for a ssl certificate) it will use that as the default number of bits for the key, but you can specify that number also at generation time: like I wrote above, I usually do that, and it's the common practice.

Thanks very much !