Re: Certificates with 2008 Debian weak key bug

2018-02-16 Thread Nick Lamb via dev-security-policy 
On Fri, 16 Feb 2018 11:28:41 +
Arkadiusz Ławniczak via dev-security-policy
 wrote:

>   The issue was caused by incorrect calculation of the SHA1
> fingerprint of public key. Public keys hashes stored in Certum's
> database was calculated from the Modulo key value with the Modulus
> prefix and a line ending character while the  value of public
> key from CSR was calculated and returned without these additional
> characters. So, this is the reason why the calculated fingerprint did
> not match the value from  Certum's database. Weak keys verification
> is tested each time before the new version of the software is
> deployed and also periodically as part of the test schedule.
> Unfortunately, the database of weak keys that served the tests
> contained keys hashes in incorrect formats, the parsed key was also
> in an incorrect format.   Therefore we could not recognize weak
> key in its "original" OpenSSL form. So each test returned false
> positives.

Thanks for your report Arkadiusz,

This is a reminder that just because your unit tests pass, doesn't mean
your larger system behaves how you think the unit tests mean it does. If
you want to be sure how the whole _system_ behaves (and for a CA we
certainly do want that) you're going to need to explicitly test that
whole system even if your unit tests are green.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

RE: Certificates with 2008 Debian weak key bug

2018-02-16 Thread Arkadiusz Ławniczak via dev-security-policy 
Hello ALL

Please find our incident report below.

1.  How your CA first became aware of the problem and the time and date.

1)  3 February 2018, 12:06 CET -  Certum receives the message from 
ha...@hboeck.de to rev...@certum.pl.



2.  A timeline of the actions CERTUM took in response.

1)  3 February 2018, 12:06 CET -  Certum receives the message from 
ha...@hboeck.de to rev...@certum.pl.
2)  5 February 2018, 15:37 CET and 15:56 CET - Certum informs 
subscribers (owners of *.orix.pl and ftp.gavdi.pl domains) 
about the obtained problem report.
3)  5 February 2018, 15:37 CET and 15:56 CET - Certum request 
subscribers to provide private keys checksums.
4)  5 February 2018, 16:03 CET - Certum informs Hanno Boeck that 
received the problem report.
5)  6 February 2018, 16:03 CET - Certum revokes certificates SHA1 - 
6E8B5A67417FDBDE2871A28ED7A2C30FEE686390 and SHA1 - 
882AE1C8660BB75E3311ACB0CEBCD3C3FF9167E3.
6)  6 February 2018 - Certum scans certificates database. No weak 
keys was found.
7)  6 February 2018 - Certum scans certificates database. The 
problem with validation against Debian weak key was found.
8)  8 February 2018 - Certum deploys a new version of the weak keys 
validation system.
9)  8 February 2018 - Certum Certum scans certificates database. 
The problem with validation against Debian weak key was not 
found.


3.  A summary of the problematic certificates.

The total number of certificates with the problem is 2:
1)  https://crt.sh/?id=308392091&opt=ocsp 
2)  https://crt.sh/?id=663&opt=ocsp


4.  Explanation about how and why the mistakes were made or bugs 
introduced, and how they avoided detection until now.

The issue was caused by incorrect calculation of the SHA1 fingerprint 
of public key.
Public keys hashes stored in Certum's  database was calculated from the 
Modulo key value with the Modulus prefix and a line ending character while the  
value of public key from CSR was calculated and returned without these 
additional characters. 
So, this is the reason why the calculated fingerprint did not match the 
value from  Certum's database.
Weak keys verification is tested each time before the new version of 
the software is deployed and also periodically as part of the test schedule.
Unfortunately, the database of weak keys that served the tests 
contained keys hashes in incorrect formats, the parsed key was also in an 
incorrect format.  Therefore we could not recognize weak key in its 
"original" OpenSSL form. So each test returned false positives.

5.  List of steps your CA is taking to resolve the situation and ensure 
such issuance will not be repeated in the future

Certum standardized formats of the validated and stored weak keys to be 
compliant with the following sources:

https://anonscm.debian.org/viewvc/pkg-openssl/openssl-blacklist/tags/0.5-2/blacklists/le64/blacklist-4096.db?view=co

https://anonscm.debian.org/viewvc/pkg-openssl/openssl-blacklist/tags/0.5-2/blacklists/le32/blacklist-4096.db?view=co

https://anonscm.debian.org/viewvc/pkg-openssl/openssl-blacklist/tags/0.5-2/blacklists/be32/blacklist-4096.db?view=co

https://anonscm.debian.org/viewvc/pkg-openssl/openssl-blacklist/trunk/blacklists/be32/blacklist-2048.db?view=co

