RE: Reuse of serial numbers

[Richard Wang]

I am sure it is revoked, please check it again, thanks.


Best Regards,

Richard

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+richard=wosig...@lists.mozilla.org] On Behalf Of Patrick T
Sent: Thursday, September 1, 2016 5:07 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Re: Reuse of serial numbers by StartCom

On Wednesday, 31 August 2016 17:57:41 UTC+1, Eddy Nigg wrote:
> On 08/31/2016 03:19 PM, Matt Palmer wrote:
> > That bug appears to pre-date *all* of the certificates listed above.
> > Further, the last communication on that bug (2014-09-22), from Eddy
> > Nigg (of StartCom), said:
> >> It's a hard and software related capacity issue of the queue
> >> managing the certificates and the real solution will be only
> >> available after a hardware upgrade we are planning for Nov-Dec this year.
> > So that's presumably Nov-Dec 2014... and 12 months later, duplicate
> > serial numbers were still appearing.
>
> Right, however we could limit this occurrence to a minimum at that
> time
> - an entirely new infrastructure was in the pipeline already which
> solved the problem completely. Please note that such infrastructures
> are fairly complex and therefore also hard to deal with sometimes. I
> acknowledged in the bug report that we were able significantly reduce
> this issue, though not eliminate entirely.
>
> > It's somewhat disconcerting that the response from StartCom in that
> > bug report was, essentially, a mixture of, "it's not our fault, the
> > software did it" and "ain't no thang". To me, that isn't a
> > particularly useful attitude for a CA operator. The correctness of
> > the software which is deployed is of
> > *crucial* importance to the trustworthiness of a CA.
>
> True, but as explained above, some more drastic changes had to be done
> in order to correct this issue completely, not something done over
> night. The corrective measure and eventual implementation was however
> there on the way, even if it took some time.
>
> Regarding our "attitude", even though this issue was certainly not
> desired, it wasn't comparable to a wrongful issuance leading to
> possible abuse - some client software would however stopped working
> when encountering a duplicate serial. And to my assessment this wasn't
> a situation which required to take an entire system down in order to "fix"
> it (which was necessary in this case).
>
> > Is anyone aware of any attempts by StartCom to proactively report
> > these BR violations to Mozilla or any other trust store operator, at
> > or around the time of issuance? I don't see any mention of the 2015
> > misissuances in the most recent BR audit report
> > (https://startssl.com/ey-webtrust-br.pdf),
> > either. Does this mean that StartCom were unaware that they had
> > issued these duplicate certificates, despite having a history of
> > doing so, or did they mislead their auditors?
>
> Neither - the software wasn't designed to issue certificates with
> duplicate serials, neither was that done knowingly or willfully. Since
> we are talking about an occurrence of perhaps one in 40-50 thousand
> certificates or less, it's not really something that can be measured
> by an auditor. What can be measured are software design, actions
> performed, implementation of plans to solve a particular issue.
>
> PS. it appears that most certificates mentioned originally have
> already expired, so there isn't much to revoke today except one.
>
> --
> Regards
> Signer: Eddy Nigg, Founder
> StartCom Ltd. <http://www.startcom.org>
> XMPP: star...@startcom.org <xmpp:star...@startcom.org>


Are the certificates listed here also affected by this problem?

https://crt.sh/?serial=056d1570da645bf6b44c0a7077cc6769&iCAID=1662

There seem to be a number of duplicated-serial certificates, which aren't revoked and are still valid.
_______________________________________________
dev-security-policy mailing list
dev-secur...@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

[Rob Stradling]

https://crt.sh/?serial=056d1570da645bf6b44c0a7077cc6769&iCAID=1662 says
"Not Revoked" three times. I wonder if that's causing some confusion here.

crt.sh currently only tracks revocation via various browser-based
blacklisting mechanisms (Chrome's CRLSets and hardcoded blacklist,
Microsoft's disallowedcert.stl and Mozilla's OneCRL).
crt.sh doesn't yet track CRLs signed by CAs (TODO:
https://github.com/crtsh/certwatch_db/issues/16) or OCSP.

I just downloaded http://crls6.wosign.com/ca6-server1-free.crl and found
that the serial number 056d1570da645bf6b44c0a7077cc6769 _is_ revoked.

The relevant OCSP server (http://ocsp6.wosign.com/ca6/server1/free) also
reports "revoked" for this issuer / serial number.

--
Rob Stradling
Senior Research & Development Scientist
COMODO - Creating Trust Online

[Peter Gutmann]

Rob Stradling <rob.st...@comodo.com> writes:

>https://crt.sh/?serial=056d1570da645bf6b44c0a7077cc6769&iCAID=1662 says
>"Not Revoked" three times. I wonder if that's causing some confusion here.

Just to make sure I'm not misreading this in some way, is this really saying
there are 313 certs issued all with the same serial number? I guess it makes
them easy to revoke, if a single revocation can kill 313 certs at once.

Peter.

[Rob Stradling]

On 01/09/16 11:18, Peter Gutmann wrote:
> Rob Stradling <rob.st...@comodo.com> writes:
>
>> https://crt.sh/?serial=056d1570da645bf6b44c0a7077cc6769&iCAID=1662 says
>> "Not Revoked" three times. I wonder if that's causing some confusion here.
>
> Just to make sure I'm not misreading this in some way, is this really saying
> there are 313 certs issued all with the same serial number?

Yes, it's really saying that.

> I guess it makes them easy to revoke, if a single revocation can kill 313
> certs at once.

That's true. It'd be impossible to revoke (via CRL and/or OCSP) a
subset of those 313 certs though.

[Peter Gutmann]

Rob Stradling <rob.st...@comodo.com> writes:

>>I guess it makes them easy to revoke, if a single revocation can kill 313
>>certs at once.
>
>That's true.

Hey, WoSign has solved the CRL scalability problem!

>It'd be impossible to revoke (via CRL and/or OCSP) a subset of those 313
>certs though.

I also get the feeling that a lot of PKI software won't handle the revocation
properly, because they're expecting to revoke *the* certificate, not the
certificate, and the other certificate, and that other one there too, and that
one in the corner, and ... . In other words I'm assuming most code will treat
serial numbers as unique and assume the revocation acted on when the first
cert has been marked as invalid.

Peter.

[Rob Stradling]

On 01/09/16 11:29, Peter Gutmann wrote:
> Rob Stradling <rob.st...@comodo.com> writes:
>
>>> I guess it makes them easy to revoke, if a single revocation can kill 313
>>> certs at once.
>>
>> That's true.
>
> Hey, WoSign has solved the CRL scalability problem!

If WoSign have discovered a way to know, at time of issuance, that a
cert will need to be revoked, then yes, yes they have. ;-)

>> It'd be impossible to revoke (via CRL and/or OCSP) a subset of those 313
>> certs though.
>
> I also get the feeling that a lot of PKI software won't handle the revocation
> properly, because they're expecting to revoke *the* certificate, not the
> certificate, and the other certificate, and that other one there too, and that
> one in the corner, and ... . In other words I'm assuming most code will treat
> serial numbers as unique and assume the revocation acted on when the first
> cert has been marked as invalid.

That could well be true.

[Richard Barnes]

On Thu, Sep 1, 2016 at 6:35 AM, Rob Stradling <rob.st...@comodo.com>
wrote:

In practice, I would actually expect this not to be an issue. Typically,
your PKI stack is looking at whether a single certificate has been revoked,
in which case it will never know about all the others.

--Richard

>
>
> --
> Rob Stradling
> Senior Research & Development Scientist
> COMODO - Creating Trust Online
>

[Eddy Nigg]

On 09/01/2016 01:29 PM, Peter Gutmann wrote:
> I also get the feeling that a lot of PKI software won't handle the revocation
> properly, because they're expecting to revoke *the* certificate, not the
> certificate, and the other certificate, and that other one there too, and that
> one in the corner, and ... . In other words I'm assuming most code will treat
> serial numbers as unique and assume the revocation acted on when the first
> cert has been marked as invalid.
>

From my experience, once one of the certificates has been revoked, it's
basically for all of them with the same serial and issuer. At the PKI
all certificates with the same serial must be revoked however to get a
unique serial order.

[Ben Laurie]

On 1 September 2016 at 11:29, Peter Gutmann <pgu...@cs.auckland.ac.nz> wrote:
> Rob Stradling <rob.st...@comodo.com> writes:
>
>>>I guess it makes them easy to revoke, if a single revocation can kill 313
>>>certs at once.
>>
>>That's true.
>
> Hey, WoSign has solved the CRL scalability problem!
>

>>It'd be impossible to revoke (via CRL and/or OCSP) a subset of those 313
>>certs though.
>

> I also get the feeling that a lot of PKI software won't handle the revocation
> properly, because they're expecting to revoke *the* certificate, not the
> certificate, and the other certificate, and that other one there too, and that
> one in the corner, and ... . In other words I'm assuming most code will treat
> serial numbers as unique and assume the revocation acted on when the first
> cert has been marked as invalid.

That seems unlikely to me (in that browsers don't really keep a server
cert database).

[Kyle Hamilton]

Has that changed? I talked with Dan Veditz (at Mozilla) around 5 years
ago regarding the fact that NSS had told me of duplicate serial numbers
being issued by a single issuer, and that as a result Firefox had
refused to permit me to connect to a site and also refused to allow me
to examine the certificate or identify it issuer for myself. I had to
use OpenSSL to get it. His action item at the time was to increase
reportability of those issues to Mozilla, because (paraphrased from his
words) "a CA issuing duplicate serial numbers is a violation of all of
the specifications and we need to know about it, to figure out what else
they're doing wrong".

(That was during a conversation where I told him I'd come up with a
means of putting multiple end-entity certs into the TLS Certificate
message, in a way that proved possession of all of them but which would
break strict PKIX formatting of that message's content.)

-Kyle H

[Paul Wouters]

On Tue, 6 Sep 2016, Kyle Hamilton wrote:

>> That seems unlikely to me (in that browsers don't really keep a server
>> cert database).
>
> Has that changed? I talked with Dan Veditz (at Mozilla) around 5 years
> ago regarding the fact that NSS had told me of duplicate serial numbers
> being issued by a single issuer, and that as a result Firefox had
> refused to permit me to connect to a site and also refused to allow me
> to examine the certificate or identify it issuer for myself. I had to
> use OpenSSL to get it. His action item at the time was to increase
> reportability of those issues to Mozilla, because (paraphrased from his
> words) "a CA issuing duplicate serial numbers is a violation of all of
> the specifications and we need to know about it, to figure out what else
> they're doing wrong".

I recently ran into this when NSS rejected an IPsec client certificate
after a libreswan ipsec software upgrade. The upgrade replaced openswan
which used custom X.509 code and did not use NSS and it did accept the
certificate with duplicate serial number.

For IPsec, a seperate non-system NSS store is used, so I don't know
how browsers handle this, but the NSS code is there to reject it _if_
it encounters this.

Paul

[Rob Stradling]

See also: https://bugzilla.mozilla.org/show_bug.cgi?id=435013

[Ben Laurie]

On 6 September 2016 at 18:49, Kyle Hamilton <aero...@gmail.com> wrote:
>
>
> On 9/6/2016 04:59, Ben Laurie wrote:
>> On 1 September 2016 at 11:29, Peter Gutmann <pgu...@cs.auckland.ac.nz> wrote:
>>> Rob Stradling <rob.st...@comodo.com> writes:
>>>
>>>>> I guess it makes them easy to revoke, if a single revocation can kill 313
>>>>> certs at once.
>>>> That's true.
>>> Hey, WoSign has solved the CRL scalability problem!
>>>
>>>> It'd be impossible to revoke (via CRL and/or OCSP) a subset of those 313
>>>> certs though.
>>> I also get the feeling that a lot of PKI software won't handle the revocation
>>> properly, because they're expecting to revoke *the* certificate, not the
>>> certificate, and the other certificate, and that other one there too, and that
>>> one in the corner, and ... . In other words I'm assuming most code will treat
>>> serial numbers as unique and assume the revocation acted on when the first
>>> cert has been marked as invalid.

>> That seems unlikely to me (in that browsers don't really keep a server
>> cert database).
>
> Has that changed? I talked with Dan Veditz (at Mozilla) around 5 years
> ago regarding the fact that NSS had told me of duplicate serial numbers
> being issued by a single issuer, and that as a result Firefox had
> refused to permit me to connect to a site and also refused to allow me
> to examine the certificate or identify it issuer for myself.

I am not an expert on NSS. However I could believe that it used a
certificate cache indexed by serial number/issuer...
(https://bugzilla.mozilla.org/show_bug.cgi?id=312732#c6 seems to
confirm this).

That would fail safe in this case.

> I had to
> use OpenSSL to get it. His action item at the time was to increase
> reportability of those issues to Mozilla, because (paraphrased from his
> words) "a CA issuing duplicate serial numbers is a violation of all of
> the specifications and we need to know about it, to figure out what else
> they're doing wrong".
>