Certificates with 2008 Debian weak key bug

[Hanno Böck]

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=6888863&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

[Eric Mill]

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

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



--
konklone.com | @konklone <https://twitter.com/konklone>

[Wayne Thayer]

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-secur...@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.

[Hanno Böck]

On Mon, 5 Feb 2018 12:07:06 -0500

Eric Mill via dev-security-policy
<dev-secur...@lists.mozilla.org> 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.

[Alex Cohn]

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

[Wayne Thayer]

On Mon, Feb 5, 2018 at 4:33 PM, Alex Cohn via dev-security-policy <
dev-secur...@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
>
>

[Kurt Roeckx]

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

[Ryan Sleevi]

On Tue, Feb 6, 2018 at 10:48 AM, Kurt Roeckx via dev-security-policy <
dev-secur...@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.

[Kurt Roeckx]

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

[Arkadiusz Ławniczak]

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=6888863&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...@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: 0000421310 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 immediately contact the sender by e-mail or by telephone and delete this information from any computer. Thank you. Asseco Data Systems S.A.

-----Original Message-----
From: dev-security-policy [mailto:dev-security-policy-bounces+arkadiusz.lawniczak=assec...@lists.mozilla.org] On Behalf Of Hanno Böck via dev-security-policy
Sent: Monday, February 5, 2018 5:08 PM
To: mozilla-dev-s...@lists.mozilla.org
Subject: Certificates with 2008 Debian weak key bug

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=6888863&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.

[Nick Lamb]

On Fri, 16 Feb 2018 11:28:41 +0000
Arkadiusz Ławniczak via dev-security-policy

<dev-secur...@lists.mozilla.org> 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.