https://anonscm.debian.org/viewvc/pkg-openssl/openssl-blacklist/trunk/blacklists/le32/blacklist-2048.db?view=co

https://anonscm.debian.org/viewvc/pkg-openssl/openssl-blacklist/trunk/blacklists/le64/blacklist-2048.db?view=co

https://anonscm.debian.org/viewvc/pkg-openssl/openssl-blacklist/trunk/blacklists/be32/blacklist-1024.db?view=co

https://anonscm.debian.org/viewvc/pkg-openssl/openssl-blacklist/trunk/blacklists/le32/blacklist-1024.db?view=co

https://anonscm.debian.org/viewvc/pkg-openssl/openssl-blacklist/trunk/blacklists/le64/blacklist-1024.db?view=co




--
Arkadiusz Ławniczak
Analyst 
Security and Trust Services Division
Asseco Data Systems S.A.
Biuro w Szczecinie
ul. Królowej Korony Polskiej 21
70-486 Szczecin
phone  + 48 91 480 12 32
mob. +48 669992104
arkadiusz.lawnic...@assecods.pl
assecods.pl 
Asseco Data Systems S.A. Headquarters: Podolska 21, 81-321 Gdynia/Poland. Tax 
Identification Number (NIP): 517-035-94-58. Statistical ID number (REGON): 
180853177. National Court Register: 421310 District Court in Gdańsk, VIII 
Commercial Department of the National Court Register. Share capital: 120 002 
940,00 PLN.
This information is intended only for the person or entity to which it is 
addressed and may contain confidential and/or privileged material. Unauthorised 
use of this information by person or entity other than the intended recipient 
is prohibited by law. If you received this by mistake, please im

Re: Certificates with 2008 Debian weak key bug

2018-02-06 Thread Kurt Roeckx via dev-security-policy 

On 6/02/2018 17:10, Ryan Sleevi wrote:

The BRs actually seem to allow this, which at least looks like a bug in
the BRs to me.


It is allowed, and it's not a bug. It's specifically called out in 3.2.2 of
the BRs.


It seems that under 3.2.2.3 (b) they can just copy the ccTLD from the 
domain name, which seems rather useless to me.



Kurt


___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with 2008 Debian weak key bug

2018-02-06 Thread Ryan Sleevi via dev-security-policy 
On Tue, Feb 6, 2018 at 10:48 AM, Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> On 5/02/2018 17:08, Hanno Böck wrote:
>
>> https://crt.sh/?id=308392091&opt=ocsp
>>
>
> It has:
>  Subject:
> commonName= ftp.gavdi.pl
> countryName   = PL
>
> This looks like a combination that's not allowed. Either it's domain
> validated, in which case it should not have a countryName, or it should
> contain other fields.
>
> The BRs actually seem to allow this, which at least looks like a bug in
> the BRs to me. It would be very handy that the OIDs from the BRs where used
> to indicate which validation was used.
>

It is allowed, and it's not a bug. It's specifically called out in 3.2.2 of
the BRs.
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with 2008 Debian weak key bug

2018-02-06 Thread Kurt Roeckx via dev-security-policy 

On 5/02/2018 17:08, Hanno Böck wrote:

https://crt.sh/?id=308392091&opt=ocsp


It has:
 Subject:
commonName= ftp.gavdi.pl
countryName   = PL

This looks like a combination that's not allowed. Either it's domain 
validated, in which case it should not have a countryName, or it should 
contain other fields.


The BRs actually seem to allow this, which at least looks like a bug in 
the BRs to me. It would be very handy that the OIDs from the BRs where 
used to indicate which validation was used.


It has:
X509v3 Certificate Policies:
Policy: 1.2.616.1.113527.2.5.1.9.6.3

That OID doesn't seem to be documented in the CPS.


Kurt
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with 2008 Debian weak key bug

