Certificate Vulnerability

[David E. Ross]

See <http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-0166>. Discussion of
this at the Risks Forum 25.15 indicates that "All SSL and SSH keys
generated on Debian-based systems (Ubuntu, Kubuntu, etc) between
September 2006 and May 13th, 2008 may be affected." See "Debian
OpenSSL Predictable PRNG Toys" and "Debian OpenSSL Vulnerability" at
<http://catless.ncl.ac.uk/Risks/25.15.html>.

The recommendation is that all affected root certificates be revoked and
replaced. The question is whether any of the root certificates
installed in the past two years or are approved or under review are
affected.

--
David E. Ross
<http://www.rossde.com/>

Go to Mozdev at <http://www.mozdev.org/> for quick access to
extensions for Firefox, Thunderbird, SeaMonkey, and other
Mozilla-related applications. You can access Mozdev much
more quickly than you can Mozilla Add-Ons.

[Frank Hecker]

David E. Ross wrote:
> See <http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-0166>. Discussion of
> this at the Risks Forum 25.15 indicates that "All SSL and SSH keys
> generated on Debian-based systems (Ubuntu, Kubuntu, etc) between
> September 2006 and May 13th, 2008 may be affected." See "Debian
> OpenSSL Predictable PRNG Toys" and "Debian OpenSSL Vulnerability" at
> <http://catless.ncl.ac.uk/Risks/25.15.html>.
>
> The recommendation is that all affected root certificates be revoked and
> replaced. The question is whether any of the root certificates
> installed in the past two years or are approved or under review are
> affected.

I presume that by "affected root certificates" you mean "root
certificates with key pairs generated using OpenSSL on Debian-based
systems", correct? The only CA I can think of that would possibly be in
this situation is CAcert, and of course it's not even applying for
inclusion at this point. Maybe I'm naive, but I can't imagine any
commercial CAs are using OpenSSL for CA functions -- but in any case we
can certainly ask CAs about this. Could you please file a bug on this
against mozilla.org / CA certificates and assign it to me?

Frank

--
Frank Hecker
hec...@mozillafoundation.org

[Michael Ströder]

Frank Hecker wrote:
> I presume that by "affected root certificates" you mean "root
> certificates with key pairs generated using OpenSSL on Debian-based
> systems", correct?

Correct. But also CA operation may be affected by any system/component
the CA is deploying in its operational context (think of OpenSSH,
Apache/mod_ssl, VPN-software etc.).

> Maybe I'm naive, but I can't imagine any commercial CAs are using
> OpenSSL for CA functions

I'd guess OpenSSL is indeed used in some commercial PKI(-enabled)
packages. I know of at least one.

Ciao, Michael.

[Eddy Nigg (StartCom Ltd.)]

Frank Hecker:

I presume that by "affected root certificates" you mean "root 
certificates with key pairs generated using OpenSSL on Debian-based 
systems", correct? The only CA I can think of that would possibly be in 
this situation is CAcert, and of course it's not even applying for 
inclusion at this point. Maybe I'm naive, but I can't imagine any 
commercial CAs are using OpenSSL for CA functions -- but in any case we 
can certainly ask CAs about this.
  

I wouldn't say that in such a categorical way. There are various toolkits and libraries for cryptographic operations, with OpenSSL being one of them. Others which come to mind are obviously NSS, gnutls and Java, but I'm certain there are also closed source libraries from MS and other vendors.

As a matter of fact we (at StartCom) use the OpenSSL library at our CA system extensively - from signing certificates, interaction with the engine (HSM) through the PKCS11 interface up to the OPCS responders, all with the underlying OpenSSL library. Additionally we added and modified parts to specifically support our hardware based RNG, hardware based encryption accelerator and HSM.

