RE: CT2 log signing key compromise
Yes, but only for embedded SCTs. For revocation or extension served SCTs, you could end up with different timestamps depending on how the CA is set up. On top of that, for embedded SCTs, you'd need to route the cert through a separate singing service that used the compromised key. For that to happen, either another CA compromised the log or another CA was compromised in a manner that an attacker could direct issuance through a log running the compromised key. Digging into our logs, I think the log should be distrusted for everything after 17:00:02 on May 2. This was the last known good treehead. That head was published at 5:00:00 on Sunday, May 3. All SCTs after this don't appear in a reliable tree. Jeremy -Original Message- From: dev-security-policy On Behalf Of Corey Bonnell via dev-security-policy Sent: Sunday, May 3, 2020 6:42 PM To: Mozilla Subject: Re: CT2 log signing key compromise On Sunday, May 3, 2020 at 7:35:44 PM UTC-4, Alex Cohn wrote: > Thank you for the clarification. This would appear to introduce a new > requirement for clients verifying SCTs from CT2: a get-proof-by-hash > call to the log server (or a mirror) is now required to know if a SCT > from before May 2 is valid. Do CT-enforcing clients do this in practice today? > (I suspect the answer is "no" but don't know off the top of my head) Alternatively, if SCTs from other trusted CT logs are available for a given certificate (which would be the case with certificates that comply with Google/Apple policy by embedding the requisite number of SCTs in the final certificate), the timestamps of those SCTs could be used to determine if the CT2 SCT was signed before the key was compromised. Thanks, Corey ___ 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: CT2 log signing key compromise
The key could be easily used if the attacked exported the key and started signing SCTs. However, they would be able to use it to sign SCTs in DigiCert’s log for fake certs without knowing the full infrastructure. We will definitely have a full post-mortem on the issue. However, I wanted to post early to give everyone a head’s up about the incident and allow the browsers to take any action required in protecting relying parties. I can say we reacted to the vulnerability when we were notified by Salt that it impacted our system. However, I’m not sure why we were not notified and did not react to the media publication when it first came out. That is a question we are digging into. From: Ian Carroll Sent: Sunday, May 3, 2020 5:55 PM To: Jeremy Rowley Cc: Mozilla Subject: Re: CT2 log signing key compromise Hi Jeremy, Can you clarify why you believe the signing key cannot be easily used? Is there a cryptographic limitation in what was disclosed? Also, do you have plans for a more formal post-mortem? Since vulnerability management is usually an organization-wide process, it would be useful to understand why it failed here, in the event it could have carried over to other DigiCert infrastructure. Thanks, Ian Carroll On Sun, May 3, 2020 at 4:19 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: Hey all, The key used to sign SCTs for the CT2 log was compromised yesterday at 7pm through the Salt root bug. The remaining logs remain uncompromised and run on separate infrastructure. We discovered the compromise today and are working to turn that log into read only mode so that no new SCTs are issued. We doubt the key was used to sign anything as you'd need to know the CT build to do so. However, as a precaution, we ask that you consider all SCTs invalid if the SCT was issued from CT2 after 7pm MST on May 2nd . Please let me know what questions you have. Jeremy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org<mailto: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: CT2 log signing key compromise
Hi Jeremy, Can you clarify why you believe the signing key cannot be easily used? Is there a cryptographic limitation in what was disclosed? Also, do you have plans for a more formal post-mortem? Since vulnerability management is usually an organization-wide process, it would be useful to understand why it failed here, in the event it could have carried over to other DigiCert infrastructure. Thanks, Ian Carroll On Sun, May 3, 2020 at 4:19 PM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hey all, > > The key used to sign SCTs for the CT2 log was compromised yesterday at 7pm > through the Salt root bug. The remaining logs remain uncompromised and run > on separate infrastructure. We discovered the compromise today and are > working to turn that log into read only mode so that no new SCTs are > issued. We doubt the key was used to sign anything as you'd need to know > the CT build to do so. However, as a precaution, we ask that you consider > all SCTs invalid if the SCT was issued from CT2 after 7pm MST on May 2nd . > Please let me know what questions you have. > > Jeremy > ___ > 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: CT2 log signing key compromise
Emails crossed paths – I meant 6pm for the last signed head, but I’m double checking as I’m not 100% sure on that time. And you are right – since a compromised SCT can have any time it wants, only a real time check on the last known good log would be proof of a valid CT. That real time check doesn’t exist. However, there is still the multiple log requirement. From: Alex Cohn Sent: Sunday, May 3, 2020 5:35 PM To: Jeremy Rowley Cc: Mozilla Subject: Re: CT2 log signing key compromise Thank you for the clarification. This would appear to introduce a new requirement for clients verifying SCTs from CT2: a get-proof-by-hash call to the log server (or a mirror) is now required to know if a SCT from before May 2 is valid. Do CT-enforcing clients do this in practice today? (I suspect the answer is "no" but don't know off the top of my head) Alex On Sun, May 3, 2020 at 6:27 PM Jeremy Rowley mailto:jeremy.row...@digicert.com>> wrote: They would already appear in a previous tree where the head was signed by us. From: Alex Cohn mailto:a...@alexcohn.com>> Sent: Sunday, May 3, 2020 5:22 PM To: Jeremy Rowley mailto:jeremy.row...@digicert.com>> Cc: Mozilla mailto:mozilla-dev-security-pol...@lists.mozilla.org>> Subject: Re: CT2 log signing key compromise The timestamp on a SCT is fully controlled by the signer, so why should SCTs bearing a timestamp before May 2 still be considered trusted? Alex On Sun, May 3, 2020 at 6:19 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: Hey all, The key used to sign SCTs for the CT2 log was compromised yesterday at 7pm through the Salt root bug. The remaining logs remain uncompromised and run on separate infrastructure. We discovered the compromise today and are working to turn that log into read only mode so that no new SCTs are issued. We doubt the key was used to sign anything as you'd need to know the CT build to do so. However, as a precaution, we ask that you consider all SCTs invalid if the SCT was issued from CT2 after 7pm MST on May 2nd . Please let me know what questions you have. Jeremy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org<mailto: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: CT2 log signing key compromise
That is a good question though - I think the last signed head was 7pm. That would be the actual time when all other certs shouldn't be trusted... There is a problem though if you have a bad-acting CA since the notBefore date could be before 7pm and the browsers don't check to see if it was included in the tree before that time. However, that is the reason to include multiple SCTs in the same log. -Original Message- From: dev-security-policy On Behalf Of Jeremy Rowley via dev-security-policy Sent: Sunday, May 3, 2020 5:27 PM To: Alex Cohn Cc: Mozilla Subject: RE: CT2 log signing key compromise They would already appear in a previous tree where the head was signed by us. From: Alex Cohn Sent: Sunday, May 3, 2020 5:22 PM To: Jeremy Rowley Cc: Mozilla Subject: Re: CT2 log signing key compromise The timestamp on a SCT is fully controlled by the signer, so why should SCTs bearing a timestamp before May 2 still be considered trusted? Alex On Sun, May 3, 2020 at 6:19 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: Hey all, The key used to sign SCTs for the CT2 log was compromised yesterday at 7pm through the Salt root bug. The remaining logs remain uncompromised and run on separate infrastructure. We discovered the compromise today and are working to turn that log into read only mode so that no new SCTs are issued. We doubt the key was used to sign anything as you'd need to know the CT build to do so. However, as a precaution, we ask that you consider all SCTs invalid if the SCT was issued from CT2 after 7pm MST on May 2nd . Please let me know what questions you have. Jeremy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org<mailto: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 ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
Re: CT2 log signing key compromise
Thank you for the clarification. This would appear to introduce a new requirement for clients verifying SCTs from CT2: a get-proof-by-hash call to the log server (or a mirror) is now required to know if a SCT from before May 2 is valid. Do CT-enforcing clients do this in practice today? (I suspect the answer is "no" but don't know off the top of my head) Alex On Sun, May 3, 2020 at 6:27 PM Jeremy Rowley wrote: > They would already appear in a previous tree where the head was signed by > us. > > > > *From:* Alex Cohn > *Sent:* Sunday, May 3, 2020 5:22 PM > *To:* Jeremy Rowley > *Cc:* Mozilla > *Subject:* Re: CT2 log signing key compromise > > > > The timestamp on a SCT is fully controlled by the signer, so why should > SCTs bearing a timestamp before May 2 still be considered trusted? > > > > Alex > > > > On Sun, May 3, 2020 at 6:19 PM Jeremy Rowley via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > Hey all, > > The key used to sign SCTs for the CT2 log was compromised yesterday at 7pm > through the Salt root bug. The remaining logs remain uncompromised and run > on separate infrastructure. We discovered the compromise today and are > working to turn that log into read only mode so that no new SCTs are > issued. We doubt the key was used to sign anything as you'd need to know > the CT build to do so. However, as a precaution, we ask that you consider > all SCTs invalid if the SCT was issued from CT2 after 7pm MST on May 2nd . > Please let me know what questions you have. > > Jeremy > ___ > 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: CT2 log signing key compromise
They would already appear in a previous tree where the head was signed by us. From: Alex Cohn Sent: Sunday, May 3, 2020 5:22 PM To: Jeremy Rowley Cc: Mozilla Subject: Re: CT2 log signing key compromise The timestamp on a SCT is fully controlled by the signer, so why should SCTs bearing a timestamp before May 2 still be considered trusted? Alex On Sun, May 3, 2020 at 6:19 PM Jeremy Rowley via dev-security-policy mailto:dev-security-policy@lists.mozilla.org>> wrote: Hey all, The key used to sign SCTs for the CT2 log was compromised yesterday at 7pm through the Salt root bug. The remaining logs remain uncompromised and run on separate infrastructure. We discovered the compromise today and are working to turn that log into read only mode so that no new SCTs are issued. We doubt the key was used to sign anything as you'd need to know the CT build to do so. However, as a precaution, we ask that you consider all SCTs invalid if the SCT was issued from CT2 after 7pm MST on May 2nd . Please let me know what questions you have. Jeremy ___ dev-security-policy mailing list dev-security-policy@lists.mozilla.org<mailto: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: CT2 log signing key compromise
The timestamp on a SCT is fully controlled by the signer, so why should SCTs bearing a timestamp before May 2 still be considered trusted? Alex On Sun, May 3, 2020 at 6:19 PM Jeremy Rowley via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > Hey all, > > The key used to sign SCTs for the CT2 log was compromised yesterday at 7pm > through the Salt root bug. The remaining logs remain uncompromised and run > on separate infrastructure. We discovered the compromise today and are > working to turn that log into read only mode so that no new SCTs are > issued. We doubt the key was used to sign anything as you'd need to know > the CT build to do so. However, as a precaution, we ask that you consider > all SCTs invalid if the SCT was issued from CT2 after 7pm MST on May 2nd . > Please let me know what questions you have. > > Jeremy > ___ > 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
