Hi Yuhong, Perhaps it be best if you create a separate thread for your question - it's not really clear at all how it relates to the topic at hand.
On Wed, Jan 11, 2017 at 6:08 PM, Yuhong Bao <yuhongbao_...@hotmail.com> wrote: > That is what the current certificate by Google Internet Authority says. > What I am referring to is that before Google bought Nest they used GoDaddy as > the CA. > ________________________________________ > From: Richard Wang <rich...@wosign.com> > Sent: Wednesday, January 11, 2017 5:01:08 PM > To: Yuhong Bao; Wayne Thayer; dev-security-policy@lists.mozilla.org; Ryan > Sleevi > Subject: RE: Incident Report – Certificates issued without proper domain > validation > > The nest.com certificate subject is: > CN = www.nest.com > O = Google Inc > L = Mountain View > S = California > C = US > > This means this website owned by Google Inc. Right? > > > Best Regards, > > Richard > > -----Original Message----- > From: dev-security-policy > [mailto:dev-security-policy-bounces+richard=wosign....@lists.mozilla.org] On > Behalf Of Yuhong Bao > Sent: Thursday, January 12, 2017 6:12 AM > To: Wayne Thayer <wtha...@godaddy.com>; > dev-security-policy@lists.mozilla.org; Ryan Sleevi <r...@sleevi.com> > Subject: Re: Incident Report - Certificates issued without proper domain > validation > > I wonder if nest.com is now considered high-risk now. They recently switched > from GoDaddy to Google Internet Authority. > ________________________________________ > From: dev-security-policy > <dev-security-policy-bounces+yuhongbao_386=hotmail....@lists.mozilla.org> on > behalf of Wayne Thayer <wtha...@godaddy.com> > Sent: Tuesday, January 10, 2017 7:02:28 PM > To: dev-security-policy@lists.mozilla.org > Subject: Incident Report - Certificates issued without proper domain > validation > > Summary: > On Friday, January 6th, 2017, GoDaddy became aware of a bug affecting our > domain validation processing system. The bug that caused the issue was fixed > late Friday. At 10 PM PST on Monday, Jan 9th we completed our review to > determine the scope of the problem, and identified 8850 certificates that > were issued without proper domain validation as a result of the bug. The > impacted certificates will be revoked by 10 PM PST on Tuesday, Jan 10th, and > will also be logged to the Google Pilot CT log. > Detailed Description: > On Tuesday, Jan 3rd, 2017, one of our resellers (Microsoft) sent an email to > n...@godaddy.com<mailto:n...@godaddy.com> and two GoDaddy employees. Due to > holiday vacations and the fact that the issue was not reported properly per > our CPS, we did not become aware of the issue until one of the employees > opened the email on Friday Jan 6th and promptly alerted management. The > issue was originally reported to Microsoft by one of their own customers and > was described as only affecting certificate requests when the DNS A record > of the domain was set to 127.0.0.1. An investigation was initiated > immediately and within a few hours we determined that the problem was > broader in scope. The root cause of the problem was fixed via a code change > at approximately 10 PM MST on Friday, Jan 6th. > On Saturday, January 7th, we determined that the bug was first introduced on > July 29th, 2016 as part of a routine code change intended to improve our > certificate issuance process. The bug is related to our use of practical > demonstration of control to validate authority to receive a certificate for > a given fully-qualified domain name. In the problematic case, we provide a > random code to a customer and ask them to place it in a specific location on > their website. Our system automatically checks for the presence of that code > via an HTTP and/or HTTPS request to the website. If the code is found, the > domain control check is completed successfully. Prior to the bug, the > library used to query the website and check for the code was configured to > return a failure if the HTTP status code was not 200 (success). A > configuration change to the library caused it to return results even when > the HTTP status code was not 200. Since many web servers are configured to > include the URL of the req uest in the body of a 404 (not found) response, > and the URL also contained the random code, any web server configured this > way caused domain control verification to complete successfully. > We are currently unaware of any malicious exploitation of this bug to > procure a certificate for a domain that was not authorized. 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. Further, any certificate requests made for > domains we flag as high-risk were also subjected to manual review (rather > than being issued purely based on an invalid domain 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. 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. As mentioned above, potentially impacted certificates > will be revoked by 10 PM PST on Tuesday Jan 10th and logged to a Google CT > log. Additional code changes were deployed on Monday Jan 9th and Tuesday > 10th to prevent the re-issuance of certificates using cached and potentially > unverified domain validation information. However, prior to identifying and > shutting down this path, an additional 101 certificates were reissued using > such cached and potentially unverified domain validation information, > resulting in an overall total of 8951 certificates that were issued without > proper domain validation as a result of the bug. > Next Steps: > While we are confident that we have completely resolved the problem, we are > watching our system closely to ensure that no more certificates are issued > without proper domain validation, and we will take immediate action and > report any further issues if found. A full post-mortem review of this > incident will occur and steps will be taken to prevent a recurrence, > including the addition of automated tests designed to detect this type of > scenario. If more information about the cause or impact of this incident > becomes available, we will publish updates to this report. > Wayne Thayer > GoDaddy > _______________________________________________ > 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 _______________________________________________ dev-security-policy mailing list dev-security-policy@lists.mozilla.org https://lists.mozilla.org/listinfo/dev-security-policy
