SUMMARY:
On November 11th (1,2) and 12th of 2015 the Google ‘pilot’ and ‘aviator’ logs logged a total of three certificates with invalid signatures. This represented a violation of section 3.1 of RFC 6962 which states:
Logs MUST verify that the submitted end-entity certificate or Precertificate has a valid signature chain leading back to a trusted root CA certificate, using the chain of intermediate CA certificates provided by the submitter.
This was a result of a bug in where a 'fail-open' existed in cases where the chain being added contained an unsupported signature algorithm.
While this did not impact users and was not exploited beyond the inclusion of the three spam entries it exposed these two logs to the risks that come with the unnecessary processing of spam. Those being potential DoS, degraded data quality, database storage hitting quota, etc.
The issue was resolved in production by November 17th, 2015.
IMPACT:
In November of 2015 three certificates with invalid signatures were included in the ‘Pilot’ and ‘Aviator’ logs.
As a result of this defect an attacker would have potentially been able to SPAM the logs which could have negatively affected log availability.
ROOT CAUSE:
A refactoring of the code base was made on September 29th, 2015 which was intended to improve error handling. This change in the way errors were handled resulted in requests with invalid signatures falling into a code path intended for non-critical errors; thus the associated certificates were added to the log.
REMEDIATION AND PREVENTION:
To prevent similar incidents in future, we have improved the error handling of the associated code added test coverage for this specific case to ensure this specific condition does not occur again.
ADDITIONAL DETAILS:
It is our practice to immediately release a public incident report once a post-mortem is completed. In this particular case, though the post-mortem was completed immediately after incident resolution, the incident report was not immediately released. This oversight was a result of staffing change and hand-over related issues.
So do you think that absent Peter's email the disclosure would have never happened?
It was entirely my oversight that this did not go out sooner but it would have gone out.
Given that these logs have failed to abide by a MUST criteria in RFC6962, does
Chromium intend to remove these logs from the trusted set? If not, why not?
It is your browser, you give it away, you can do what you want.I haven't seen anything in the policy, nor discussions, that allow any lattitude.
I believe RFC non-compliance is a greater issue than some downtime that other logs have had.
In the interests of transparency, you should update the policy to include the fact that value judgements will come into play if that is, in fact, the case.
You are right, there is a section on Policy violations that I had forgotten about. It's three sentences say exactly what I was asking for. I apologize.The non-compliance can never be expunged from the logs. Some missing uptime can be corrected. What was the true effect of the latter? And what were the measurements?
I understand the importance of uptime and its potential impact. Without seeing detailed reports, I do not believe that the downtime for all those logs was impactful. Your software, your rules, YMMV.Even if MMD were blown, once, is it really any worse than non-compliant certs in a log? Again, see above.
--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/fed5588a-e40b-f0d6-139d-d15d3e80067f%40comodo.com.
I'm just interested in what lessons we can all learn from this incident/response. Whilst it's possible that your's was the first "failed handover" in the history of CT, I'm sure it won't be the last!
--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/CACvaWvYVK8jprBbW5YDDrerj_U9v6brBDOajtgav_0MJ1FYvHw%40mail.gmail.com.
--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/d734f65d-8f01-4344-6446-91a13e85b7f6%40comodo.com.
I tried quoting but the Google Groups interface is so reprehensibly awful I gave up.
Rob FWIW ninety days would make sense to me, but the same real world we live in that may make an otherwise responsible organisation like Google fail to respond in ninety days could also see you forget to do anything after the deadline expires. In light of that just announcing publicly may be more practical, particularly whenever the thing you're publishing doesn't seem to represent a real immediate danger to the web PKI or to security generally. Just one less thing to remember that way.
--
You received this message because you are subscribed to the Google Groups "Certificate Transparency Policy" group.
To unsubscribe from this group and stop receiving emails from it, send an email to ct-policy+...@chromium.org.
To post to this group, send email to ct-p...@chromium.org.
To view this discussion on the web visit https://groups.google.com/a/chromium.org/d/msgid/ct-policy/04d5a47a-e6ce-40df-8ce7-1bb65a78230d%40chromium.org.