Certificate with Debian OpenSSL bug issued

[Hanno Böck]

Hi,

A few days ago a certificate with a key vulnerable to the 2008 Debian
OpenSSL bug was issued by Telia:
https://crt.sh/?id=7799145606

It's a 4096 bit RSA key generated with a vulnerable debian version on
64 bit.

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

[Lahtiharju, Pekka]

Hi Hanno,

This is not publicly trusted TLS certificate but only Telia's test certificate. Issuer is our test issuer "Telia PreProd Server CA v3" (not publicly trusted).

Telia was testing new Badkeys/Lint implementation and we wanted to do also one test without Badkeys/Lint with vulnerable key to see if anything else would prevent such key. According to our information CT log "Dodo" that was used is non-production CT log and could be used for such tests with non-trusted TLS certificates (Mammoth and Sabre are Sectigo's production CT logs). I hope this kind of testing is OK? Or should we keep such test certificates internal only without any CT publishing?

Best Regards

Pekka Lahtiharju
Senior Development Manager | Trust Services
Telia Finland
+358407061299
pekka.la...@teliacompany.com
www.telia.fi
Telia Finland Oyj, Helsinki 1475607-9

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.
To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/20221023151433.7002479b%40computer.

This email may contain information which is privileged or protected against unauthorized disclosure or communication. If you are not the intended recipient, please notify the sender and delete this message and any attachments from your system without producing, distributing or retaining copies thereof or disclosing its contents to any other person.

Telia Company processes emails and other files that may contain personal data in accordance with Telia Company’s Privacy Policy<https://www.teliacompany.com/en/about-the-company/privacy/>.

[Hanno Böck]

On Mon, 24 Oct 2022 06:07:53 +0000
"Lahtiharju, Pekka" <pekka.la...@teliacompany.com> wrote:

> Telia was testing new Badkeys/Lint implementation and we wanted to do
> also one test without Badkeys/Lint with vulnerable key to see if
> anything else would prevent such key. According to our information CT
> log "Dodo" that was used is non-production CT log and could be used
> for such tests with non-trusted TLS certificates (Mammoth and Sabre
> are Sectigo's production CT logs). I hope this kind of testing is OK?
> Or should we keep such test certificates internal only without any CT
> publishing?

Ok, I wasn't aware up until now that crt.sh has data from pure test
logs. It seems okay from me. Though maybe crt.sh would want to indicate
this prominently to avoid confusion?

[Ben Laurie]

On Mon, 24 Oct 2022 at 07:07, 'Lahtiharju, Pekka' via dev-secur...@mozilla.org <dev-secur...@mozilla.org> wrote:

Hi Hanno,

This is not publicly trusted TLS certificate but only Telia's test certificate. Issuer is our test issuer "Telia PreProd Server CA v3" (not publicly trusted).

Telia was testing new Badkeys/Lint implementation and we wanted to do also one test without Badkeys/Lint with vulnerable key to see if anything else would prevent such key. According to our information CT log "Dodo" that was used is non-production CT log and could be used for such tests with non-trusted TLS certificates (Mammoth and Sabre are Sectigo's production CT logs). I hope this kind of testing is OK? Or should we keep such test certificates internal only without any CT publishing?

The certificate aside, having the problem suggests you were running a very ancient version of Debian - is that wise, even in test environments?

 

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/AS1PR07MB8688F4317AE188F9EFCE44C1E12E9%40AS1PR07MB8688.eurprd07.prod.outlook.com.

[Lahtiharju, Pekka]

Hi Ben,

 

We are not using Debian at all. We just took one random vulnerable key from vulnerable key archive from Debian weak key list because we wanted to test what will happen in our test code with such key. The purpose of this test was to use seriously bad key when bypassing our normal ways to detect and prevent it.

 

We didn’t expect this test key/certificate to go to any CT log that is used for CT monitoring.

 

Br Pekka

[Filippo Valsorda]

Hi,

For what it's worth, I think this kind of intentional end-to-end testing is good, and what testing CT logs and roots are for. Like negative tests, it demonstrates your pipeline actually works (and is not rejecting the bad certificates just because it's broken), and as a side effect it allowed us to test the community's ability to catch certificates issued from bad public keys.

I'm mentioning this because I want you and other CAs to feel encouraged to, not discouraged from, this kind of testing.

Agreed on maybe surfacing public trust information in crt.sh, which is available behind the Issuer click. https://crt.sh/?caid=251252

Cheers,

Filippo

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/AS1PR07MB8688A78506942360543FF0D4E12E9%40AS1PR07MB8688.eurprd07.prod.outlook.com.

[Ben Laurie]

On Mon, 24 Oct 2022 at 14:06, Filippo Valsorda <fil...@ml.filippo.io> wrote:

Hi,

For what it's worth, I think this kind of intentional end-to-end testing is good, and what testing CT logs and roots are for. Like negative tests, it demonstrates your pipeline actually works (and is not rejecting the bad certificates just because it's broken), and as a side effect it allowed us to test the community's ability to catch certificates issued from bad public keys.

I'm mentioning this because I want you and other CAs to feel encouraged to, not discouraged from, this kind of testing.

Agreed on maybe surfacing public trust information in crt.sh, which is available behind the Issuer click. https://crt.sh/?caid=251252

Agreed/

 

To view this discussion on the web visit https://groups.google.com/a/mozilla.org/d/msgid/dev-security-policy/6a844802-74ac-4026-8e32-72dd083fd506%40app.fastmail.com.

[Rob Stradling]

> Ok, I wasn't aware up until now that crt.sh has data from pure test logs.

crt.sh doesn't monitor "pure" test logs, such as Google's testtube, crucible and solera logs.

Dodo was not originally intended to be a test log (see https://github.com/sectigo/CTLogs-AcceptedRoots/tree/master/crt/dodo), but its scope has drifted a bit over time.  (In retrospect, it would have been better if we'd kept the "production" and "test" use cases restricted to separate logs).

> It seems okay from me. Though maybe crt.sh would want to indicate this prominently to avoid confusion?

I'm happy to consider concrete suggestions for what that might look like.  🙂

---

From: dev-secur...@mozilla.org <dev-secur...@mozilla.org> on behalf of Hanno Böck <ha...@hboeck.de>
Sent: 24 October 2022 08:37
To: Lahtiharju, Pekka <pekka.la...@teliacompany.com>
Cc: dev-secur...@mozilla.org <dev-secur...@mozilla.org>
Subject: Re: Certificate with Debian OpenSSL bug issued

 

CAUTION: This email originated from outside of the organization. Do not click links or open attachments unless you recognize the sender and know the content is safe.

https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fhboeck.de%2F&amp;data=05%7C01%7Crob%40sectigo.com%7C230de0bececd4aa29aa708dab5929039%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638021938342010009%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=kdD6h%2FX1j6kE8YZaZxPiNLhwKDUgL%2F1DdeSLrnM6Vl8%3D&amp;reserved=0

--
You received this message because you are subscribed to the Google Groups "dev-secur...@mozilla.org" group.
To unsubscribe from this group and stop receiving emails from it, send an email to dev-security-po...@mozilla.org.

To view this discussion on the web visit https://nam04.safelinks.protection.outlook.com/?url=https%3A%2F%2Fgroups.google.com%2Fa%2Fmozilla.org%2Fd%2Fmsgid%2Fdev-security-policy%2F20221024093706.71bd06c7%2540computer&amp;data=05%7C01%7Crob%40sectigo.com%7C230de0bececd4aa29aa708dab5929039%7C0e9c48946caa465d96604b6968b49fb7%7C0%7C0%7C638021938342010009%7CUnknown%7CTWFpbGZsb3d8eyJWIjoiMC4wLjAwMDAiLCJQIjoiV2luMzIiLCJBTiI6Ik1haWwiLCJXVCI6Mn0%3D%7C3000%7C%7C%7C&amp;sdata=z0k8m77PvHDzSzLUL%2Fo8crKIszKee18I6gIGRnkzstc%3D&amp;reserved=0.