Responding to Ryan, Nick and Gerv: > What's unclear is what steps GoDaddy has taken to remedy this. > > For example: > 1) Disabling domain control demonstrations through the use of a file on a > server > 2) Switching to /.well-known/pkivalidation > 3) Ensuring that the random value is not part of the HTTP[S] request > > etc > > Could you speak further to how GoDaddy has resolved this problem? My > hope is that it doesn't involve "Only look for 200 responses" =)
Our process for verifying domain control via a change to the website worked by generating a random alphanumeric code. The code was then placed in a file in the root directory of the website. The structure of the filename is <code>.html. Our system queries for that URL and looks for the code in the response. Our initial response as reported yesterday was to fix the bug introduced in July. Based on internal discussions and comments here, as of 12 midnight PST last night (1/11) we stopped using this method of file based domain control validation. > Has GoDaddy been following ACME > https://datatracker.ietf.org/wg/acme/charter/ development, either with a > view to eventually implementing ACME, or just to learn the same lessons > about automating domain validation ? We are aware of the work being done on ACME. We’ll continue to watch its development and evolution. Our current focus is on implementing the new domain validation processes published by the CAB Forum. > Perhaps the most surprising thing the ACME WG discovered was that due to > a common misconfiguration customers sharing a bulk host can often answer > HTTPS requests for other people's sites that haven't for whatever reason > enabled SSL yet. GoDaddy's validation method as described would be > vulnerable to this problem. Can you say what, if anything, GoDaddy does to > avoid being tricked into issuing a certificate on this basis ? Here is what we were doing to prevent this: When performing the domain control check over HTTPS, we validate the certificate – including verifying that the domain name of the site matches one in the cert and that the cert chains to a root in the Java root store – and the check fails if the certificate does not validate. > As you will know, the method being used by GoDaddy here corresponds > broadly to method 3.2.2.4.6 from ballot 169 - "Agreed-Upon Change to > Website". (Although this method is not currently in the Baseline > Requirements due to it being part of ballot 182 and having a related IPR > disclosure, at least one root store operator has suggested they are going to > require strict adherence to the methods listed in that ballot by 1st March.) > https://cabforum.org/2016/08/05/ballot-169-revised-validation- > requirements/ > > One of the sentences in 3.2.2.4.6 is the following: > > "The entire Required Website Content MUST NOT appear in the request > used to retrieve the file or web page" > > This sentence is there precisely because the problem which hit GoDaddy was > anticipated when the Validation WG was discussing the possible problems > with this validation method. > > Has GoDaddy already, or is GoDaddy planning to, update its implementation > to conform to that requirement? GoDaddy was on track to implement the new requirements prior to March 1, but we hope to be able to implement them even sooner than that date. > > We are currently unaware of > > any malicious exploitation of this bug to procure a certificate for a > > domain that was not authorized. > > Does that mean "we have revalidated all the domains", or does it mean "no- > one has actively reported to us that someone else is using a certificate for a > domain name the reporter owns"? As soon as we learned of this issue, we went through every certificate that was validated with the HTML method utilized during this period and attempted to verify. If it could not be immediately verified, we revoked the certificate. > > The customer who discovered the bug > > revoked the certificate they obtained, and subsequent certificates > > issued as the result of requests used for testing by Microsoft and > > GoDaddy have been revoked. > > I would hope and assume that such testing was done using domains owned > by Microsoft and/or GoDaddy, or someone else whose permission you had > gained? Yes, testing was done using domains registered by Microsoft and GoDaddy employees. > > authorization). We have re-verified domain control on every > > certificate issued using this method of validation in the period from > > when the bug was introduced until it was fixed. > > How was that possible for all domains, as surely some domain owners will > have taken the necessary file down? When we learned of this issue, we re-validated every affected certificate. If we were unable to properly validate, we revoked the certificate. That is how we got the total of 8,951 revoked certificates. > > A list of 8850 > > potentially unverified certificates (representing less than 2% of the > > total issued during the period) was compiled at 10 PM PST on Monday > > Jan 9th. > > How were you able to create that list? Do you store the HTTP status code and > content returned from the website, and just searched for non-200 codes? Or > some other way? As soon as we discovered the bug, we ran a report to identify every certificate that didn’t fail the domain validation check during the period the bug was active. We then started scanning websites to see which ones were able to re-pass the proper validation check. If they passed, we removed the certificate from the list. If we were unable to revalidate the certificate, we revoked it. If there was any question if the certificate was properly verified, we revoked it. _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
