[openssl.org #2753] Patch: let application explicitly seed RNG on Unix
I sent email about this about a week ago. The attached patch allows
applications to explicitly seed the RNG before first use on Unix, so
that it does not automatically seed itself via RAND_poll().
This is beneficial for three reasons:
1) On some platforms, the Unix RAND_poll() implementation is
pretty dodgy. For example, it can fall back to using just
getpid() etc on very old platforms; worse, on OpenBSD, it
is #ifdeffed in such a way that all the entropy comes
from libc arc4random() (there may be a FIPS issue here,
since I do not think the Approved DRBG is really supposed
to be keyed in this manner).
2) RAND_poll() pulls a lot of bits from /dev/urandom. Some
applications (like OpenSSH) repeatedly re-initialize the
library (for example, by re-execing themselves) which causes
severe depletion of the system entropy pool. This change
lets such applications avoid that problem by explicitly
passing entropy across the library re-init, then feeding it
back in via RAND_seed(), RAND_add(), etc.
3) It simplifies the md_rand code slightly by removing the
initialized variable and logic which surrounds it. Now
RAND_poll() is simply called if there is not enough entropy
available, and not called if there is enough entropy.
The diff is against the in-tree OpenSSL in NetBSD. Hopefully it will
apply cleanly to the head and branch OpenSSL sources.
--
Thor Lancelot Simon t...@panix.com
The liberties...lose much of their value whenever those who have greater
private means are permitted to use their advantages to control the course
of public debate. -John Rawls
? openssl-rand.diff
Index: crypto/rand/md_rand.c
===
RCS file: /cvsroot/src/crypto/external/bsd/openssl/dist/crypto/rand/md_rand.c,v
retrieving revision 1.1.1.3
diff -u -r1.1.1.3 md_rand.c
--- crypto/rand/md_rand.c 5 Jun 2011 14:59:27 - 1.1.1.3
+++ crypto/rand/md_rand.c 4 Mar 2012 17:57:30 -
@@ -141,7 +141,6 @@
static unsigned char md[MD_DIGEST_LENGTH];
static long md_count[2]={0,0};
static double entropy=0;
-static int initialized=0;
static unsigned int crypto_lock_rand = 0; /* may be set only when a thread
* holds CRYPTO_LOCK_RAND
@@ -187,7 +186,6 @@
md_count[0]=0;
md_count[1]=0;
entropy=0;
- initialized=0;
}
static void ssleay_rand_add(const void *buf, int num, double add)
@@ -389,18 +387,15 @@
CRYPTO_w_unlock(CRYPTO_LOCK_RAND2);
crypto_lock_rand = 1;
- if (!initialized)
- {
- RAND_poll();
- initialized = 1;
- }
-
if (!stirred_pool)
do_stir_pool = 1;
ok = (entropy = ENTROPY_NEEDED);
if (!ok)
{
+
+ RAND_poll();
+
/* If the PRNG state is not yet unpredictable, then seeing
* the PRNG output may help attackers to determine the new
* state; thus we have to decrease the entropy estimate.
@@ -571,11 +566,10 @@
CRYPTO_w_unlock(CRYPTO_LOCK_RAND2);
crypto_lock_rand = 1;
}
-
- if (!initialized)
+
+ if (entropy ENTROPY_NEEDED)
{
RAND_poll();
- initialized = 1;
}
ret = entropy = ENTROPY_NEEDED;
Index: crypto/rand/rand_unix.c
===
RCS file:
/cvsroot/src/crypto/external/bsd/openssl/dist/crypto/rand/rand_unix.c,v
retrieving revision 1.2
diff -u -r1.2 rand_unix.c
--- crypto/rand/rand_unix.c 19 Jul 2009 23:30:41 - 1.2
+++ crypto/rand/rand_unix.c 4 Mar 2012 17:57:30 -
@@ -182,6 +182,16 @@
u_int32_t rnd = 0, i;
unsigned char buf[ENTROPY_NEEDED];
+ /*
+* XXX is this really a good idea? It has the seemingly
+* XXX very undesirable eventual result of keying the CTR_DRBG
+* XXX generator exclusively with key material produced by
+* XXX the libc arc4random(). It also guarantees that even
+* XXX if the generator tries to use RAND_poll() to rekey
+* XXX itself after a call to fork() etc, it will end up with
+* XXX the same state, since the libc arc4 state will be the same
+* XXX unless explicitly updated by the application.
+*/
for (i = 0; i sizeof(buf); i++) {
if (i % 4 == 0)
rnd = arc4random();
[openssl.org #2754] Ugly interaction of (openssl x509)'s option -x509toreq with -outform/-text/-noout
About year ago, the apps/x509.c has been patched not to ignore -keyform during -x509toreq operation. IMHO it's proper time to patch not to ignore other options as well. All following text is related to openssl req -x509toreq call. Current behavior: 1. -outform is ignored, PEM format used all the times 2. output contain text representation of created request all the time, despite of '-text' option is used or not 3a. -text -x509toreq sequence results to following output sequence: [text representation of source x509 certificate] [text representation of resulting request] [resulting request in PEM format] 3b. -x509toreq -text sequence results to following output sequence: [text representation of resulting request] [resulting request in PEM format] [text representation of source x509 certificate] 3c. -x509toreq -text or -text -x509toreq sequences combined with -noout in any position results to following output sequence: [text representation of source x509 certificate] --- Proposed behavior: 1. honor the -outform 2,3. print text representation of resulting request when -text requested only, then print resulting request in DER or PEM format unless -noout specified, don't print text representation of source x509 certificate in -x509toreq mode at all. It results to following output sequence: IF -textTHEN [text representation of resulting request] IF ! -noout THEN [resulting request in $( outform) format] I wish [1] need no more explanation. According to 23 - I assume the current behavior is not intentional. I wish the proposed behavior is more consistent with x509 app behavior in non x509toreq mode as well as behavior of other apps. Patch is attached. Best regards Dan Lukes patch-DAN-apps::x509.c Description: application/unregisterd-mime-type-to-avoid-ie-mime-sniffing
Re: Patch sent to RT never got there?
On Sun, 2012-03-04 at 14:16 -0500, Thor Lancelot Simon wrote: I sent a patch to RT a few hours ago. I didn't get an ack of any kind and don't see it in the tracker -- any way to tell where it went? The message-ID was 20120304175840.ga12...@panix.com . The RT queue is moderated. So you just need to wait till the moderator looks at it. -- Tomas Mraz No matter how far down the wrong road you've gone, turn back. Turkish proverb __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: Limiting EC curves in ClientHello
On Thu, Mar 1, 2012 at 11:28 PM, Erik Tkal et...@me.com wrote: So then the question is will this be addressed in 1.0.1 or later? Probably a bit later. Bodo
[openssl.org #2746] Bugfix for ASN.1 parser in OpenSSL 0.9.8 and 1.0
[steve - Fri Mar 02 03:57:59 2012]: [to...@tutus.se - Thu Mar 01 15:44:36 2012]: Hi, In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1 parser that if one has length data such as 84 00 00 00 00 at the end of a block to be parsed, it will give header too long error even though the ASN.1 is valid. The last time I looked that wasn't a valid encoding. The length must be expressed in the minimum number of octets possible, that applies to BER as well as DER. Hmm... must have confused it with something else. That *is* legal. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2755] [PATCH] DTLS does not lower MTU after retransmissions
The DTLS implementation does not lower the assumed MTU after unsuccessful retransmissions, which results in a failing handshake in case fragmentation is necessary. With this patch the MTU is reduced to a safe value of 576 - 20 - 8 for IPv4 and 1280 - 40 - 8 for IPv6, respectively, after 2 retransmissions. Best regards Robin dtls-timer-mtu-bug-1.0.0.patch Description: Binary data dtls-timer-mtu-bug-1.0.1.patch Description: Binary data
Re: [openssl-dev] [openssl.org #2746] Bugfix for ASN.1 parser in OpenSSL 0.9.8 and 1.0
Le 05/03/2012 15:14, Stephen Henson via RT a écrit : [steve - Fri Mar 02 03:57:59 2012]: [to...@tutus.se - Thu Mar 01 15:44:36 2012]: Hi, In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1 parser that if one has length data such as 84 00 00 00 00 at the end of a block to be parsed, it will give header too long error even though the ASN.1 is valid. The last time I looked that wasn't a valid encoding. The length must be expressed in the minimum number of octets possible, that applies to BER as well as DER. Hmm... must have confused it with something else. That *is* legal. No, you were (partly) right. This is legal BER, not DER. -- Erwann ABALEA - parturiophone: enceinte acoustique __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl-dev] [openssl.org #2746] Bugfix for ASN.1 parser in OpenSSL 0.9.8 and 1.0
Le 05/03/2012 15:14, Stephen Henson via RT a écrit : [steve - Fri Mar 02 03:57:59 2012]: [to...@tutus.se - Thu Mar 01 15:44:36 2012]: Hi, In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1 parser that if one has length data such as 84 00 00 00 00 at the end of a block to be parsed, it will give header too long error even though the ASN.1 is valid. The last time I looked that wasn't a valid encoding. The length must be expressed in the minimum number of octets possible, that applies to BER as well as DER. Hmm... must have confused it with something else. That *is* legal. No, you were (partly) right. This is legal BER, not DER. -- Erwann ABALEA - parturiophone: enceinte acoustique __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2746] Bugfix for ASN.1 parser in OpenSSL 0.9.8 and 1.0
Am 5. März 2012 15:14 schrieb Stephen Henson via RT r...@openssl.org: [steve - Fri Mar 02 03:57:59 2012]: [to...@tutus.se - Thu Mar 01 15:44:36 2012]: Hi, In at least OpenSSL 0.9.8s and 1.0.1-beta1 there is a bug in the ASN.1 parser that if one has length data such as 84 00 00 00 00 at the end of a block to be parsed, it will give header too long error even though the ASN.1 is valid. The last time I looked that wasn't a valid encoding. The length must be expressed in the minimum number of octets possible, that applies to BER as well as DER. Hmm... must have confused it with something else. That *is* legal. I'm sorry, but I disagree - this is not a legal encoding, even not at the end of a constructed indefinite length encoding. The first 0x00 cannot belong to a multiple length encoding because section 8.1.3.5 of X.690 states that bit 8 would have to be 1 in that case. So this must be a single octet length. This is why it even would not be valid at the end of an indefinite constructed value. 84 00 00 00 (three zero octets) would be a valid encoding (context-specific tag 0, zero length followed by and END OF CONTENTS), e.g. as in 30 80 84 00 00 00, but four zeroes can not lead to a valid encoding in this case. In any situation, only an odd number of zeroes could lead to a valid encoding. Best regards, Martin Bosslet __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2746] Bugfix for ASN.1 parser in OpenSSL 0.9.8 and 1.0
84 00 00 00 (three zero octets) would be a valid encoding (context-specific tag 0, zero length followed by and END OF CONTENTS), Sorry, this has to read context-specific tag 4 of course. Best regards, Martin Bosslet __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
[openssl.org #2594] Problem with X509 path loop detection - PATCH
[nick.le...@usa.g4s.com - Mon Sep 12 10:31:50 2011]: Thank you for looking at the patch and reporting the problem with it. I apologise that I did not test it properly. The path loop test in the patch should of course be first whether the issuer is in the chain and only if it is then whether it is lower than the cert x i.e. The self signed check is clearly broken and I've committed this fix: http://cvs.openssl.org/chngview?cn=22200 I'm not sure why we need to do anything more than that. As I see it if the candidate issuer certificate is already in the chain we should always reject it as we never want to include duplicate certificates in the chain. Steve. -- Dr Stephen N. Henson. OpenSSL project core developer. Commercial tech support now available see: http://www.openssl.org __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
Re: [openssl.org #2746] Bugfix for ASN.1 parser in OpenSSL 0.9.8 and 1.0
Am 5. März 2012 16:45 schrieb Martin Boßlet martin.boss...@googlemail.com: I'm sorry, but I disagree - this is not a legal encoding, even not at the end of a constructed indefinite length encoding. The first 0x00 cannot belong to a multiple length encoding because section 8.1.3.5 of X.690 states that bit 8 would have to be 1 in that case. So this must be a single octet length. This is why it even would not be valid at the end of an indefinite constructed value. 84 00 00 00 (three zero octets) would be a valid encoding (context-specific tag 0, zero length followed by and END OF CONTENTS), e.g. as in 30 80 84 00 00 00, but four zeroes can not lead to a valid encoding in this case. In any situation, only an odd number of zeroes could lead to a valid encoding. I overlooked length in valid length encoding and read valid encoding instead. In that case it's a valid length encoding alright. I apologize for the noise. Best regards, Martin __ OpenSSL Project http://www.openssl.org Development Mailing List openssl-dev@openssl.org Automated List Manager majord...@openssl.org