2018-02-05 Thread Wayne Thayer via dev-security-policy 
On Mon, Feb 5, 2018 at 4:33 PM, Alex Cohn via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> I logged two of those five certificates (https://crt.sh/?id=308392091
> and https://crt.sh/?id=307753186) to Argon, as part of a project to
> log every certificate in the censys.io database to a public CT log. I
> believe Censys found them by scanning all of IPv4 and grabbing the
> default (i.e. no SNI) certificate presented on port 443.
>
> Given that this method will not uncover every certificate ever issued,
> and that Certum isn't or wasn't checking for weak keys and isn't
> logging certificates to CT, should Mozilla ask Certum to scan every
> currently-valid certificate they have issued for weak keys?
>
> Thanks for pointing this out Alex. I would like to think that this is
required by the incident report, but it's not specifically called out, so I
added this request to the bug.

Alex
>
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with 2008 Debian weak key bug

2018-02-05 Thread Alex Cohn via dev-security-policy 
I logged two of those five certificates (https://crt.sh/?id=308392091
and https://crt.sh/?id=307753186) to Argon, as part of a project to
log every certificate in the censys.io database to a public CT log. I
believe Censys found them by scanning all of IPv4 and grabbing the
default (i.e. no SNI) certificate presented on port 443.

Given that this method will not uncover every certificate ever issued,
and that Certum isn't or wasn't checking for weak keys and isn't
logging certificates to CT, should Mozilla ask Certum to scan every
currently-valid certificate they have issued for weak keys?

Alex

On Mon, Feb 5, 2018 at 2:56 PM, Hanno Böck via dev-security-policy
 wrote:
> On Mon, 5 Feb 2018 12:07:06 -0500
> Eric Mill via dev-security-policy
>  wrote:
>
>> WoSign and StartCom are untrusted, but Certum is still trusted, right?
>
> Yes.
>
> In case that was unclear: The sentence "As we all know these are no
> longer trusted by Mozilla, ..." was referring to the chapter above,
> i.e. the three Startcom+Wosign certs, not the whole mail.
>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with 2008 Debian weak key bug

2018-02-05 Thread Hanno Böck via dev-security-policy 
On Mon, 5 Feb 2018 12:07:06 -0500
Eric Mill via dev-security-policy
 wrote:

> WoSign and StartCom are untrusted, but Certum is still trusted, right?

Yes.

In case that was unclear: The sentence "As we all know these are no
longer trusted by Mozilla, ..." was referring to the chapter above,
i.e. the three Startcom+Wosign certs, not the whole mail.

-- 
Hanno Böck
https://hboeck.de/

mail/jabber: ha...@hboeck.de
GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with 2008 Debian weak key bug

2018-02-05 Thread Wayne Thayer via dev-security-policy 
I have filed https://bugzilla.mozilla.org/show_bug.cgi?id=1435770
requesting an incident report from Certum.

On Mon, Feb 5, 2018 at 10:07 AM, Eric Mill via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> WoSign and StartCom are untrusted, but Certum is still trusted, right?
>
> Yes, the two certificates issued by Certum are trusted by Mozilla.

On Mon, Feb 5, 2018 at 11:08 AM, Hanno Böck via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> > Hi,
> >
> > I searched crt.sh for valid certificates vulnerable to the 2008 Debian
> > weak key bug. (Only 2048 bit.)
> >
> > Overall I found 5 unexpired certificates.
> >
> > Two certificates by Certum (reported on Saturday, Certum told me "We
> > have taken necessary steps to clarify this situation as soon as
> > possible", they're not revoked yet):
> > https://crt.sh/?id=308392091&opt=ocsp
> > https://crt.sh/?id=663&opt=ocsp
> >
> > Wosign:
> > https://crt.sh/?id=30347743
> > StartCom:
> > https://crt.sh/?id=54187884
> > https://crt.sh/?id=307753186
> >
> > As we all know these are no longer trusted by Mozilla, I reported them
> > nevertheless. No reply yet.
> >
> > Old bugs never die, I recommend every CA adds a check for the Debian
> > bug to their certificate issuance process.
>
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy

Re: Certificates with 2008 Debian weak key bug

2018-02-05 Thread Eric Mill via dev-security-policy 
WoSign and StartCom are untrusted, but Certum is still trusted, right?

On Mon, Feb 5, 2018 at 11:08 AM, Hanno Böck via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:

> Hi,
>
> I searched crt.sh for valid certificates vulnerable to the 2008 Debian
> weak key bug. (Only 2048 bit.)
>
> Overall I found 5 unexpired certificates.
>
> Two certificates by Certum (reported on Saturday, Certum told me "We
> have taken necessary steps to clarify this situation as soon as
> possible", they're not revoked yet):
> https://crt.sh/?id=308392091&opt=ocsp
> https://crt.sh/?id=663&opt=ocsp
>
> Wosign:
> https://crt.sh/?id=30347743
> StartCom:
> https://crt.sh/?id=54187884
> https://crt.sh/?id=307753186
>
> As we all know these are no longer trusted by Mozilla, I reported them
> nevertheless. No reply yet.
>
> Old bugs never die, I recommend every CA adds a check for the Debian
> bug to their certificate issuance process.
>
> --
> Hanno Böck
> https://hboeck.de/
>
> mail/jabber: ha...@hboeck.de
> GPG: FE73757FA60E4E21B937579FA5880072BBB51E42
> ___
> dev-security-policy mailing list
> dev-security-policy@lists.mozilla.org
> https://lists.mozilla.org/listinfo/dev-security-policy
>



-- 
konklone.com | @konklone 
___
dev-security-policy mailing list
dev-security-policy@lists.mozilla.org
https://lists.mozilla.org/listinfo/dev-security-policy