I have no problem disclosing the use of the OpenSSL library by our CA, even after the Debian debacle. We could have also used a Java library and even considered it at some point (originally I'm Java programmer when I used to earn my daily bred with coding many years ago, so it could have been an almost obvious choice for me), but in the end we opted for OpenSSL. It serves us well and is relatively easy to understand and to handle - an excellent library and nothing to be ashamed about.

Just for the sport I also checked some ssh keys of some of our systems with a tool which is supposed to to check for weak keys and it obviously found none. StartCom Linux which we use is based on RHEL and all binaries are compiled at the premise, they never left the building one could say. In relation to that I wrote this article which explains our reasoning behind this somewhat more [1].

And after all news sites already reported about the Debian vulnerability I couldn't hold myself back and had to write something [2]. There were scores of revocation requests recently, many inquiries about this issue came in, so I felt the need to explain our situation publicly.

Back to your question above, I'm certain that many CAs use the OpenSSL library for certain functions, some more, some less. I can imagine that this includes even big ones (without naming names), but this is just a library which supports cryptographic functions and interfaces, it does that excellent and there is nothing wrong with that. Writing your own library has its drawbacks too, which is why many times open source code have an advantage in this respect. That's certainly true for a project the size of OpenSSL and with its many prominent developers involved (some of which I happen to know). Half the worlds web servers rely on the OpenSSL library, scores of other libraries and applications too. Therefore I think it's wrong to categorically deny OpenSSL as a useless piece of code not worthy to be used by CAs - just because some code-hero (or script-kiddy) had it wrong. That's certainly no the case!


[1] https://blog.startcom.org/?p=27 (Open Source is about Trust)
[2] https://blog.startcom.org/?p=85 (Randomly Broken Randomness)

Regards
Signer:	Eddy Nigg, StartCom Ltd.
Jabber:	star...@startcom.org
Blog:	Join the Revolution!
Phone:	+1.213.341.0390

[Frank Hecker]

Eddy Nigg (StartCom Ltd.) wrote:
> Therefore I think it's wrong to categorically deny OpenSSL as a useless
> piece of code not worthy to be used by CAs - just because some code-hero
> (or script-kiddy) had it wrong. That's certainly no the case!

You're right, my comment was a bit snarky in a way I didn't really
intend, and I apologize for that. I agree that OpenSSL is a good product
(and one that the Mozilla Foundation has helped fund some development
for, BTW), and in any case the present problem is really an OpenSSL on
Debian problem, not an OpenSSL problem per se.

However it's still unclear to me how many public commercial CAs have
incorporated OpenSSL+Debian, or even just OpenSSL, as a core part of
their infrastructure. You're willing and able at Startcom to "hand
build" large parts of your CA system, but I'm not sure if that's common
among public commercial CAs, or whether Startcom is unusual in this
regard. I'd rather guess that most public commercial CAs are deploying
off-the-shelf commercial CA software bought from a third party.

Frank

P.S. Since we're talking about hackable CA software, I'll also mention
the Dogtag project out of Red Hat, the open source version of the
commercial Red Hat Certificate System.

--
Frank Hecker
hec...@mozillafoundation.org

[David E. Ross]

On 5/16/2008 5:06 PM, David E. Ross wrote:
> See <http://nvd.nist.gov/nvd.cfm?cvename=CVE-2008-0166>. Discussion of
> this at the Risks Forum 25.15 indicates that "All SSL and SSH keys
> generated on Debian-based systems (Ubuntu, Kubuntu, etc) between
> September 2006 and May 13th, 2008 may be affected." See "Debian
> OpenSSL Predictable PRNG Toys" and "Debian OpenSSL Vulnerability" at
> <http://catless.ncl.ac.uk/Risks/25.15.html>.
>
> The recommendation is that all affected root certificates be revoked and
> replaced. The question is whether any of the root certificates
> installed in the past two years or are approved or under review are
> affected.
>

Please note that the problem is only with Debian-based implementations
of OpenSSL. Other Linux and also UNIX implementations of OpenSSL are
not affected.

Per Hecker's reply, I have opened bug report #434128.

[Eddy Nigg (StartCom Ltd.)]

Frank Hecker:

Eddy Nigg (StartCom Ltd.) wrote:
  

Therefore I think it's wrong to categorically deny OpenSSL as a useless 
piece of code not worthy to be used by CAs - just because some code-hero 
(or script-kiddy) had it wrong. That's certainly not the case!
    

I agree that OpenSSL is a good product 
(and one that the Mozilla Foundation has helped fund some development 
for, BTW), and in any case the present problem is really an OpenSSL on 
Debian problem, not an OpenSSL problem per se.
  

:-)

However it's still unclear to me how many public commercial CAs have 
incorporated OpenSSL+Debian, or even just OpenSSL, as a core part of 
their infrastructure. 

I have no clue about it obviously and I'm sure that most of them will not be willing to disclose what exactly they are using. However I think to all of my knowledge that your assumption about the CA which isn't included in NSS applies. But that's not relevant really.

You're willing and able at Startcom to "hand 
build" large parts of your CA system, but I'm not sure if that's common 
among public commercial CAs, or whether Startcom is unusual in this 
regard. 

I'm sure that StartCom is unique in this respect. We view this as our best approach and responsibility and on-the-way let others enjoy the fruits of that work with a little bit extra effort from our side. It's kind of a win-win situation which happened  when we started to build StartCom Linux back in 2004 for our hosting department because we also gained extra exposure by offering our RHEL clone to the public. No support, but an excellent operating system for free.

I'd rather guess that most public commercial CAs are deploying 
off-the-shelf commercial CA software bought from a third party.
  

Obviously the underlying operating system and libraries are from third parties, however I believe that most CAs develop their own (on top of existing libraries and toolkits). I can't imagine that CAs are using something like OpenCA or comparable commercial products or even MSCA for that. But perhaps I might be wrong as well...who knows.

P.S. Since we're talking about hackable CA software, I'll also mention 
the Dogtag project out of Red Hat, the open source version of the 
commercial Red Hat Certificate System.
  

Which is based on the former Netscape Directory Server, isn't it? Too late for us for now, but certainly an interesting product.

[Wan-Teh Chang]

2008/5/17 Eddy Nigg (StartCom Ltd.) <eddy...@startcom.org>:
> Frank Hecker:

>
> P.S. Since we're talking about hackable CA software, I'll also mention
> the Dogtag project out of Red Hat, the open source version of the
> commercial Red Hat Certificate System.
>
>
> Which is based on the former Netscape Directory Server, isn't it?

Dogtag is based on the former Netscape Certificate Management
System.

Fedora Directory Server is based on the former Netscape Directory
Server.

Wan-Teh