I see that my messages to mozilla-dev-security-policy@lists.mozilla.org are not being displayed on the google group archive (I don't know why), but the messages are being delivered to the subscribers of the group. Ryan reacted on my last message to the group, which isn't available in the archive; I've pasted it here (30 days validity) https://p.6core.net/p/fqlhiWNzuwuuKOff2l8KLdWB . The original message had 9.pem as attachment but without modulus and signature to prevent people from submitting it to CT.

I don't see a Chrome bug here, though. What am I missing?

There is no Chrome bug here; Ryan Sleevi asked me to report these findings here anyway. I'm assuming there is use for this information within the team.

Do you need to keep 9.pem confidential, or can I WontFix this bug and make it public?

It needs to remain private for now, hence the embargo.

Right, awhalley is on it palmer :) Hence the SecurityEmbargo tag.

rsleevi: OK. In the future, let's not use the Chrome bug tracker for things that are not Chrome bugs. Changing the labels to get it out of the security triage queue.

Chris: In the past, we've encouraged reports of CA misissuance to be securely directed through our bug tracker, especially when it likely requires mitigating steps in the client to protect Chrome users. I don't believe we want to change that policy, but if we do, we can take that discussion offline, but it offers more privacy/security than our security@ alias.

This is a security risk to our users, per our bug reporting guidelines, and we want to continue to encourage full disclosure of details privately (under embargo), even when not appropriate to be shared publicly.

Ryan, I don't have a strong preference for the way in which we communicate - PGP mail is fine by me as well, although this tracker offers a cleaner history. From my perspective I don't see who has access to the info, but I trust you guys with that.

What I'm more interested in is what direction you plan to take this in, can you shed some light on that perhaps?

We're now in communication with the CA, who has confirmed that this certificate was issued during the timeframe communicated, which is a serious failing on multiple fronts. As far as what further steps may or will be taken, unfortunately, I can't share that until it's finalized, but this does represent a serious breach of trust on multiple fronts.

You mentioned you attempted to obtain StartEncrypt certificates from StartCom - did those also show backdating and/or SHA-1?

Would it be possible to request all of the test-certificates you issued so that we can examine if any further violations existed?

Attached is a ZIP with all the certs that we saved.

No other certs were backdated or were using SHA-1; this was purely with that combination of caID and template. We tried to reproduce shortly after disclosure (when we found out the wosign cert was actually valid by cross-signing and we noticed the backdating), but the API had been changed and we couldn't reproduce it.

We increased the number a couple of times without receiving a certificate to ensure no rate limiting was affecting the results. The names starting with "hash-" were our attempts at reproducing the results after the initial disclosure when we realized the backdated certificate was valid. We tried to get cryptographic proof that the certificates are backdated, but the functionality was already disabled then.

Deleted: all certs.zip 25.5 KB

all certs.zip 25.5 KB Download

Thanks!

In related news, in response to your disclosure, both StartCom and WoSign have publicly committed to 100% Certificate Transparency - http://www.wosign.com/english/News/2016_wosign_CT.htm and https://www.startssl.com/NewsDetails?date=20160323 - That's tracked in  Issue 626338  and   Issue 626401 

We're still finalizing data gathering about how to best protect Chrome users in response to the SHA-1 issuance.

Hi guys,

Mozilla has revived the discussion at https://www.mail-archive.com/dev-security-policy@lists.mozilla.org/msg03665.html

We normally don't disclose issues publicly like this, and we're interested to see what effects our disclosure had (positive and negative). Could you update us on what is happening on the Chrome security side?

Your disclosure is significantly appreciated. Your findings - which, due to a bug in the Mozilla listserve weren't widely noticed - have raised significant concern for a number of root store operators when they were made aware of it. Yours was not the only report we received about WoSign either, as detailed in Mozilla's report noting people choosing to report, as you have, through here to the Chrome team (and we greatly appreciate it).

Unfortunately, for a variety of reasons we can't discuss what we're considering to how to respond to this. I'm going to close this as WontFix not because we're not planning on fixing this in general, but because we don't believe there's further specific steps to take here for this incident, having alerted other root stores and having worked with WoSign to ensure the immediate issue was resolved. The longer discussion - what actions are appropriate to take and how best to protect our users.

While WoSign has requested to voluntarily have Certificate Transparency policies enforced for all of their certificates, we're still weighing whether that is the appropriate step for our users and their security, given all things.

If you should ever turn your gaze back onto the CA system, please feel free to file as many bugs as reasonable, and we'd greatly appreciate it. We are happy to coordinate disclosure to other affected root programs, as well as coordinate remediation, since there is often a dissonance between what CAs believe is necessary, and what is actually required upon them by root stores.

Leaving R-V-SE in place, although if you're comfortable with 9.pem being shared widely, we can remove that, and it'll eventually become public as the bug is auto derestricted.

Thanks for the update and for taking the issue as seriously as you have. We're okay with removing the embargo and derestricting the issue.

This bug has been closed for more than 14 weeks. Removing security view restrictions.

For more details visit https://www.chromium.org/issue-tracking/autotriage - Your friendly Sheriffbot