RE: Microsoft deems all DigiNotar certificates untrustworthy, releases updates
Damian Menscher wrote on 2011-09-11:
Because of that lost trust, any cross-signed cert would likely be revoked by the browsers. It would also make the browser vendors question whether the signing CA is worthy of their trust.
And therein is the root of the problem: Trustworthiness is assessed by what you refer to as the "browser vendors". Unfortunately, there is no Trustworthiness assessment of those vendors. The current system provides no more authentication or confidentiality than if everyone simply used self-signed certificates. It is nothing more than theatre and provides no actual security benefit whatsoever. Anyone believing otherwise is operating under a delusion. --- Keith Medcalf () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
On Sun, 11 Sep 2011 13:00:09 MDT, Keith Medcalf said:
The current system provides no more authentication or confidentiality than if everyone simply used self-signed certificates.
Not strictly true. The current system at least gives you "you have reached the hostname your browser tried to reach". A self-signed cert doesn't even give you that.
On Sun, Sep 11, 2011 at 3:37 PM, <Valdis.Kletnieks@vt.edu> wrote:
On Sun, 11 Sep 2011 13:00:09 MDT, Keith Medcalf said:
The current system provides no more authentication or confidentiality than if everyone simply used self-signed certificates.
Not strictly true. The current system at least gives you "you have reached the hostname your browser tried to reach". A self-signed cert doesn't even give you that.
really? even in the face of CA's that have signed certs for existing domains (to not the domain owners)? If I have a thawte cert for valdis.com on host A and one from comodo on host B... which is the right one?
On Sun, 11 Sep 2011 22:01:47 EDT, Christopher Morrow said:
If I have a thawte cert for valdis.com on host A and one from comodo on host B... which is the right one?
You wouldn't have 2 certs for that... I'd have *one* cert for that. And if when you got to the IP address you were trying to reach, the cert didn't validate as matching the hostname, you know something fishy is up. And if you *do* have two certs for it, I'd like to talk to the bozos at Thawte and Comodo who obviously didn't check the paperwork. ;)
On Mon, Sep 12, 2011 at 4:39 AM, <Valdis.Kletnieks@vt.edu> wrote:
On Sun, 11 Sep 2011 22:01:47 EDT, Christopher Morrow said:
If I have a thawte cert for valdis.com on host A and one from comodo on host B... which is the right one?
You wouldn't have 2 certs for that... I'd have *one* cert for that. And if when you got to the IP address you were trying to reach, the cert didn't validate as matching the hostname, you know something fishy is up.
And if you *do* have two certs for it, I'd like to talk to the bozos at Thawte and Comodo who obviously didn't check the paperwork. ;)
this has already happened with mozilla.com, google.com, microsoft.com .... my point was that as a user, and as a service operator, what in today's CA world helps me know that the service operator's certificate is what my user-client sees? some 'trust' in the fact that thawte/comodo/verisign/cnnic didn't issue a cert for the service-operator's service incorrectly? I think I need a method that the service operator can use to signal to my user-client outside the certificate itself that the certificate #1234 is the 'right' one.
Date: Mon, 12 Sep 2011 11:22:11 -0400 Subject: Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates From: Christopher Morrow <morrowc.lists@gmail.com>
I think I need a method that the service operator can use to signal to my user-client outside the certificate itself that the certificate #1234 is the 'right' one.
A certificate that cdrtifies the crertificate is valid, maybe? And why would you trust that any more than the origial certificate? And, if you do trust *that* certificate, what do you need the original one for? Seriously, about the only way I see to ameliorate this kind of problem is for people to use self-signed certificates that are then authenticated by _multiple_ 'trust anchors'. If the end-user world raises warnings for a certificate 'authenticated' by say, less than five separate entities. then the compomise of any _single_ anchor is of pretty much 'no' value. Even better, let the user set the 'paranoia' level -- how many different 'trusted' authorities have to have authenticated the self-signed certificate before the user 'really trusts' it. Similarly, the certificate 'owner' can decide how much 'redundancy' it wants in the 'authentiation' of it's identity -- how many separate authorities it gets to 'co-sign' it's certificate.
On Mon, Sep 12, 2011 at 1:39 PM, Robert Bonomi <bonomi@mail.r-bonomi.com> wrote:
Date: Mon, 12 Sep 2011 11:22:11 -0400 Subject: Re: Microsoft deems all DigiNotar certificates untrustworthy, releases updates From: Christopher Morrow <morrowc.lists@gmail.com>
I think I need a method that the service operator can use to signal to my user-client outside the certificate itself that the certificate #1234 is the 'right' one.
A certificate that cdrtifies the crertificate is valid, maybe?
so the DANE work does this, sort of... you sign (with dnssec) your cert fingerprint, the client does a lookup (requiring dnssec signed responses) to verify that the cert FP matches that which is in DNS.
And why would you trust that any more than the origial certificate?
at least in this case the domain owner (presumably the service owner in question) has signed (with their private key) the DNS content you get back. There are failure modes, but it's more in line with the service-owner/service-user level not some oddball thirdparty.
Seriously, about the only way I see to ameliorate this kind of problem is for people to use self-signed certificates that are then authenticated by _multiple_ 'trust anchors'. If the end-user world raises warnings for a certificate 'authenticated' by say, less than five separate entities. then the compomise of any _single_ anchor is of pretty much 'no' value. Even better, let the user set the 'paranoia' level -- how many different 'trusted' authorities have to have authenticated the self-signed certificate before the user 'really trusts' it.
this almost sounds like GPS position fixing... 'require 4 satellites in view', or something along those lines. Interesting as an idea though. -chris
On 12 September 2011 18:39, Robert Bonomi <bonomi@mail.r-bonomi.com> wrote:
Seriously, about the only way I see to ameliorate this kind of problem is for people to use self-signed certificates that are then authenticated by _multiple_ 'trust anchors'. If the end-user world raises warnings for a certificate 'authenticated' by say, less than five separate entities. then the compomise of any _single_ anchor is of pretty much 'no' value. Even better, let the user set the 'paranoia' level -- how many different 'trusted' authorities have to have authenticated the self-signed certificate before the user 'really trusts' it.
So if I want my small website to support encryption, I now have to pay 5 companies, and hope that all my users have those 5 CAs in their browser? Much better to use the existing DNS infrastructure (that all 5 of them would likely be using for their validation anyway), and not have to pay anyone anything. - Mike
At 13:00 11/09/2011 -0600, Keith Medcalf wrote:
Damian Menscher wrote on 2011-09-11:
Because of that lost trust, any cross-signed cert would likely be revoked by the browsers. It would also make the browser vendors question whether the signing CA is worthy of their trust.
And therein is the root of the problem: Trustworthiness is assessed by what you refer to as the "browser vendors". Unfortunately, there is no Trustworthiness assessment of those vendors.
The current system provides no more authentication or confidentiality than if everyone simply used self-signed certificates. It is nothing more than theatre and provides no actual security benefit whatsoever. Anyone believing otherwise is operating under a delusion.
The problem is about lack of pen-testing and a philosphy of security. In order to run a CA, one not only has to build the infrastructure but also have constant external pen-testing and patch management in place. Whether it be Comodo or RSA or now Diginotar, unless an overwhelming philosphy of "computer and network security" is paradigmed into the corporate DNA, this will keep happening - and not only to CAs but to the likes of Google, Cisco, Microsoft, etc. (read - APT attacks). If 60% of your employees will plug in a USB drive they find in the parking lot, then you have failed: http://www.bloomberg.com/news/2011-06-27/human-errors-fuel-hacking-as-test-s... The problem for us as a community if to find a benchmark of which company "does have a clue" vs those that don't. Until then, it will just be whack-a-mole/CA. -Hank
--- Keith Medcalf () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
Hank and everyone, This is a very interesting problem. As it happens, some folks in the IETF have anticipated this one. For those who are interested, Paul Hoffman and Jakob Schlyter have been working within the DANE working group at the IETF to provide for a means to alleviate some of the responsibility of the browser vendors as to who gets to decide what is a valid certificate, by allowing for that burden to be shifted to the subject through the use of secure DNS. A list of hashes is published in the subject's domain indicating what are valid certificates. And so if a CA went rogue, the subject domains would be able to indicate to the browser that something is afoot. For more information, please see http://datatracker.ietf.org/wg/dane/. Eliot On 9/12/11 7:22 AM, Hank Nussbacher wrote:
At 13:00 11/09/2011 -0600, Keith Medcalf wrote:
Damian Menscher wrote on 2011-09-11:
Because of that lost trust, any cross-signed cert would likely be revoked by the browsers. It would also make the browser vendors question whether the signing CA is worthy of their trust.
And therein is the root of the problem: Trustworthiness is assessed by what you refer to as the "browser vendors". Unfortunately, there is no Trustworthiness assessment of those vendors.
The current system provides no more authentication or confidentiality than if everyone simply used self-signed certificates. It is nothing more than theatre and provides no actual security benefit whatsoever. Anyone believing otherwise is operating under a delusion.
The problem is about lack of pen-testing and a philosphy of security. In order to run a CA, one not only has to build the infrastructure but also have constant external pen-testing and patch management in place. Whether it be Comodo or RSA or now Diginotar, unless an overwhelming philosphy of "computer and network security" is paradigmed into the corporate DNA, this will keep happening - and not only to CAs but to the likes of Google, Cisco, Microsoft, etc. (read - APT attacks).
If 60% of your employees will plug in a USB drive they find in the parking lot, then you have failed: http://www.bloomberg.com/news/2011-06-27/human-errors-fuel-hacking-as-test-s...
The problem for us as a community if to find a benchmark of which company "does have a clue" vs those that don't. Until then, it will just be whack-a-mole/CA.
-Hank
--- Keith Medcalf () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
Except that this just shifts the burden of trust on to DNSSEC, which also necessitates a central authority of 'trust'. Unless there's an explicitly more secure way of storing DNSSEC private keys, this just moves the bullseye from CAs to DNSSEC signers. Jason On Mon, Sep 12, 2011 at 5:30 AM, Eliot Lear <lear@cisco.com> wrote:
Hank and everyone,
This is a very interesting problem. As it happens, some folks in the IETF have anticipated this one. For those who are interested, Paul Hoffman and Jakob Schlyter have been working within the DANE working group at the IETF to provide for a means to alleviate some of the responsibility of the browser vendors as to who gets to decide what is a valid certificate, by allowing for that burden to be shifted to the subject through the use of secure DNS. A list of hashes is published in the subject's domain indicating what are valid certificates. And so if a CA went rogue, the subject domains would be able to indicate to the browser that something is afoot. For more information, please see http://datatracker.ietf.org/wg/dane/.
Eliot
On 9/12/11 7:22 AM, Hank Nussbacher wrote:
At 13:00 11/09/2011 -0600, Keith Medcalf wrote:
Damian Menscher wrote on 2011-09-11:
Because of that lost trust, any cross-signed cert would likely be revoked by the browsers. It would also make the browser vendors question whether the signing CA is worthy of their trust.
And therein is the root of the problem: Trustworthiness is assessed by what you refer to as the "browser vendors". Unfortunately, there is no Trustworthiness assessment of those vendors.
The current system provides no more authentication or confidentiality than if everyone simply used self-signed certificates. It is nothing more than theatre and provides no actual security benefit whatsoever. Anyone believing otherwise is operating under a delusion.
The problem is about lack of pen-testing and a philosphy of security. In order to run a CA, one not only has to build the infrastructure but also have constant external pen-testing and patch management in place. Whether it be Comodo or RSA or now Diginotar, unless an overwhelming philosphy of "computer and network security" is paradigmed into the corporate DNA, this will keep happening - and not only to CAs but to the likes of Google, Cisco, Microsoft, etc. (read - APT attacks).
If 60% of your employees will plug in a USB drive they find in the parking lot, then you have failed:
http://www.bloomberg.com/news/2011-06-27/human-errors-fuel-hacking-as-test-s...
The problem for us as a community if to find a benchmark of which company "does have a clue" vs those that don't. Until then, it will just be whack-a-mole/CA.
-Hank
--- Keith Medcalf () ascii ribbon campaign against html e-mail /\ www.asciiribbon.org
In article <CAJNn=DNMrGC42i4Q_Wjvz-i9uV_4w1YnfM8vcX4g_wnXLoT=vA@mail.gmail.com> you write:
Except that this just shifts the burden of trust on to DNSSEC, which also necessitates a central authority of 'trust'. Unless there's an explicitly more secure way of storing DNSSEC private keys, this just moves the bullseye from CAs to DNSSEC signers.
It does, but it also limits the damage. If you lose your DNSSEC key, bad guys can forge names below you in the DNS tree. If you lose your CA key, bad guys can forge any name they want. Or to look at it another way, if I put effort into securing my own DNS, and I am careful about the providers above me in the tree, I can limit the chance of DNSSEC compromise. With SSL, it doesn't matter what I do, I'm always at the mercy of the next Diginotar. R's, John
On 9/12/11 4:32 PM, Jason Duerstock wrote:
Except that this just shifts the burden of trust on to DNSSEC, which also necessitates a central authority of 'trust'. Unless there's an explicitly more secure way of storing DNSSEC private keys, this just moves the bullseye from CAs to DNSSEC signers.
I said "some", not all, of the responsibility. By adding an independent PKI there is an additional control put in place to confirm that in fact the signer is authorized to sign. Should one go as far as to remove CA caches from browsers altogether? Eliot
participants (9)
-
Christopher Morrow -
Eliot Lear -
Hank Nussbacher -
Jason Duerstock -
John Levine -
Keith Medcalf -
Mike Jones -
Robert Bonomi -
Valdis.Kletnieks＠vt.edu