new | show | ask | jobs Github

oasisbob 4 hours ago

More details in the now-public bugzilla issue:

https://bugzilla.mozilla.org/show_bug.cgi?id=2083449

▲

eqvinox 3 hours ago | parent | next [-]

> Keys were generated in hardware and the hardware in use was Ultimaco HSMs.

The plot thickens.

Broken HSM? Misconfiguration? Confusion? Straight up lie?

> Excel attached. The Ultimaco devices were used to generate the ECC, RSA key pairs for the issuers. They were not used to generate any other key material. But it doesnt look like the device is at fault.

> We have done some preliminary assessment, there appears to be a flaw in the KGC script that was used on that specific day to create these ECC issuers. As for these ECC keys, our review of the KGC, assessment of the code and view of HSM keys so far indicate that a) a set of original ECC keys were created onboard as expected b) an approved deviation to our usual KGC to test a wrap/unwrap was introduced as these keys were meant for export for this instance c) a flaw in the code resulted in the second pair of keys being created onboard which were weaker d) these second pair of weaker keys were used by mistake to create the csr (because the key labels were similar) and signed by our root e) the CSR from these weaker keys were also sent over to Sectigo for cross signing (we verified the files sent over to Sectigo)

…

▲

sippingabonedry 2 hours ago | parent | next [-]

> an approved deviation to our usual KGC to test

The whole point of a key ceremony is that you're not going off-script and YOLOing random crap.

▲

q3k 3 hours ago | parent | prev [-]

Reading further, it seems like they say they first generated some keys on-HSM, but then used 'test keys' (that were used to test wrap/unwrap of key material) instead by accident. Fishy.

	▲	eqvinox 3 hours ago \| parent [-]
		They used the "correct" key for signing the CRLs (which of course was then an invalid signature): > The CRL's were signed with the original private keys (which were supposed to be the correct keys with appropriate entropy) but given that this resulted in incorrect signatures, they were resigned with flawed keys. And THAT is where I'm drawing the line between "honest mistake" and "gross negligence". For that to not raise giant red flags is an unacceptable failure in process and work culture.

▲

shellcromancer 2 hours ago | parent | prev | next [-]

What a change a month makes. Public discussion on eMudhra getting their own root CA inclusion ended and Mozilla had them slated for approval.

https://bugzilla.mozilla.org/show_bug.cgi?id=1889859

▲

hypfer 3 hours ago | parent | prev | next [-]

> "The CRL's were signed with the original private keys (which were supposed to be the correct keys with appropriate entropy) but given that this resulted in incorrect signatures, they were resigned with flawed keys."

Ah yes.

"The system says something is wrong, but it's also 4.30PM. Let's just re-sign the thing and go home."

Good luck recovering from this.

▲

sippingabonedry 3 hours ago | parent | prev [-]

> The other two certificates are for codesigning and trusted by Microsoft

That seems like a WAY bigger problem than TLS, but AFAIK Windows still validates code signing certs against CRLs before trusting them (can't remember if it soft-fails).

▲

msm_ 3 hours ago | parent [-]

Why is that a way bigger problem? Windows will happily run unsigned binaries. Code signing just decreases the friction for users slightly, but is in no way required. TLS is definitely a way bigger problem.

▲

sippingabonedry 3 hours ago | parent [-]

> Windows will happily run unsigned binaries

This is absolutely false, it's a simple policy change to enforce code signing, any organization that is serious about security can do it.

I'll give you the benefit of the doubt and assume you're another Linux guy who doesn't understand Windows security.

The concern of course is with malware being signed, which is far more likely to be abused than some TLS MITM fantasy.

▲

throwaway7356 3 hours ago | parent | next [-]

> The concern of course is with malware being signed, which is far more likely to be abused than some TLS MITM fantasy.

You already need compromised systems to install malware, signed or not. Not a real problem.

For TLS MitM you just need to use a shared network, wired or wireless.

▲

tsimionescu 2 hours ago | parent | prev [-]

Plenty of major programs are not signed, and thus plenty of organizations don't enforce code signing.

	▲	sippingabonedry 2 hours ago \| parent [-]
		For the exceptions, you can sign your own using internal CA.