Bug#639744: [Pkg-openssl-devel] Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA

2011-09-08 Thread Raphael Geissert 
On Wednesday 07 September 2011 22:06:55 Raphael Geissert wrote:
 On Wednesday 07 September 2011 10:57:51 Raphael Geissert wrote:
  On Monday 05 September 2011 14:55:50 Kurt Roeckx wrote:
   So you're basicly saying that X509_verify_cert() should give an
   error in case it finds DigiNotar somewhere in the chain?
   
   I'm not opposed to such a change, but would like to see a better
   option in the future.
  
  Yes. I will try to spend some time with a debugger later today to find
  the right place to implement such check. Or do you have any hint? (the
  cn validation functions didn't seem to be executed in one case I tried)
 
 Attached is the first version of patch against the 1.0.0 series that does
 that. I implemented it in check_name_constraints, but given that 0.9.8
 doesn't have support for name constraints I might as well move it to a
 separate function. I've tested it on the rogue *.google.com cert  with
 verify(1) and a few others with different clients (tried the urls
 mentioned on the bug report, of which only ingcommercialbanking still uses
 a DigiNotar cert.)
 Attached are a bundle of the certs needed to verify(1) the rogue google
 cert, and the rogue cert itself. Perhaps they could be included in the
 test suite.

I somehow ended up adding an O instead of a 0 in the exported patch for 1.0.0. 
Attached are the fixed 1.0.0 patch (as v2, to avoid confusions) and the 
previous patch for 0.9.8.

 The patch for 0.9.8 is also attached, but I haven't tested it yet. It was
 made based on squeeze's openssl and it seems to apply fine to lenny's
 openssl (just a few lines of difference.)
 
 Kurt, what do you think? would upstream be interested in the patch, or at
 least in reviewing it?

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Description: make X509_verify_cert indicate that any certificate whose
 name contains DigiNotar is revoked.
Origin: vendor
Forwarded: no
Last-Update: 2011-09-07
Bug: http://bugs.debian.org/639744

diff -urpN openssl-0.9.8o-4squeeze1.orig/crypto/x509/x509_vfy.c openssl-0.9.8o-4squeeze1/crypto/x509/x509_vfy.c
--- openssl-0.9.8o-4squeeze1.orig/crypto/x509/x509_vfy.c	2009-06-26 06:34:21.0 -0500
+++ openssl-0.9.8o-4squeeze1/crypto/x509/x509_vfy.c	2011-09-07 21:23:58.0 -0500
@@ -78,6 +78,7 @@ static int check_trust(X509_STORE_CTX *c
 static int check_revocation(X509_STORE_CTX *ctx);
 static int check_cert(X509_STORE_CTX *ctx);
 static int check_policy(X509_STORE_CTX *ctx);
+static int check_ca_blacklist(X509_STORE_CTX *ctx);
 static int internal_verify(X509_STORE_CTX *ctx);
 const char X509_version[]=X.509 OPENSSL_VERSION_PTEXT;
 
@@ -312,6 +313,9 @@ int X509_verify_cert(X509_STORE_CTX *ctx
 		ok=internal_verify(ctx);
 	if(!ok) goto end;
 
+	ok = check_ca_blacklist(ctx);
+	if(!ok) goto end;
+
 #ifndef OPENSSL_NO_RFC3779
 	/* RFC 3779 path validation, now that CRL check has been done */
 	ok = v3_asid_validate_path(ctx);
@@ -661,6 +665,29 @@ static int check_crl_time(X509_STORE_CTX
 	return 1;
 	}
 
+static int check_ca_blacklist(X509_STORE_CTX *ctx)
+	{
+	X509 *x;
+	int i;
+	/* Check all certificates against the blacklist */
+	for (i = sk_X509_num(ctx-chain) - 1; i = 0; i--)
+		{
+		x = sk_X509_value(ctx-chain, i);
+		/* Mark DigiNotar certificates as revoked, no matter
+		 * where in the chain they are. 
+		 */
+		if (x-name  strstr(x-name, DigiNotar))
+			{
+			ctx-error = X509_V_ERR_CERT_REVOKED;
+			ctx-error_depth = i;
+			ctx-current_cert = x;
+			if (!ctx-verify_cb(0,ctx))
+return 0;
+			}
+		}
+	return 1;
+	}
+
 /* Lookup CRLs from the supplied list. Look for matching isser name
  * and validity. If we can't find a valid CRL return the last one
  * with matching name. This gives more meaningful error codes. Otherwise
Description: make X509_verify_cert indicate that any certificate whose
 name contains DigiNotar is revoked.
Origin: vendor
Forwarded: no
Last-Update: 2011-09-07
Bug: http://bugs.debian.org/639744

diff --git a/crypto/x509/x509_vfy.c.orig b/crypto/x509/x509_vfy.c
index bd6695d..1aaf5d3 100644
--- a/crypto/x509/x509_vfy.c.orig
+++ b/crypto/x509/x509_vfy.c
@@ -617,6 +617,17 @@ static int check_name_constraints(X509_STORE_CTX *ctx)
 	for (i = sk_X509_num(ctx-chain) - 1; i = 0; i--)
 		{
 		x = sk_X509_value(ctx-chain, i);
+		/* Mark DigiNotar certificates as revoked, no matter
+		 * where in the chain they are.
+		 */
+		if (x-name  strstr(x-name, DigiNotar))
+			{
+			ctx-error = X509_V_ERR_CERT_REVOKED;
+			ctx-error_depth = i;
+			ctx-current_cert = x;
+			if (!ctx-verify_cb(0,ctx))
+return 0;
+			}
 		/* Ignore self issued certs unless last in chain */
 		if (i  (x-ex_flags  EXFLAG_SI))
 			continue;

Bug#639744: [Pkg-openssl-devel] Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA

2011-09-08 Thread Kurt Roeckx 
On Wed, Sep 07, 2011 at 10:06:55PM -0500, Raphael Geissert wrote:
 On Wednesday 07 September 2011 10:57:51 Raphael Geissert wrote:
  On Monday 05 September 2011 14:55:50 Kurt Roeckx wrote:
   So you're basicly saying that X509_verify_cert() should give an
   error in case it finds DigiNotar somewhere in the chain?
   
   I'm not opposed to such a change, but would like to see a better
   option in the future.
  
  Yes. I will try to spend some time with a debugger later today to find the
  right place to implement such check. Or do you have any hint? (the cn
  validation functions didn't seem to be executed in one case I tried)
 
 Attached is the first version of patch against the 1.0.0 series that does 
 that. 
 I implemented it in check_name_constraints, but given that 0.9.8 doesn't have 
 support for name constraints I might as well move it to a separate function.
 I've tested it on the rogue *.google.com cert  with verify(1) and a few 
 others 
 with different clients (tried the urls mentioned on the bug report, of which 
 only ingcommercialbanking still uses a DigiNotar cert.)
 Attached are a bundle of the certs needed to verify(1) the rogue google cert, 
 and the rogue cert itself. Perhaps they could be included in the test suite.
 
 The patch for 0.9.8 is also attached, but I haven't tested it yet. It was 
 made 
 based on squeeze's openssl and it seems to apply fine to lenny's openssl 
 (just 
 a few lines of difference.)

I wonder why you don't use the same patch for both.  I think the
check_name_constraints() actually tries to test something else,
like that it's a well-formed name or something.  So the new function
makes more sense to me.

Looking at the patch, it seems to make sense to me.

 Kurt, what do you think? would upstream be interested in the patch, or at 
 least in reviewing it?

I can always try and ask them.


Kurt




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#639744: [Pkg-openssl-devel] Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA

2011-09-08 Thread Raphael Geissert 
On Thursday 08 September 2011 16:57:56 Kurt Roeckx wrote:
 On Wed, Sep 07, 2011 at 10:06:55PM -0500, Raphael Geissert wrote:
  The patch for 0.9.8 is also attached, but I haven't tested it yet. It was
  made based on squeeze's openssl and it seems to apply fine to lenny's
  openssl (just a few lines of difference.)
 
 I wonder why you don't use the same patch for both.  I think the
 check_name_constraints() actually tries to test something else,
 like that it's a well-formed name or something.  So the new function
 makes more sense to me.

Yes, I rewrote the patch for 1.0.0 after my last message but it was pending a 
rebuild and re-test. I've attached it now.

I had the chance of testing the 098.v1 patch on squeeze and it passed all my 
tests. I haven't tested it on lenny yet, since the build system seems to be 
tricky and keeps modifying files even on debian/rules clean.

  Kurt, what do you think? would upstream be interested in the patch, or at
  least in reviewing it?
 
 I can always try and ask them.

It'd be great if you handled that part.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net
Description: make X509_verify_cert indicate that any certificate whose
 name contains DigiNotar is revoked.
Origin: vendor
Forwarded: no
Last-Update: 2011-09-08
Bug: http://bugs.debian.org/639744

Index: openssl-1.0.0d/crypto/x509/x509_vfy.c
===
--- openssl-1.0.0d.orig/crypto/x509/x509_vfy.c
+++ openssl-1.0.0d/crypto/x509/x509_vfy.c
@@ -117,6 +117,7 @@ static int check_trust(X509_STORE_CTX *c
 static int check_revocation(X509_STORE_CTX *ctx);
 static int check_cert(X509_STORE_CTX *ctx);
 static int check_policy(X509_STORE_CTX *ctx);
+static int check_ca_blacklist(X509_STORE_CTX *ctx);
 
 static int get_crl_score(X509_STORE_CTX *ctx, X509 **pissuer,
 			unsigned int *preasons,
@@ -374,6 +375,9 @@ int X509_verify_cert(X509_STORE_CTX *ctx
 		ok=internal_verify(ctx);
 	if(!ok) goto end;
 
+	ok = check_ca_blacklist(ctx);
+	if(!ok) goto end;
+
 #ifndef OPENSSL_NO_RFC3779
 	/* RFC 3779 path validation, now that CRL check has been done */
 	ok = v3_asid_validate_path(ctx);
@@ -820,6 +824,29 @@ static int check_crl_time(X509_STORE_CTX
 	return 1;
 	}
 
+static int check_ca_blacklist(X509_STORE_CTX *ctx)
+	{
+	X509 *x;
+	int i;
+	/* Check all certificates against the blacklist */
+	for (i = sk_X509_num(ctx-chain) - 1; i = 0; i--)
+		{
+		x = sk_X509_value(ctx-chain, i);
+		/* Mark DigiNotar certificates as revoked, no matter
+		 * where in the chain they are.
+		 */
+		if (x-name  strstr(x-name, DigiNotar))
+			{
+			ctx-error = X509_V_ERR_CERT_REVOKED;
+			ctx-error_depth = i;
+			ctx-current_cert = x;
+			if (!ctx-verify_cb(0,ctx))
+return 0;
+			}
+		}
+	return 1;
+	}
+
 static int get_crl_sk(X509_STORE_CTX *ctx, X509_CRL **pcrl, X509_CRL **pdcrl,
 			X509 **pissuer, int *pscore, unsigned int *preasons,
 			STACK_OF(X509_CRL) *crls)

Bug#639744: [Pkg-openssl-devel] Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA

2011-09-07 Thread Raphael Geissert 
[Kurt, please CC me on your replies. The BTS' -subscribe functionality doesn't 
seem to be working]
[CC'ing ubuntu sec, in case Kees or Jamie or whoever is taking care of the 
issue is also working on something to completely block DigiNotar]

On Monday 05 September 2011 14:55:50 Kurt Roeckx wrote:
 On Mon, Sep 05, 2011 at 02:15:31PM -0500, Raphael Geissert wrote:
  The only currently supported methods are OCSP and CRL, but none would do
  the trick in this case.
 
 I guess OCSP/CRL is only called for the top most certificate, and all
 the CAs in the chain aren't checked in most applications.  I thought
 I read Entrust revoked their signature, and in theory that should
 be enough.

As long as the client becomes aware of that revocation, yes.
DigiNotar's PKIOverheid CA also needs to be blocked. I don't remember reading 
any report of the gov already revoking it.

 At least the openssl verify util has a -crl_check, and
 -crl_check_all, but it doesn't do OCSP.

Yes, there's X509_V_FLAG_CRL_CHECK and X509_V_FLAG_CRL_CHECK_ALL.
OCSP can be checked with openssl ocsp, IIRC.

  I was thinking about hard-coding a check for CN=* DigiNotar * most likely
  in libcrypto's X.509 support, but so far my lack of knowledge of
  OpenSSL's internals has me a bit lost.
  Hard-coding it is suboptimal, but I think it is the only reasonable
  solution for the time being. We can't wait weeks or months for a better
  solution.
  
  What do you think about making such change?
 
 So you're basicly saying that X509_verify_cert() should give an
 error in case it finds DigiNotar somewhere in the chain?
 
 I'm not opposed to such a change, but would like to see a better
 option in the future.

Yes. I will try to spend some time with a debugger later today to find the 
right place to implement such check. Or do you have any hint? (the cn 
validation functions didn't seem to be executed in one case I tried)

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#639744: [Pkg-openssl-devel] Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA

2011-09-07 Thread Kurt Roeckx 
On Wed, Sep 07, 2011 at 10:57:51AM -0500, Raphael Geissert wrote:
 [Kurt, please CC me on your replies. The BTS' -subscribe functionality 
 doesn't 
 seem to be working]
 [CC'ing ubuntu sec, in case Kees or Jamie or whoever is taking care of the 
 issue is also working on something to completely block DigiNotar]
 
 On Monday 05 September 2011 14:55:50 Kurt Roeckx wrote:
  On Mon, Sep 05, 2011 at 02:15:31PM -0500, Raphael Geissert wrote:
   The only currently supported methods are OCSP and CRL, but none would do
   the trick in this case.
  
  I guess OCSP/CRL is only called for the top most certificate, and all
  the CAs in the chain aren't checked in most applications.  I thought
  I read Entrust revoked their signature, and in theory that should
  be enough.
 
 As long as the client becomes aware of that revocation, yes.
 DigiNotar's PKIOverheid CA also needs to be blocked. I don't remember reading 
 any report of the gov already revoking it.

There was a new update of firefox today that removed an other
certificate.  It also seems the government started using the new
one?

  At least the openssl verify util has a -crl_check, and
  -crl_check_all, but it doesn't do OCSP.
 
 Yes, there's X509_V_FLAG_CRL_CHECK and X509_V_FLAG_CRL_CHECK_ALL.
 OCSP can be checked with openssl ocsp, IIRC.

There is an ocsp util that you can use to generate and
validate ocsp requests.  But it's not something you can
for instance check in something like s_client.  s_client
does support CRLs however, but you need to make sure
they're downloaded and updated.

Looking at different client software, it seems to me that
nothing is actually checking CRL.  And webbrowsers are
probably the only one doing OCSP, and only OCSP.

So the only solution I currently see is doing this in the
part that verifies the chain, and there making sure
know bad certificates generate a verify failure.

   I was thinking about hard-coding a check for CN=* DigiNotar * most likely
   in libcrypto's X.509 support, but so far my lack of knowledge of
   OpenSSL's internals has me a bit lost.
   Hard-coding it is suboptimal, but I think it is the only reasonable
   solution for the time being. We can't wait weeks or months for a better
   solution.
   
   What do you think about making such change?
  
  So you're basicly saying that X509_verify_cert() should give an
  error in case it finds DigiNotar somewhere in the chain?
  
  I'm not opposed to such a change, but would like to see a better
  option in the future.
 
 Yes. I will try to spend some time with a debugger later today to find the 
 right place to implement such check. Or do you have any hint? (the cn 
 validation functions didn't seem to be executed in one case I tried)

I have no real idea.


Kurt




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#639744: [Pkg-openssl-devel] Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA

2011-09-07 Thread Mike Hommey 
On Wed, Sep 07, 2011 at 06:23:18PM +0200, Kurt Roeckx wrote:
 On Wed, Sep 07, 2011 at 10:57:51AM -0500, Raphael Geissert wrote:
  [Kurt, please CC me on your replies. The BTS' -subscribe functionality 
  doesn't 
  seem to be working]
  [CC'ing ubuntu sec, in case Kees or Jamie or whoever is taking care of the 
  issue is also working on something to completely block DigiNotar]
  
  On Monday 05 September 2011 14:55:50 Kurt Roeckx wrote:
   On Mon, Sep 05, 2011 at 02:15:31PM -0500, Raphael Geissert wrote:
The only currently supported methods are OCSP and CRL, but none would do
the trick in this case.
   
   I guess OCSP/CRL is only called for the top most certificate, and all
   the CAs in the chain aren't checked in most applications.  I thought
   I read Entrust revoked their signature, and in theory that should
   be enough.
  
  As long as the client becomes aware of that revocation, yes.
  DigiNotar's PKIOverheid CA also needs to be blocked. I don't remember 
  reading 
  any report of the gov already revoking it.
 
 There was a new update of firefox today that removed an other
 certificate.

It corresponds to the second nss upload in Debian. (DSA-2300-2)

Mike



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#639744: [Pkg-openssl-devel] Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA

2011-09-07 Thread Raphael Geissert 
On Wednesday 07 September 2011 11:23:18 Kurt Roeckx wrote:
  On Monday 05 September 2011 14:55:50 Kurt Roeckx wrote:
   On Mon, Sep 05, 2011 at 02:15:31PM -0500, Raphael Geissert wrote:
The only currently supported methods are OCSP and CRL, but none would
do the trick in this case.
[...]
 Looking at different client software, it seems to me that
 nothing is actually checking CRL.  And webbrowsers are
 probably the only one doing OCSP, and only OCSP.

Yes, that was the impression I got when I checked some of the clients.
CRL is probably not used because:
a) it requires somebody (some program) to download the CRLs and keep them up 
to date
b) even if they are downloaded, where do they locate them? dirmngr and 
pathfinder both use their own protocol, and fetch-crl installs them in a non-
standard dir
c) clients would need to enable X509_V_FLAG_CRL_CHECK and/or 
X509_V_FLAG_CRL_CHECK_ALL depending on whether the certificates in the chain do 
have CRL distribution points.

 So the only solution I currently see is doing this in the
 part that verifies the chain, and there making sure
 know bad certificates generate a verify failure.

Yep, that's why I moved on to the proposal of the hard-coded check :)

   I'm not opposed to such a change, but would like to see a better
   option in the future.

Not sure how the engine's modularity was implemented, but something similar 
could be done so that X.509 certs could be verified by different modules:
* Standard: current chain validation and other existing checks
* Untrusted: checking a cert against a list of untrusted certs
* etc (something along Moxie's convergence, perspectives, or any other 
distributed trust model)

Anyways, that's something that needs to be discussed elsewhere.

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#639744: [Pkg-openssl-devel] Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA

2011-09-06 Thread Yves-Alexis Perez 
On mar., 2011-09-06 at 07:33 +0200, Mike Hommey wrote:
 On Mon, Sep 05, 2011 at 09:55:50PM +0200, Kurt Roeckx wrote:
  On Mon, Sep 05, 2011 at 02:15:31PM -0500, Raphael Geissert wrote:
   On Sunday 04 September 2011 05:55:27 Kurt Roeckx wrote:
On Sun, Sep 04, 2011 at 12:02:48PM +0200, Kurt Roeckx wrote:
 Their is also openssl-blacklist, but it doesn't seem to have
 much users.
   
   However, opensl-blacklist only includes a program that checks wether a 
   certificate is weak, nothing in it AFAICS actually blocks them. It's 
   basically 
   useless for this case.
  
  It could theoreticly also be used to block any certificate if
  we'd know the public key.  But I agree it's useless for this case.
 
 Actually, if it was used at all levels of the cert chain, we could block
 the CA certificates we want. And we do know their public key, contrary
 to the rogue certs.
 
In case this was missed:
http://www.f-secure.com/weblog/archives/2231.html

(sorry, pastebin seems to be under attack right now or slashdotted right
now, so http://pastebin.com/u/ComodoHacker is unavailable)

Regards,
-- 
Yves-Alexis


signature.asc
Description: This is a digitally signed message part

Bug#639744: [Pkg-openssl-devel] Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA

2011-09-05 Thread Raphael Geissert 
On Sunday 04 September 2011 05:55:27 Kurt Roeckx wrote:
 On Sun, Sep 04, 2011 at 12:02:48PM +0200, Kurt Roeckx wrote:
  Their is also openssl-blacklist, but it doesn't seem to have
  much users.

However, opensl-blacklist only includes a program that checks wether a 
certificate is weak, nothing in it AFAICS actually blocks them. It's basically 
useless for this case.

 After having read the bug report, I think we need to have a way
 to say that we don't trust a CA, or have a concept for which
 things we do trust a CA.  I think NSS has this concept, but
 openssl or ca-certificates clearly can't express this currently.
 
 An other way of saying the same thing  would be to be able to
 blacklist a CA.  The openssl-blacklist only contains a list of
 blocked certificates, but nothing in it now checks the trust
 path to see if it's used anywhere in the chain.

The only currently supported methods are OCSP and CRL, but none would do the 
trick in this case.

I was thinking about hard-coding a check for CN=* DigiNotar * most likely in 
libcrypto's X.509 support, but so far my lack of knowledge of OpenSSL's 
internals has me a bit lost.
Hard-coding it is suboptimal, but I think it is the only reasonable solution 
for the time being. We can't wait weeks or months for a better solution.

What do you think about making such change?

 If we want to add something, it would be nice if all SSL/TLS
 libraries could do that.  As far as I know, this currently
 includes:
 - openssl
 - gnutls
 - nss
 - polarssl
 
 I think I'm forgetting something for java.  And have the feeling
 I still forget something else.

Java: JSSE (but not sure what its status is in openjdk)
python-tlslite
yassl (cyassl now?), only used by mysql last time I checked
Not sure if we have a copy of cryptlib somewhere

Cheers,
-- 
Raphael Geissert - Debian Developer
www.debian.org - get.debian.net



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#639744: [Pkg-openssl-devel] Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA

2011-09-05 Thread Kurt Roeckx 
On Mon, Sep 05, 2011 at 02:15:31PM -0500, Raphael Geissert wrote:
 On Sunday 04 September 2011 05:55:27 Kurt Roeckx wrote:
  On Sun, Sep 04, 2011 at 12:02:48PM +0200, Kurt Roeckx wrote:
   Their is also openssl-blacklist, but it doesn't seem to have
   much users.
 
 However, opensl-blacklist only includes a program that checks wether a 
 certificate is weak, nothing in it AFAICS actually blocks them. It's 
 basically 
 useless for this case.

It could theoreticly also be used to block any certificate if
we'd know the public key.  But I agree it's useless for this case.

  After having read the bug report, I think we need to have a way
  to say that we don't trust a CA, or have a concept for which
  things we do trust a CA.  I think NSS has this concept, but
  openssl or ca-certificates clearly can't express this currently.
  
  An other way of saying the same thing  would be to be able to
  blacklist a CA.  The openssl-blacklist only contains a list of
  blocked certificates, but nothing in it now checks the trust
  path to see if it's used anywhere in the chain.
 
 The only currently supported methods are OCSP and CRL, but none would do the 
 trick in this case.

I guess OCSP/CRL is only called for the top most certificate, and all
the CAs in the chain aren't checked in most applications.  I thought
I read Entrust revoked their signature, and in theory that should
be enough.

At least the openssl verify util has a -crl_check, and
-crl_check_all, but it doesn't do OCSP.

 I was thinking about hard-coding a check for CN=* DigiNotar * most likely in 
 libcrypto's X.509 support, but so far my lack of knowledge of OpenSSL's 
 internals has me a bit lost.
 Hard-coding it is suboptimal, but I think it is the only reasonable solution 
 for the time being. We can't wait weeks or months for a better solution.
 
 What do you think about making such change?

So you're basicly saying that X509_verify_cert() should give an
error in case it finds DigiNotar somewhere in the chain?

I'm not opposed to such a change, but would like to see a better
option in the future.


Kurt




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#639744: [Pkg-openssl-devel] Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA

2011-09-05 Thread Mike Hommey 
On Mon, Sep 05, 2011 at 09:55:50PM +0200, Kurt Roeckx wrote:
 On Mon, Sep 05, 2011 at 02:15:31PM -0500, Raphael Geissert wrote:
  On Sunday 04 September 2011 05:55:27 Kurt Roeckx wrote:
   On Sun, Sep 04, 2011 at 12:02:48PM +0200, Kurt Roeckx wrote:
Their is also openssl-blacklist, but it doesn't seem to have
much users.
  
  However, opensl-blacklist only includes a program that checks wether a 
  certificate is weak, nothing in it AFAICS actually blocks them. It's 
  basically 
  useless for this case.
 
 It could theoreticly also be used to block any certificate if
 we'd know the public key.  But I agree it's useless for this case.

Actually, if it was used at all levels of the cert chain, we could block
the CA certificates we want. And we do know their public key, contrary
to the rogue certs.

Mike



-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#639744: [Pkg-openssl-devel] Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA

2011-09-04 Thread Kurt Roeckx 
On Sun, Sep 04, 2011 at 01:37:19AM -0500, Raphael Geissert wrote:
 
 Seems like it would be better if we also handled the issue at the libssl 
 level. OpenSSL maintainers: does that sound doable?

I'm not sure what you mean.  We don't provide any certificates,
you need to tell openssl which certs to use, which can be a file
or directory.  There are certificates provided by ca-certificates,
which is probably what most people would use and afaik the DigiNotar
CA got dropped from it.

Their is also openssl-blacklist, but it doesn't seem to have
much users.


Kurt




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#639744: [Pkg-openssl-devel] Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA

2011-09-04 Thread Kurt Roeckx 
On Sun, Sep 04, 2011 at 12:02:48PM +0200, Kurt Roeckx wrote:
 On Sun, Sep 04, 2011 at 01:37:19AM -0500, Raphael Geissert wrote:
  
  Seems like it would be better if we also handled the issue at the libssl 
  level. OpenSSL maintainers: does that sound doable?
 
 I'm not sure what you mean.  We don't provide any certificates,
 you need to tell openssl which certs to use, which can be a file
 or directory.  There are certificates provided by ca-certificates,
 which is probably what most people would use and afaik the DigiNotar
 CA got dropped from it.
 
 Their is also openssl-blacklist, but it doesn't seem to have
 much users.

After having read the bug report, I think we need to have a way
to say that we don't trust a CA, or have a concept for which
things we do trust a CA.  I think NSS has this concept, but
openssl or ca-certificates clearly can't express this currently.

An other way of saying the same thing  would be to be able to
blacklist a CA.  The openssl-blacklist only contains a list of
blocked certificates, but nothing in it now checks the trust
path to see if it's used anywhere in the chain.

If we want to add something, it would be nice if all SSL/TLS
libraries could do that.  As far as I know, this currently
includes:
- openssl
- gnutls
- nss
- polarssl

I think I'm forgetting something for java.  And have the feeling
I still forget something else.


Kurt




-- 
To UNSUBSCRIBE, email to debian-bugs-rc-requ...@lists.debian.org
with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org