Bug#639744: [Pkg-openssl-devel] Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
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
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-dist-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
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
[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-dist-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
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-dist-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
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-dist-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
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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Tuesday 06 September 2011 08:19:27 Mike Hommey wrote: On Tue, Sep 06, 2011 at 03:03:27PM +0200, Giuseppe Iuculano wrote: On 09/04/2011 09:20 PM, Raphael Geissert wrote: Giuseppe, do you already have plans for updating chromium? (more info on the CCed bug.) chromium uses libnss, please explain, what kind of update chromium needs? did I miss something? You missed the part where chromium uses libpkix (despite mozilla saying it's not ready), and the libpkix path doesn't reject the certs chaining to the Explicitly Disabled CAs. Giuseppe, in case you missed it: according to [1] Chromium needs an update to .220 [1]http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=639744#203 Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-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
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: Compromised certificates for *.google.com issued by DigiNotar Root CA
Hi, On 09/04/2011 09:20 PM, Raphael Geissert wrote: NSS now ships modified certs of DigiNotar, their name is Explicitly Disabled DigiNotar rest of the original CN here In chromium, for example, if you browse a DigiNotar-signed website and check the certificate chain you will see the Explicitly Disabled cert there. Giuseppe, do you already have plans for updating chromium? (more info on the CCed bug.) chromium uses libnss, please explain, what kind of update chromium needs? did I miss something? Cheers, Giuseppe. signature.asc Description: OpenPGP digital signature
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Tue, Sep 06, 2011 at 03:03:27PM +0200, Giuseppe Iuculano wrote: Hi, On 09/04/2011 09:20 PM, Raphael Geissert wrote: NSS now ships modified certs of DigiNotar, their name is Explicitly Disabled DigiNotar rest of the original CN here In chromium, for example, if you browse a DigiNotar-signed website and check the certificate chain you will see the Explicitly Disabled cert there. Giuseppe, do you already have plans for updating chromium? (more info on the CCed bug.) chromium uses libnss, please explain, what kind of update chromium needs? did I miss something? You missed the part where chromium uses libpkix (despite mozilla saying it's not ready), and the libpkix path doesn't reject the certs chaining to the Explicitly Disabled CAs. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Tuesday 30 August 2011 12:29:23 Raphael Geissert wrote: AFAIR they only know about CRL (Certificate Revocation List,) which only allows for one issuer per-file. What I can't tell for sure from the documentation is whether OpenSSL and GnuTLS do check the CRL's validity (signature and time.) It doesn't seem like they do. This is relevant if we were to ship them in ca-certificates. Just for future reference, after further investigation: OpenSSL _does_ check the CRL's signature. CRLs should be available, via symlinks for example, in /etc/ssl/certs[1] and c_rehash run on that directory. Applications using OpenSSL may instruct it to load the CRLs in two different ways: by manually loading every single CRL, or by adding the /etc/ssl/certs path to the X509 store. However, failure to find a CRL for the signer's cert results in validation failure. What I still haven't verified is that if the presence or absence of the CRL Distribution Points leads to a behaviour change (I'd assume it doesn't.) GnuTLS does seem to require that every CRL is loaded. Haven't tested its behaviours. [1] A different directory may be used, but for compatibility with openssl(1) the same directory should be used. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-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
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-dist-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
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-dist-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
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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Saturday 03 September 2011 01:45:22 Mike Hommey wrote: Looking at the patches, this really is: [...] Ok, with the patches we got NSS covered, but we still need to do something for other users. A first look at stuff we ship, this seems to be their current status: * NSS: ice* packages should be okay after the latest NSS update. * OpenSSL Nothing special here * GnuTLS Nothing special here * chromium: Even after the NSS update, it seems to be happy to use the Explicitly Distrusted certs. * Qt: Qt4 has built-in support for SSL via OpenSSL. Qt 4.7 (wheezey+) uses certs from /etc/ssl Qt 4.6 and older (lenny, squeeze) uses its own bundled list of certs. DigiNotar not included Qt3 doesn't have built-in support for SSL. Qt3-based software often use QCA, see below * QCA There are two versions: 1 for Qt3 and 2 for Qt4, both use OpenSSL as the backend for SSL. Seems like it would be better if we also handled the issue at the libssl level. OpenSSL maintainers: does that sound doable? Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Sun, Sep 04, 2011 at 01:37:19AM -0500, Raphael Geissert wrote: On Saturday 03 September 2011 01:45:22 Mike Hommey wrote: Looking at the patches, this really is: [...] Ok, with the patches we got NSS covered, but we still need to do something for other users. A first look at stuff we ship, this seems to be their current status: * NSS: ice* packages should be okay after the latest NSS update. * OpenSSL Nothing special here * GnuTLS Nothing special here * chromium: Even after the NSS update, it seems to be happy to use the Explicitly Distrusted certs. * Qt: Qt4 has built-in support for SSL via OpenSSL. Qt 4.7 (wheezey+) uses certs from /etc/ssl Qt 4.6 and older (lenny, squeeze) uses its own bundled list of certs. DigiNotar not included If Entrust is included, there's still a problem. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Sun, Sep 04, 2011 at 01:37:19AM -0500, Raphael Geissert wrote: On Saturday 03 September 2011 01:45:22 Mike Hommey wrote: Looking at the patches, this really is: [...] Ok, with the patches we got NSS covered, but we still need to do something for other users. A first look at stuff we ship, this seems to be their current status: * NSS: ice* packages should be okay after the latest NSS update. * OpenSSL Nothing special here * GnuTLS Nothing special here * chromium: Even after the NSS update, it seems to be happy to use the Explicitly Distrusted certs. Note that this suggests others NSS using applications may be affected too, if they don't do the appropriate thing for untrusted certs. I know at least pidgin and evolution use NSS. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-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
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-dist-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
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-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On dim., 2011-09-04 at 01:37 -0500, Raphael Geissert wrote: On Saturday 03 September 2011 01:45:22 Mike Hommey wrote: Looking at the patches, this really is: [...] Ok, with the patches we got NSS covered, but we still need to do something for other users. A first look at stuff we ship, this seems to be their current status: * NSS: ice* packages should be okay after the latest NSS update. For other NSS users I guess they're ok? I've just checked in evolution certificate store and there's no DigiNotar one, though I don't know if evolution would prevent connection to an imap/pop/smtp server with a relevant certificate. evolution uses gnutls for calendars (since it's http/https) and so is protected through ca-certificates afaict? * OpenSSL Nothing special here * GnuTLS Nothing special here * chromium: Even after the NSS update, it seems to be happy to use the Explicitly Distrusted certs. I've tried the tree websites given on this bug report but I don't know if they still make sense: https://www.diginotar.nl redirects to http://www.diginotar.nl/ (!!) but as the redirect isn't prevented I guess chromium is ok with the certificate. https://sha2.diginotar.nl/ succeeds, chain of certification is: CN = sha2.diginotar.nl CN = DigiNotar PKIoverheid CA Organisatie - G2 CN = Staat der Nederlanden Organisatie CA - G2 CN = Staat der Nederlanden Root CA - G2 (chromium builtin). Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On 09/04/2011 10:35 AM, Yves-Alexis Perez wrote: On dim., 2011-09-04 at 01:37 -0500, Raphael Geissert wrote: On Saturday 03 September 2011 01:45:22 Mike Hommey wrote: Looking at the patches, this really is: [...] Ok, with the patches we got NSS covered, but we still need to do something for other users. A first look at stuff we ship, this seems to be their current status: * NSS: ice* packages should be okay after the latest NSS update. For other NSS users I guess they're ok? I've just checked in evolution certificate store and there's no DigiNotar one, though I don't know if evolution would prevent connection to an imap/pop/smtp server with a relevant certificate. evolution uses gnutls for calendars (since it's http/https) and so is protected through ca-certificates afaict? * OpenSSL Nothing special here * GnuTLS Nothing special here * chromium: Even after the NSS update, it seems to be happy to use the Explicitly Distrusted certs. I've tried the tree websites given on this bug report but I don't know if they still make sense: https://www.diginotar.nl redirects to http://www.diginotar.nl/ (!!) but as the redirect isn't prevented I guess chromium is ok with the certificate. https://sha2.diginotar.nl/ succeeds, chain of certification is: CN = sha2.diginotar.nl CN = DigiNotar PKIoverheid CA Organisatie - G2 CN = Staat der Nederlanden Organisatie CA - G2 CN = Staat der Nederlanden Root CA - G2 (chromium builtin). Regards, Chromium needs an update to .220 to properly block all of the DigiNotar certificates. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Sunday 04 September 2011 02:34:13 Mike Hommey wrote: On Sun, Sep 04, 2011 at 01:37:19AM -0500, Raphael Geissert wrote: * Qt: Qt4 has built-in support for SSL via OpenSSL. Qt 4.7 (wheezey+) uses certs from /etc/ssl Qt 4.6 and older (lenny, squeeze) uses its own bundled list of certs. DigiNotar not included If Entrust is included, there's still a problem. Right. It appears to be included: subject= /C=US/O=Entrust.net/OU=www.entrust.net/CPS incorp. by ref. (limits liab.)/OU=(c) 1999 Entrust.net Limited/CN=Entrust.net Secure Server Certification Authority serial=374AD243 Staat der Nederlanden is not included. I attached the full list for future references, I extracted it from current HEAD (8f427b2) of the 4.6 branch of Qt. The common denominator here is still OpenSSL. If we make it reject DigiNotar certs, we can protect most of the SSL/TLS users. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net qt-ca-bundle.lst.gz Description: GNU Zip compressed data
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
[Dropping CC on openssl maintainers, to reduce noise] On Sunday 04 September 2011 10:35:16 Yves-Alexis Perez wrote: On dim., 2011-09-04 at 01:37 -0500, Raphael Geissert wrote: On Saturday 03 September 2011 01:45:22 Mike Hommey wrote: Looking at the patches, this really is: [...] Ok, with the patches we got NSS covered, but we still need to do something for other users. A first look at stuff we ship, this seems to be their current status: * NSS: ice* packages should be okay after the latest NSS update. For other NSS users I guess they're ok? I've just checked in evolution certificate store and there's no DigiNotar one, though I don't know if evolution would prevent connection to an imap/pop/smtp server with a relevant certificate. Did you look for Explicitly Disabled DigiNotar...? evolution uses gnutls for calendars (since it's http/https) and so is protected through ca-certificates afaict? Not really, since DigiNotar's CA is cross-signed by Entrust and it probably won't know that that signature has been revoked, since GnuTLS doesn't support OCSP. That's the same sad story for everything else using GnuTLS and for many OpenSSL users. OpenSSL does support OCSP, but applications rarely use it. I've tried the tree websites given on this bug report but I don't know if they still make sense: https://www.diginotar.nl redirects to http://www.diginotar.nl/ (!!) but as the redirect isn't prevented I guess chromium is ok with the certificate. https://sha2.diginotar.nl/ succeeds, chain of certification is: CN = sha2.diginotar.nl CN = DigiNotar PKIoverheid CA Organisatie - G2 CN = Staat der Nederlanden Organisatie CA - G2 CN = Staat der Nederlanden Root CA - G2 (chromium builtin). From mozilla's bugzilla, these should also fail: https://www.nifpnet.nl/ https://belastingbalie.eindhoven.nl/ https://acceptation.cbpublications.ingcommercialbanking.com/ (disable online recovation check before testing, at least the last one) Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On dim., 2011-09-04 at 13:34 -0500, Raphael Geissert wrote: [Dropping CC on openssl maintainers, to reduce noise] On Sunday 04 September 2011 10:35:16 Yves-Alexis Perez wrote: On dim., 2011-09-04 at 01:37 -0500, Raphael Geissert wrote: On Saturday 03 September 2011 01:45:22 Mike Hommey wrote: Looking at the patches, this really is: [...] Ok, with the patches we got NSS covered, but we still need to do something for other users. A first look at stuff we ship, this seems to be their current status: * NSS: ice* packages should be okay after the latest NSS update. For other NSS users I guess they're ok? I've just checked in evolution certificate store and there's no DigiNotar one, though I don't know if evolution would prevent connection to an imap/pop/smtp server with a relevant certificate. Did you look for Explicitly Disabled DigiNotar...? What do you mean? evolution uses gnutls for calendars (since it's http/https) and so is protected through ca-certificates afaict? Not really, since DigiNotar's CA is cross-signed by Entrust and it probably won't know that that signature has been revoked, since GnuTLS doesn't support OCSP. That's the same sad story for everything else using GnuTLS and for many OpenSSL users. OpenSSL does support OCSP, but applications rarely use it. Damn. I've tried the tree websites given on this bug report but I don't know if they still make sense: https://www.diginotar.nl redirects to http://www.diginotar.nl/ (!!) but as the redirect isn't prevented I guess chromium is ok with the certificate. https://sha2.diginotar.nl/ succeeds, chain of certification is: CN = sha2.diginotar.nl CN = DigiNotar PKIoverheid CA Organisatie - G2 CN = Staat der Nederlanden Organisatie CA - G2 CN = Staat der Nederlanden Root CA - G2 (chromium builtin). From mozilla's bugzilla, these should also fail: https://www.nifpnet.nl/ https://belastingbalie.eindhoven.nl/ https://acceptation.cbpublications.ingcommercialbanking.com/ (disable online recovation check before testing, at least the last one) None of them fail (the last one fails with revocation checking) Cheers, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Sunday 04 September 2011 13:54:29 Yves-Alexis Perez wrote: On dim., 2011-09-04 at 13:34 -0500, Raphael Geissert wrote: On Sunday 04 September 2011 10:35:16 Yves-Alexis Perez wrote: For other NSS users I guess they're ok? I've just checked in evolution certificate store and there's no DigiNotar one, though I don't know if evolution would prevent connection to an imap/pop/smtp server with a relevant certificate. Did you look for Explicitly Disabled DigiNotar...? What do you mean? NSS now ships modified certs of DigiNotar, their name is Explicitly Disabled DigiNotar rest of the original CN here In chromium, for example, if you browse a DigiNotar-signed website and check the certificate chain you will see the Explicitly Disabled cert there. Giuseppe, do you already have plans for updating chromium? (more info on the CCed bug.) Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Sat, Sep 03, 2011 at 07:40:23AM +0200, Mike Hommey wrote: On Wed, Aug 31, 2011 at 11:02:53PM -0500, Raphael Geissert wrote: On Tuesday 30 August 2011 23:30:19 Mike Hommey wrote: On Wed, Aug 31, 2011 at 06:26:26AM +0200, Mike Hommey wrote: So, I'll put that on tiredness. That'd be several fraudulent certificates which fingerprint is unknown (thus even CRL, OCSP and blacklists can't do anything), and the mitigation involves several different intermediate certs that are cross-signed, which makes it kind of hard. Plus, there is the problem that untrusting the DigiNotar root untrusts a separate PKI used by the Dutch government. AFAICS, this last part is not true. The gov has one Root and DigiNotar's PKIOverheid is one if its leafs. Other DigiNotar CAs are the one derived from Entrust (seems to have been revoked), and a PKIOverheid G2 that I've seen mentioned in a few places (also derived from Entrust?) Add to the above that untrusting a root still allows users to override in applications, and we have no central way to not allow that. Aiui, the mozilla update is going to block overrides as well, but that involves the application side. NSS won't deal with that. See https://bugzilla.mozilla.org/show_bug.cgi?id=682927 which is now open. Thanks for the link. FWIW, it seems that the government is ACKing [3] that DigiNotar re-signs certificates with its PKIOverheid CA for non-gov users of its now-untrusted DigiNotar Root CA. Action items based on what others are doing: 1. Disable DigiNotar Root CA: done 2. Disable other DigiNotar CAs (derived from Entrust)[4]: not done 3. Still permit Staat der Nederlanden CA and PKIoverheid: nothing to be done Item 2 is handled by Mozilla by matching /^DigiNotar/ and marking them as untrusted at the PMS level. http://blog.mozilla.com/security/2011/09/02/diginotar-removal-follow-up/ On the NSS end, this is my understanding of the status (haven't gone through the patches yet): - It disables DigiNotar Root CA - It untrusts the signatures from Entrust on the DigiNotar CAs - It blacklists /^DigiNotar/ intermediates All that at NSS level, making the solution work in all applications using NSS, which is good. I need to check what is done at PSM level now. And affected dutch users are now officially aware they're screwed. http://www.rnw.nl/english/bulletin/security-dutch-government-websites-jeopardy Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Sat, Sep 03, 2011 at 07:40:23AM +0200, Mike Hommey wrote: On Wed, Aug 31, 2011 at 11:02:53PM -0500, Raphael Geissert wrote: On Tuesday 30 August 2011 23:30:19 Mike Hommey wrote: On Wed, Aug 31, 2011 at 06:26:26AM +0200, Mike Hommey wrote: So, I'll put that on tiredness. That'd be several fraudulent certificates which fingerprint is unknown (thus even CRL, OCSP and blacklists can't do anything), and the mitigation involves several different intermediate certs that are cross-signed, which makes it kind of hard. Plus, there is the problem that untrusting the DigiNotar root untrusts a separate PKI used by the Dutch government. AFAICS, this last part is not true. The gov has one Root and DigiNotar's PKIOverheid is one if its leafs. Other DigiNotar CAs are the one derived from Entrust (seems to have been revoked), and a PKIOverheid G2 that I've seen mentioned in a few places (also derived from Entrust?) Add to the above that untrusting a root still allows users to override in applications, and we have no central way to not allow that. Aiui, the mozilla update is going to block overrides as well, but that involves the application side. NSS won't deal with that. See https://bugzilla.mozilla.org/show_bug.cgi?id=682927 which is now open. Thanks for the link. FWIW, it seems that the government is ACKing [3] that DigiNotar re-signs certificates with its PKIOverheid CA for non-gov users of its now-untrusted DigiNotar Root CA. Action items based on what others are doing: 1. Disable DigiNotar Root CA: done 2. Disable other DigiNotar CAs (derived from Entrust)[4]: not done 3. Still permit Staat der Nederlanden CA and PKIoverheid: nothing to be done Item 2 is handled by Mozilla by matching /^DigiNotar/ and marking them as untrusted at the PMS level. http://blog.mozilla.com/security/2011/09/02/diginotar-removal-follow-up/ On the NSS end, this is my understanding of the status (haven't gone through the patches yet): - It disables DigiNotar Root CA - It untrusts the signatures from Entrust on the DigiNotar CAs - It blacklists /^DigiNotar/ intermediates All that at NSS level, making the solution work in all applications using NSS, which is good. Looking at the patches, this really is: - untrust all the DigiNotar* CAs[1] - untrust the PKIoverheid intermediates Untrusting is done by actually having entries for all these CAs, but marking them as untrusted. Mike 1. DigiNotar Root CA, DigiNotar Services 1024 CA, DigiNotar Services 1024 CA, DigiNotar Cyber CA, DigiNotar Cyber CA 2nd. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Sat, Sep 03, 2011 at 08:45:22AM +0200, Mike Hommey wrote: On Sat, Sep 03, 2011 at 07:40:23AM +0200, Mike Hommey wrote: On Wed, Aug 31, 2011 at 11:02:53PM -0500, Raphael Geissert wrote: On Tuesday 30 August 2011 23:30:19 Mike Hommey wrote: On Wed, Aug 31, 2011 at 06:26:26AM +0200, Mike Hommey wrote: So, I'll put that on tiredness. That'd be several fraudulent certificates which fingerprint is unknown (thus even CRL, OCSP and blacklists can't do anything), and the mitigation involves several different intermediate certs that are cross-signed, which makes it kind of hard. Plus, there is the problem that untrusting the DigiNotar root untrusts a separate PKI used by the Dutch government. AFAICS, this last part is not true. The gov has one Root and DigiNotar's PKIOverheid is one if its leafs. Other DigiNotar CAs are the one derived from Entrust (seems to have been revoked), and a PKIOverheid G2 that I've seen mentioned in a few places (also derived from Entrust?) Add to the above that untrusting a root still allows users to override in applications, and we have no central way to not allow that. Aiui, the mozilla update is going to block overrides as well, but that involves the application side. NSS won't deal with that. See https://bugzilla.mozilla.org/show_bug.cgi?id=682927 which is now open. Thanks for the link. FWIW, it seems that the government is ACKing [3] that DigiNotar re-signs certificates with its PKIOverheid CA for non-gov users of its now-untrusted DigiNotar Root CA. Action items based on what others are doing: 1. Disable DigiNotar Root CA: done 2. Disable other DigiNotar CAs (derived from Entrust)[4]: not done 3. Still permit Staat der Nederlanden CA and PKIoverheid: nothing to be done Item 2 is handled by Mozilla by matching /^DigiNotar/ and marking them as untrusted at the PMS level. http://blog.mozilla.com/security/2011/09/02/diginotar-removal-follow-up/ On the NSS end, this is my understanding of the status (haven't gone through the patches yet): - It disables DigiNotar Root CA - It untrusts the signatures from Entrust on the DigiNotar CAs - It blacklists /^DigiNotar/ intermediates All that at NSS level, making the solution work in all applications using NSS, which is good. Looking at the patches, this really is: - untrust all the DigiNotar* CAs[1] - untrust the PKIoverheid intermediates Untrusting is done by actually having entries for all these CAs, but marking them as untrusted. On the PSM side, there is an explicit blacklist of certificates which issuer matches CN=DigiNotar (strstr), even if NSS has the CAs untrusted. Additionally, if a certificate signed by DigiNotar is invalid because of the NSS distrust, it is marked as revoked instead of invalid if it has been issued after July 1st. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Thu, Sep 01, 2011 at 11:37:41PM -0500, Raphael Geissert wrote: On Thursday 01 September 2011 17:47:57 Mike Hommey wrote: On Thu, Sep 01, 2011 at 02:06:39PM -0500, Raphael Geissert wrote: Unless other certificates were signed with another CA, at least the *.google.com one should fail now. The chain of the the public *.google.com cert is: Issuer: C=NL, O=DigiNotar, CN=DigiNotar Root CA Subject: C=NL, O=DigiNotar, CN=DigiNotar Public CA 2025 Issuer: C=NL, O=DigiNotar, CN=DigiNotar Public CA 2025 Subject: C=US, O=Google Inc, L=Mountain View/serialNumber=PK00022922, CN=*.google.com AIUI, the DigiNotar Public CA 2025 is cross signed by Entrust. Do you have a copy of that one? http://www.diginotar.nl/LinkClick.aspx?fileticket=lSCwDq6q038%3dtabid=308 It looks like it's not cross-signed. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Wed, Aug 31, 2011 at 11:02:53PM -0500, Raphael Geissert wrote: On Tuesday 30 August 2011 23:30:19 Mike Hommey wrote: On Wed, Aug 31, 2011 at 06:26:26AM +0200, Mike Hommey wrote: So, I'll put that on tiredness. That'd be several fraudulent certificates which fingerprint is unknown (thus even CRL, OCSP and blacklists can't do anything), and the mitigation involves several different intermediate certs that are cross-signed, which makes it kind of hard. Plus, there is the problem that untrusting the DigiNotar root untrusts a separate PKI used by the Dutch government. AFAICS, this last part is not true. The gov has one Root and DigiNotar's PKIOverheid is one if its leafs. Other DigiNotar CAs are the one derived from Entrust (seems to have been revoked), and a PKIOverheid G2 that I've seen mentioned in a few places (also derived from Entrust?) Add to the above that untrusting a root still allows users to override in applications, and we have no central way to not allow that. Aiui, the mozilla update is going to block overrides as well, but that involves the application side. NSS won't deal with that. See https://bugzilla.mozilla.org/show_bug.cgi?id=682927 which is now open. Thanks for the link. FWIW, it seems that the government is ACKing [3] that DigiNotar re-signs certificates with its PKIOverheid CA for non-gov users of its now-untrusted DigiNotar Root CA. Action items based on what others are doing: 1. Disable DigiNotar Root CA: done 2. Disable other DigiNotar CAs (derived from Entrust)[4]: not done 3. Still permit Staat der Nederlanden CA and PKIoverheid: nothing to be done Item 2 is handled by Mozilla by matching /^DigiNotar/ and marking them as untrusted at the PMS level. http://blog.mozilla.com/security/2011/09/02/diginotar-removal-follow-up/ On the NSS end, this is my understanding of the status (haven't gone through the patches yet): - It disables DigiNotar Root CA - It untrusts the signatures from Entrust on the DigiNotar CAs - It blacklists /^DigiNotar/ intermediates All that at NSS level, making the solution work in all applications using NSS, which is good. I need to check what is done at PSM level now. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Wed, Aug 31, 2011 at 11:02:53PM -0500, Raphael Geissert wrote: On Tuesday 30 August 2011 23:30:19 Mike Hommey wrote: On Wed, Aug 31, 2011 at 06:26:26AM +0200, Mike Hommey wrote: So, I'll put that on tiredness. That'd be several fraudulent certificates which fingerprint is unknown (thus even CRL, OCSP and blacklists can't do anything), and the mitigation involves several different intermediate certs that are cross-signed, which makes it kind of hard. Plus, there is the problem that untrusting the DigiNotar root untrusts a separate PKI used by the Dutch government. AFAICS, this last part is not true. The gov has one Root and DigiNotar's PKIOverheid is one if its leafs. Other DigiNotar CAs are the one derived from Entrust (seems to have been revoked), and a PKIOverheid G2 that I've seen mentioned in a few places (also derived from Entrust?) Well, reality is that the Firefox 6.0.1 release, which has a white least for Staat der Nederlanden Root CA but not Staat der Nederlanden Root CA - G2, effectively prevents from going to a couple of dutch government sites. Considering it has been found that the PSM side blacklist doesn't work, that suggests that the root CA removal alone is responsible for the situation, but I could be wrong. Add to the above that untrusting a root still allows users to override in applications, and we have no central way to not allow that. Aiui, the mozilla update is going to block overrides as well, but that involves the application side. NSS won't deal with that. See https://bugzilla.mozilla.org/show_bug.cgi?id=682927 which is now open. Thanks for the link. FWIW, it seems that the government is ACKing [3] that DigiNotar re-signs certificates with its PKIOverheid CA for non-gov users of its now-untrusted DigiNotar Root CA. Action items based on what others are doing: 1. Disable DigiNotar Root CA: done 2. Disable other DigiNotar CAs (derived from Entrust)[4]: not done There are 3 of them iirc. 3. Still permit Staat der Nederlanden CA and PKIoverheid: nothing to be done Item 2 is handled by Mozilla by matching /^DigiNotar/ and marking them as untrusted at the PMS level. And that currently doesn't work. It seems reasonable to wait for a more correct fix there before uploading ice*. There may be another nss round before that, though, for the Entrust certs. Please also note that Kai Engert is going to work on a NSS patch to handle the whole think at NSS level which would port what PSM does for SSL to S/MIME and other uses of NSS. I'm not sure this will be easily backportable, though. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Thu, Sep 01, 2011 at 08:37:01AM +0200, Mike Hommey wrote: On Wed, Aug 31, 2011 at 11:02:53PM -0500, Raphael Geissert wrote: On Tuesday 30 August 2011 23:30:19 Mike Hommey wrote: On Wed, Aug 31, 2011 at 06:26:26AM +0200, Mike Hommey wrote: So, I'll put that on tiredness. That'd be several fraudulent certificates which fingerprint is unknown (thus even CRL, OCSP and blacklists can't do anything), and the mitigation involves several different intermediate certs that are cross-signed, which makes it kind of hard. Plus, there is the problem that untrusting the DigiNotar root untrusts a separate PKI used by the Dutch government. AFAICS, this last part is not true. The gov has one Root and DigiNotar's PKIOverheid is one if its leafs. Other DigiNotar CAs are the one derived from Entrust (seems to have been revoked), and a PKIOverheid G2 that I've seen mentioned in a few places (also derived from Entrust?) Well, reality is that the Firefox 6.0.1 release, which has a white least for Staat der Nederlanden Root CA but not Staat der Nederlanden Root CA - G2, effectively prevents from going to a couple of dutch government sites. Considering it has been found that the PSM side blacklist doesn't work, that suggests that the root CA removal alone is responsible for the situation, but I could be wrong. I did some actual testing. With the DigiNoTar Root CA removal, we don't block Staat der Nederlanden Root CA and Staat der Nederlanden Root CA - G2. We also don't block (obviously) the ones with intermediate certs signed by Entrust, and if I followed the story correctly, this means we're effectively *not* preventing the *.google.com, addons.mozilla.org, *.yahoo.com, etc. fraudulent certificates from being used. A few urls to test: https://www.diginotar.nl should be blocked, and is - OK https://sha2.diginotar.nl should not be blocked, and isn't - OK https://zga-tag.zorggroep-almere.nl should be blocked, and isn't - BAD Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Thursday 01 September 2011 01:37:01 Mike Hommey wrote: On Wed, Aug 31, 2011 at 11:02:53PM -0500, Raphael Geissert wrote: Well, reality is that the Firefox 6.0.1 release, which has a white least for Staat der Nederlanden Root CA but not Staat der Nederlanden Root CA - G2, effectively prevents from going to a couple of dutch government sites. Do you know if there's any plan to whitelist the G2 CA? Considering it has been found that the PSM side blacklist doesn't work, that suggests that the root CA removal alone is responsible for the situation, but I could be wrong. That's what I also understood from the bug report, but it puzzles me. How does the removal of DigiNotar Root CA affects Staat der Nederlanden Root CA? I must have missunderstood the message. Action items based on what others are doing: 1. Disable DigiNotar Root CA: done 2. Disable other DigiNotar CAs (derived from Entrust)[4]: not done There are 3 of them iirc. 3. Still permit Staat der Nederlanden CA and PKIoverheid: nothing to be done Item 2 is handled by Mozilla by matching /^DigiNotar/ and marking them as untrusted at the PMS level. And that currently doesn't work. It seems reasonable to wait for a more correct fix there before uploading ice*. There may be another nss round before that, though, for the Entrust certs. Please also note that Kai Engert is going to work on a NSS patch to handle the whole think at NSS level which would port what PSM does for SSL to S/MIME and other uses of NSS. I'm not sure this will be easily backportable, though. On Thursday 01 September 2011 04:12:44 Mike Hommey wrote: I did some actual testing. With the DigiNoTar Root CA removal, we don't block Staat der Nederlanden Root CA and Staat der Nederlanden Root CA - G2. We also don't block (obviously) the ones with intermediate certs signed by Entrust, and if I followed the story correctly, this means we're effectively *not* preventing the *.google.com, addons.mozilla.org, *.yahoo.com, etc. fraudulent certificates from being used. Unless other certificates were signed with another CA, at least the *.google.com one should fail now. The chain of the the public *.google.com cert is: Issuer: C=NL, O=DigiNotar, CN=DigiNotar Root CA Subject: C=NL, O=DigiNotar, CN=DigiNotar Public CA 2025 Issuer: C=NL, O=DigiNotar, CN=DigiNotar Public CA 2025 Subject: C=US, O=Google Inc, L=Mountain View/serialNumber=PK00022922, CN=*.google.com A few urls to test: https://www.diginotar.nl should be blocked, and is - OK https://sha2.diginotar.nl should not be blocked, and isn't - OK https://zga-tag.zorggroep-almere.nl should be blocked, and isn't - BAD The last one is atm only blocked if the user has a CRL-enabled system (KDE + kleopatra, or similar,) or OCSP validation enabled. I have an idea, but I need to test a few things first. It is too simple, so I guess I must be missing something, otherwise people would have already done it. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Thu, Sep 01, 2011 at 02:06:39PM -0500, Raphael Geissert wrote: On Thursday 01 September 2011 01:37:01 Mike Hommey wrote: On Wed, Aug 31, 2011 at 11:02:53PM -0500, Raphael Geissert wrote: Well, reality is that the Firefox 6.0.1 release, which has a white least for Staat der Nederlanden Root CA but not Staat der Nederlanden Root CA - G2, effectively prevents from going to a couple of dutch government sites. Do you know if there's any plan to whitelist the G2 CA? There is. Considering it has been found that the PSM side blacklist doesn't work, that suggests that the root CA removal alone is responsible for the situation, but I could be wrong. That's what I also understood from the bug report, but it puzzles me. How does the removal of DigiNotar Root CA affects Staat der Nederlanden Root CA? I must have missunderstood the message. Me too. It looks like some part of the blacklisting must be working, and the blacklisting is responsible for Staat der Nederlanden Root CA being affected, because their chain of trust involve a cert that happen to contain DigiNotar in its name. (PKIoverheid) Sorry for the confusion, this whole thing is such a mess. Action items based on what others are doing: 1. Disable DigiNotar Root CA: done 2. Disable other DigiNotar CAs (derived from Entrust)[4]: not done There are 3 of them iirc. 3. Still permit Staat der Nederlanden CA and PKIoverheid: nothing to be done Item 2 is handled by Mozilla by matching /^DigiNotar/ and marking them as untrusted at the PMS level. And that currently doesn't work. It seems reasonable to wait for a more correct fix there before uploading ice*. There may be another nss round before that, though, for the Entrust certs. Please also note that Kai Engert is going to work on a NSS patch to handle the whole think at NSS level which would port what PSM does for SSL to S/MIME and other uses of NSS. I'm not sure this will be easily backportable, though. On Thursday 01 September 2011 04:12:44 Mike Hommey wrote: I did some actual testing. With the DigiNoTar Root CA removal, we don't block Staat der Nederlanden Root CA and Staat der Nederlanden Root CA - G2. We also don't block (obviously) the ones with intermediate certs signed by Entrust, and if I followed the story correctly, this means we're effectively *not* preventing the *.google.com, addons.mozilla.org, *.yahoo.com, etc. fraudulent certificates from being used. Unless other certificates were signed with another CA, at least the *.google.com one should fail now. The chain of the the public *.google.com cert is: Issuer: C=NL, O=DigiNotar, CN=DigiNotar Root CA Subject: C=NL, O=DigiNotar, CN=DigiNotar Public CA 2025 Issuer: C=NL, O=DigiNotar, CN=DigiNotar Public CA 2025 Subject: C=US, O=Google Inc, L=Mountain View/serialNumber=PK00022922, CN=*.google.com AIUI, the DigiNotar Public CA 2025 is cross signed by Entrust. A few urls to test: https://www.diginotar.nl should be blocked, and is - OK https://sha2.diginotar.nl should not be blocked, and isn't - OK https://zga-tag.zorggroep-almere.nl should be blocked, and isn't - BAD The last one is atm only blocked if the user has a CRL-enabled system (KDE + kleopatra, or similar,) or OCSP validation enabled. Latest chromium does it too. I have an idea, but I need to test a few things first. It is too simple, so I guess I must be missing something, otherwise people would have already done it. The last one should be handled by the removal of the Entrust roots that signed DigiNoTar intermediate certs. Entrust actually requested the removal of these roots, as well as published revocations (which is why OCSP and CRL validation works) See https://bugzilla.mozilla.org/show_bug.cgi?id=683455 Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Thursday 01 September 2011 17:47:57 Mike Hommey wrote: On Thu, Sep 01, 2011 at 02:06:39PM -0500, Raphael Geissert wrote: Unless other certificates were signed with another CA, at least the *.google.com one should fail now. The chain of the the public *.google.com cert is: Issuer: C=NL, O=DigiNotar, CN=DigiNotar Root CA Subject: C=NL, O=DigiNotar, CN=DigiNotar Public CA 2025 Issuer: C=NL, O=DigiNotar, CN=DigiNotar Public CA 2025 Subject: C=US, O=Google Inc, L=Mountain View/serialNumber=PK00022922, CN=*.google.com AIUI, the DigiNotar Public CA 2025 is cross signed by Entrust. Do you have a copy of that one? I have an idea, but I need to test a few things first. It is too simple, so I guess I must be missing something, otherwise people would have already done it. The last one should be handled by the removal of the Entrust roots that signed DigiNoTar intermediate certs. Entrust actually requested the removal of these roots, as well as published revocations (which is why OCSP and CRL validation works) See https://bugzilla.mozilla.org/show_bug.cgi?id=683455 Well, no, they didn't request their roots from being removed. They are actively using them. What they've done is revoke their signatures for DigiNotar certs. We are still left with the question of how to invalidate those. Will try to test some things tomorrow. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Tuesday 30 August 2011 23:30:19 Mike Hommey wrote: On Wed, Aug 31, 2011 at 06:26:26AM +0200, Mike Hommey wrote: So, I'll put that on tiredness. That'd be several fraudulent certificates which fingerprint is unknown (thus even CRL, OCSP and blacklists can't do anything), and the mitigation involves several different intermediate certs that are cross-signed, which makes it kind of hard. Plus, there is the problem that untrusting the DigiNotar root untrusts a separate PKI used by the Dutch government. AFAICS, this last part is not true. The gov has one Root and DigiNotar's PKIOverheid is one if its leafs. Other DigiNotar CAs are the one derived from Entrust (seems to have been revoked), and a PKIOverheid G2 that I've seen mentioned in a few places (also derived from Entrust?) Add to the above that untrusting a root still allows users to override in applications, and we have no central way to not allow that. Aiui, the mozilla update is going to block overrides as well, but that involves the application side. NSS won't deal with that. See https://bugzilla.mozilla.org/show_bug.cgi?id=682927 which is now open. Thanks for the link. FWIW, it seems that the government is ACKing [3] that DigiNotar re-signs certificates with its PKIOverheid CA for non-gov users of its now-untrusted DigiNotar Root CA. Action items based on what others are doing: 1. Disable DigiNotar Root CA: done 2. Disable other DigiNotar CAs (derived from Entrust)[4]: not done 3. Still permit Staat der Nederlanden CA and PKIoverheid: nothing to be done Item 2 is handled by Mozilla by matching /^DigiNotar/ and marking them as untrusted at the PMS level. [3] https://www.govcert.nl/english/service-provision/knowledge-and- publications/factsheets/factsheet-fraudulently-issued-security-certificate- discovered.html (and the linked fact-sheet) [4] Entrust revoked them, marked as superseded in the CRL -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On lun., 2011-08-29 at 20:24 -0700, Josh Triplett wrote:
On Mon, Aug 29, 2011 at 08:32:40PM -0500, Raphael Geissert wrote:
On Monday 29 August 2011 20:19:11 Josh Triplett wrote:
Does OpenSSL not have any facility for a system-wide revocation
list?
No, I already checked that back when the Comodo hack occurred.
Every application needs to manually load the revocation lists, just
like they
need to manually check the trust chain and all the other
this-should-all-be-
done-in-just-one-place things.
I understand that they'd have to manually load the lists, but perhaps
it
would make sense to standardize a location from which they should load
them? Does OpenSSL or GnuTLS have any concept of a revocation store
format, similar to a certificate store, or would this need some
special-purpose custom format?
And it'd be nice if nss could share that store...
nss apps are more or less starting to use a {/etc/,~/.}pki/nssdb/ which
can be shared accross apps (though I only know about evolution using it
right now).
By the way, shouldn't this bug be clone to libnss3-1d (and maybe
iceweasel and icedove if they ship the certificates themselves)?
Regards,
--
Yves-Alexis
signature.asc
Description: This is a digitally signed message part
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Tuesday 30 August 2011 01:08:29 Yves-Alexis Perez wrote: On lun., 2011-08-29 at 20:24 -0700, Josh Triplett wrote: I understand that they'd have to manually load the lists, but perhaps it would make sense to standardize a location from which they should load them? Does OpenSSL or GnuTLS have any concept of a revocation store format, similar to a certificate store, or would this need some special-purpose custom format? AFAIR they only know about CRL (Certificate Revocation List,) which only allows for one issuer per-file. What I can't tell for sure from the documentation is whether OpenSSL and GnuTLS do check the CRL's validity (signature and time.) It doesn't seem like they do. This is relevant if we were to ship them in ca-certificates. And it'd be nice if nss could share that store... [...] By the way, shouldn't this bug be clone to libnss3-1d (and maybe iceweasel and icedove if they ship the certificates themselves)? Perhaps it's time to start a discussion as to how we can properly deal with all this mess: * Multiple packages shipping their own certificates list * Probably no app except web browsers support CRLs and/or OCSP * configuration Yves, do you know how the CRL stuff is handled in nss? Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On mar., 2011-08-30 at 12:29 -0500, Raphael Geissert wrote: On Tuesday 30 August 2011 01:08:29 Yves-Alexis Perez wrote: On lun., 2011-08-29 at 20:24 -0700, Josh Triplett wrote: I understand that they'd have to manually load the lists, but perhaps it would make sense to standardize a location from which they should load them? Does OpenSSL or GnuTLS have any concept of a revocation store format, similar to a certificate store, or would this need some special-purpose custom format? AFAIR they only know about CRL (Certificate Revocation List,) which only allows for one issuer per-file. What I can't tell for sure from the documentation is whether OpenSSL and GnuTLS do check the CRL's validity (signature and time.) It doesn't seem like they do. This is relevant if we were to ship them in ca-certificates. And it'd be nice if nss could share that store... [...] By the way, shouldn't this bug be clone to libnss3-1d (and maybe iceweasel and icedove if they ship the certificates themselves)? Perhaps it's time to start a discussion as to how we can properly deal with all this mess: * Multiple packages shipping their own certificates list * Probably no app except web browsers support CRLs and/or OCSP * configuration Yves, do you know how the CRL stuff is handled in nss? (my first name is Yves-Alexis :) I have no idea. There's a crlutil (http://www.mozilla.org/projects/security/pki/nss/tools/crlutil.html) but it works on previous database version (bdb, cert8.db and key3.db) while at least evolution now uses the shared sqlite db (cert9.db and key4.db, see https://wiki.mozilla.org/NSS_Shared_DB). Maybe Mike has some more ideas (adding him to CC:) Regards, -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Tue, Aug 30, 2011 at 09:58:18PM +0200, Yves-Alexis Perez wrote: On mar., 2011-08-30 at 12:29 -0500, Raphael Geissert wrote: On Tuesday 30 August 2011 01:08:29 Yves-Alexis Perez wrote: On lun., 2011-08-29 at 20:24 -0700, Josh Triplett wrote: I understand that they'd have to manually load the lists, but perhaps it would make sense to standardize a location from which they should load them? Does OpenSSL or GnuTLS have any concept of a revocation store format, similar to a certificate store, or would this need some special-purpose custom format? AFAIR they only know about CRL (Certificate Revocation List,) which only allows for one issuer per-file. What I can't tell for sure from the documentation is whether OpenSSL and GnuTLS do check the CRL's validity (signature and time.) It doesn't seem like they do. This is relevant if we were to ship them in ca-certificates. And it'd be nice if nss could share that store... [...] By the way, shouldn't this bug be clone to libnss3-1d (and maybe iceweasel and icedove if they ship the certificates themselves)? Perhaps it's time to start a discussion as to how we can properly deal with all this mess: * Multiple packages shipping their own certificates list * Probably no app except web browsers support CRLs and/or OCSP * configuration Yves, do you know how the CRL stuff is handled in nss? (my first name is Yves-Alexis :) I have no idea. There's a crlutil (http://www.mozilla.org/projects/security/pki/nss/tools/crlutil.html) but it works on previous database version (bdb, cert8.db and key3.db) while at least evolution now uses the shared sqlite db (cert9.db and key4.db, see https://wiki.mozilla.org/NSS_Shared_DB). The NSS tools are supposed to work with whatever database version you use, since they use NSS ;) That being said, there is a huge problem with mitigation in basically all the SSL libraries. There simply is no way to handle the current situation[1] without modifying applications. Mike 1. Several fraudulent certificates whose fingerprint is unknown signed with several different intermediate certs that are cross-signed by other safe CAs (aiui). -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On mar., 2011-08-30 at 22:48 +0200, Mike Hommey wrote: 1. Several fraudulent certificates whose fingerprint is unknown signed with several different intermediate certs that are cross-signed by other safe CAs (aiui). I missed that. What is the source for that? (i looked at the mozilla bug earlier but it lacks that level of precision) -- Yves-Alexis signature.asc Description: This is a digitally signed message part
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Tuesday 30 August 2011 15:48:11 Mike Hommey wrote: On Tue, Aug 30, 2011 at 09:58:18PM +0200, Yves-Alexis Perez wrote: On mar., 2011-08-30 at 12:29 -0500, Raphael Geissert wrote: What I can't tell for sure from the documentation is whether OpenSSL and GnuTLS do check the CRL's validity (signature and time.) It doesn't seem like they do. This is relevant if we were to ship them in ca-certificates. Mike, without digging into the documentation I found this reference [2] regarding NSS and its CRL support. Do you know if any of what is said on that email has changed? namely how 'next update' dates are handled. [2]http://www.mail-archive.com/mozilla-crypto@mozilla.org/msg00890.html Yves, do you know how the CRL stuff is handled in nss? (my first name is Yves-Alexis :) Oops, sorry. Please accept my apologies. That being said, there is a huge problem with mitigation in basically all the SSL libraries. There simply is no way to handle the current situation[1] without modifying applications. [...] 1. Several fraudulent certificates whose fingerprint is unknown signed with several different intermediate certs that are cross-signed by other safe CAs (aiui). Oh. Well, first thing first, I've NMUed ca-certs to remove the DigiNotar Root CA and will probably release a DSA with the change too (I'm afraid it will give a false sense of security.) What is to be done next should probably be discussed in -devel and have input from external people. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Tue, Aug 30, 2011 at 10:48:11PM +0200, Mike Hommey wrote: On Tue, Aug 30, 2011 at 09:58:18PM +0200, Yves-Alexis Perez wrote: On mar., 2011-08-30 at 12:29 -0500, Raphael Geissert wrote: On Tuesday 30 August 2011 01:08:29 Yves-Alexis Perez wrote: On lun., 2011-08-29 at 20:24 -0700, Josh Triplett wrote: I understand that they'd have to manually load the lists, but perhaps it would make sense to standardize a location from which they should load them? Does OpenSSL or GnuTLS have any concept of a revocation store format, similar to a certificate store, or would this need some special-purpose custom format? AFAIR they only know about CRL (Certificate Revocation List,) which only allows for one issuer per-file. What I can't tell for sure from the documentation is whether OpenSSL and GnuTLS do check the CRL's validity (signature and time.) It doesn't seem like they do. This is relevant if we were to ship them in ca-certificates. And it'd be nice if nss could share that store... [...] By the way, shouldn't this bug be clone to libnss3-1d (and maybe iceweasel and icedove if they ship the certificates themselves)? Perhaps it's time to start a discussion as to how we can properly deal with all this mess: * Multiple packages shipping their own certificates list * Probably no app except web browsers support CRLs and/or OCSP * configuration Yves, do you know how the CRL stuff is handled in nss? (my first name is Yves-Alexis :) I have no idea. There's a crlutil (http://www.mozilla.org/projects/security/pki/nss/tools/crlutil.html) but it works on previous database version (bdb, cert8.db and key3.db) while at least evolution now uses the shared sqlite db (cert9.db and key4.db, see https://wiki.mozilla.org/NSS_Shared_DB). The NSS tools are supposed to work with whatever database version you use, since they use NSS ;) That being said, there is a huge problem with mitigation in basically all the SSL libraries. There simply is no way to handle the current situation[1] without modifying applications. Mike 1. Several fraudulent certificates whose fingerprint is unknown signed with several different intermediate certs that are cross-signed by other safe CAs (aiui). So, I'll put that on tiredness. That'd be several fraudulent certificates which fingerprint is unknown (thus even CRL, OCSP and blacklists can't do anything), and the mitigation involves several different intermediate certs that are cross-signed, which makes it kind of hard. Plus, there is the problem that untrusting the DigiNotar root untrusts a separate PKI used by the Dutch government. Add to the above that untrusting a root still allows users to override in applications, and we have no central way to not allow that. Aiui, the mozilla update is going to block overrides as well, but that involves the application side. NSS won't deal with that. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Wed, Aug 31, 2011 at 06:26:26AM +0200, Mike Hommey wrote: On Tue, Aug 30, 2011 at 10:48:11PM +0200, Mike Hommey wrote: On Tue, Aug 30, 2011 at 09:58:18PM +0200, Yves-Alexis Perez wrote: On mar., 2011-08-30 at 12:29 -0500, Raphael Geissert wrote: On Tuesday 30 August 2011 01:08:29 Yves-Alexis Perez wrote: On lun., 2011-08-29 at 20:24 -0700, Josh Triplett wrote: I understand that they'd have to manually load the lists, but perhaps it would make sense to standardize a location from which they should load them? Does OpenSSL or GnuTLS have any concept of a revocation store format, similar to a certificate store, or would this need some special-purpose custom format? AFAIR they only know about CRL (Certificate Revocation List,) which only allows for one issuer per-file. What I can't tell for sure from the documentation is whether OpenSSL and GnuTLS do check the CRL's validity (signature and time.) It doesn't seem like they do. This is relevant if we were to ship them in ca-certificates. And it'd be nice if nss could share that store... [...] By the way, shouldn't this bug be clone to libnss3-1d (and maybe iceweasel and icedove if they ship the certificates themselves)? Perhaps it's time to start a discussion as to how we can properly deal with all this mess: * Multiple packages shipping their own certificates list * Probably no app except web browsers support CRLs and/or OCSP * configuration Yves, do you know how the CRL stuff is handled in nss? (my first name is Yves-Alexis :) I have no idea. There's a crlutil (http://www.mozilla.org/projects/security/pki/nss/tools/crlutil.html) but it works on previous database version (bdb, cert8.db and key3.db) while at least evolution now uses the shared sqlite db (cert9.db and key4.db, see https://wiki.mozilla.org/NSS_Shared_DB). The NSS tools are supposed to work with whatever database version you use, since they use NSS ;) That being said, there is a huge problem with mitigation in basically all the SSL libraries. There simply is no way to handle the current situation[1] without modifying applications. Mike 1. Several fraudulent certificates whose fingerprint is unknown signed with several different intermediate certs that are cross-signed by other safe CAs (aiui). So, I'll put that on tiredness. That'd be several fraudulent certificates which fingerprint is unknown (thus even CRL, OCSP and blacklists can't do anything), and the mitigation involves several different intermediate certs that are cross-signed, which makes it kind of hard. Plus, there is the problem that untrusting the DigiNotar root untrusts a separate PKI used by the Dutch government. Add to the above that untrusting a root still allows users to override in applications, and we have no central way to not allow that. Aiui, the mozilla update is going to block overrides as well, but that involves the application side. NSS won't deal with that. See https://bugzilla.mozilla.org/show_bug.cgi?id=682927 which is now open. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Tue, Aug 30, 2011 at 10:49:04PM -0500, Raphael Geissert wrote: On Tuesday 30 August 2011 15:48:11 Mike Hommey wrote: On Tue, Aug 30, 2011 at 09:58:18PM +0200, Yves-Alexis Perez wrote: On mar., 2011-08-30 at 12:29 -0500, Raphael Geissert wrote: What I can't tell for sure from the documentation is whether OpenSSL and GnuTLS do check the CRL's validity (signature and time.) It doesn't seem like they do. This is relevant if we were to ship them in ca-certificates. Mike, without digging into the documentation I found this reference [2] regarding NSS and its CRL support. Do you know if any of what is said on that email has changed? namely how 'next update' dates are handled. [2]http://www.mail-archive.com/mozilla-crypto@mozilla.org/msg00890.html I think CRL handling is still mostly manual work. I don't know much more though. Mike -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
Package: ca-certificates Version: 20110502 Severity: critical Tags: security Please see the following: https://bugzilla.mozilla.org/show_bug.cgi?id=682956 http://pastebin.com/ff7Yg663 http://pastebin.com/SwCZqskV (or just search current news for DigiNotar, optionally in conjunction with gmail or google.) Whatever resolution Mozilla and others end up with (revocation of the certificate or of the entire CA), ca-certificates will likely need to do the same. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Monday 29 August 2011 16:03:57 Josh Triplett wrote: Whatever resolution Mozilla and others end up with (revocation of the certificate or of the entire CA), ca-certificates will likely need to do the same. FWIW, individual certificates can't be revoked in ca-certificates. Shipping revocation lists is useless too. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Mon, Aug 29, 2011 at 08:09:02PM -0500, Raphael Geissert wrote: On Monday 29 August 2011 16:03:57 Josh Triplett wrote: Whatever resolution Mozilla and others end up with (revocation of the certificate or of the entire CA), ca-certificates will likely need to do the same. FWIW, individual certificates can't be revoked in ca-certificates. Shipping revocation lists is useless too. Does OpenSSL not have any facility for a system-wide revocation list? Fortunately, in this case, the resolution involves disabling the DigiNotar Root CA entirely, which ca-certificates can do. - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Monday 29 August 2011 20:19:11 Josh Triplett wrote: Does OpenSSL not have any facility for a system-wide revocation list? No, I already checked that back when the Comodo hack occurred. Every application needs to manually load the revocation lists, just like they need to manually check the trust chain and all the other this-should-all-be- done-in-just-one-place things. (I only checked OpenSSL and GnuTLS, don't know about other implementations.) Fortunately, in this case, the resolution involves disabling the DigiNotar Root CA entirely, which ca-certificates can do. Yep, this case can nicely be handled by ca-certificates. Cheers, -- Raphael Geissert - Debian Developer www.debian.org - get.debian.net -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
Bug#639744: Compromised certificates for *.google.com issued by DigiNotar Root CA
On Mon, Aug 29, 2011 at 08:32:40PM -0500, Raphael Geissert wrote: On Monday 29 August 2011 20:19:11 Josh Triplett wrote: Does OpenSSL not have any facility for a system-wide revocation list? No, I already checked that back when the Comodo hack occurred. Every application needs to manually load the revocation lists, just like they need to manually check the trust chain and all the other this-should-all-be- done-in-just-one-place things. I understand that they'd have to manually load the lists, but perhaps it would make sense to standardize a location from which they should load them? Does OpenSSL or GnuTLS have any concept of a revocation store format, similar to a certificate store, or would this need some special-purpose custom format? - Josh Triplett -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org
