Hi Nick,
Sorry for the slow reply.
> -----Original Message-----
> From: Nick Lamb
> Sent: 30 July 2016 00:04
> To: mozilla-dev-security-pol...@lists.mozilla.org
>
> Hi Robin,
>
> On Friday, 29 July 2016 18:54:56 UTC+1, Robin Alden wrote:
> > We received a report of bugs in the construction of the emails we send
out
> > in order to confirm authorization by the domain name registrant prior to
> > issuing a server certificate.
> >
> > Colloquially these are known as Domain-Control Validation Emails.
>
> Indeed. A few questions arise. First about this specific occurrence, all
> questions are about the state prior to the incident. It's interesting to
hear
> about things which have changed, but my focus at first is on how things
were
> _before_ you knew about this specific problem.
>
> 1. Did Comodo grasp that these emails were a critical element of their CA
> systems? e.g. do you have a document that calls them out as being
important
> in this way and distinguishes them from marketing communications and
> other "fluff" that, though it may be important to your business, is not
vital to
> the web PKI ?
> Hmm, that's one of those 'When did you stop beating your wife?' type questions. Yes, Comodo grasps that these emails are a critical element of the CA system. We treat the sending of these emails differently from marketing communications, although that is not hard since marketing communications come from different systems. We treat the sending of these emails differently from the sending of other emails concerning the certificate lifecycle, precisely because we are aware that they are a critical piece of the validation and issuance process. > 2. Was it impressed upon the software engineers responsible for Comodo's > software which sends these emails how critical this content was ? Were they > given suitable training e.g. based on OWASP in how to make the software > secure against well-known risks like this ? > Yes, the development team that maintains the CA software use a development process that includes review of all code by staff with experience and training in secure coding techniques. > 3. Had Comodo engaged a third party to conduct penetration testing of their > web site https://secure.comodo.com/ ? How often was this testing > done ? Yes. We are required to have this done at least annually. > If so, did that engagement include > these emails as part of the system to be tested ? These emails were generated, sent, received by, and interacted with by the pen testers as part of the pen test. Could we have drawn more attention to these emails for the pen testers as a special area of interest, and will we do so in the future? - yes. > > 4. How long had this bug been present in your production systems, and to > what certainty do you know this answer ? > Since Jan 23rd, 2015. The date is tracked as part of the change control system. > > https://thehackerblog.com/keeping-positive-obtaining-arbitrary-wildcard- > ssl- > > certificates-from-comodo-via-dangling-markup-injection/index.html > > Thanks for the link. > > > We are pleased to report that no certificates were issued contrary to the > > terms of our CPS. > > Two more, this time from the point of view of Comodo after the problem > was reported: > > 5. What methods were actually used to determine whether any certificates > had been issued contrary to the terms? Were those methods independent > of the specific technique used in this incident, or did they assume that this > method was the only possible means by which certificates might be mis- > issued by Comodo at this time ? > Our investigation covered the effects of markup injection into the DCV emails. We retain all details associated with a certificate request in a database. This data is not changed or deleted once a certificate is generated from the request. > 6. Given the timeline established in question 4, were you able to perform > such checks for the whole period affected, or only some of it ? > For the whole period. > > We will be further engaging with external security consultants to ensure > > that our systems remain secure so that we may continue to meet our policy > > obligations. > > Now a final question from the point of view of the incident having happened, > but independent of Comodo itself: > > 7. In your view what new requirements should be imposed on CAs by CA/B > or by the individual trust stores in order to reduce the risk of this sort of > incident in future, whether at Comodo or another CA ? I'm going to decline to suggest what anyone should impose. I would say that having more eyes on the code is always a good thing. Specifying a white-box pen test would be one way to have that effect. It may be the case that just not using the same pen tester twice in a row would provide an improvement in coverage for little or no increase in cost. Regards Robin
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
