Re: Incident Report – Certificates issued without proper domain validation

2017-01-24 Thread kanepyork
On Thursday, January 19, 2017 at 6:05:22 PM UTC-8, Jakob Bohm wrote: > On 20/01/2017 00:35, Nick Lamb wrote: > > On Thursday, 19 January 2017 20:20:24 UTC, Jakob Bohm wrote: > >> Google's CT initiative in its current form has serious privacy problems > >> for genuine certificate holders. I

Re: Incident Report – Certificates issued without proper domain validation

2017-01-19 Thread Jakob Bohm
On 20/01/2017 00:35, Nick Lamb wrote: On Thursday, 19 January 2017 20:20:24 UTC, Jakob Bohm wrote: Google's CT initiative in its current form has serious privacy problems for genuine certificate holders. I applaud any well-run CA that stands up to this attack on the Internet at large. I

Re: Incident Report – Certificates issued without proper domain validation

2017-01-19 Thread Nick Lamb
On Thursday, 19 January 2017 20:20:24 UTC, Jakob Bohm wrote: > Google's CT initiative in its current form has serious privacy problems > for genuine certificate holders. I applaud any well-run CA that stands > up to this attack on the Internet at large. I notice that you have not specifically

Re: Incident Report – Certificates issued without proper domain validation

2017-01-19 Thread Jakob Bohm
On 19/01/2017 01:33, montel.bahn...@gmail.com wrote: On Thursday, January 12, 2017 at 7:38:47 PM UTC-5, Itzhak Daniel wrote: Why not posting _ALL_ certificates issues via that method to CT log? We had to nag and whine for a year to get IXSystems and FreeNAS folks to finally, begrudgingly use

Re: Incident Report – Certificates issued without proper domain validation

2017-01-19 Thread montel . bahniii
On Thursday, January 12, 2017 at 7:38:47 PM UTC-5, Itzhak Daniel wrote: > Why not posting _ALL_ certificates issues via that method to CT log? We had to nag and whine for a year to get IXSystems and FreeNAS folks to finally, begrudgingly use TLS (for Download of ISOs and SHA256 no less!). The

Re: Incident Report – Certificates issued without proper domain validation

2017-01-12 Thread Itzhak Daniel
On Wednesday, January 11, 2017 at 5:03:08 AM UTC+2, Wayne Thayer wrote: > ... and will also be logged to the Google Pilot CT log. Why not posting _ALL_ certificates issues via that method to CT log? ___ dev-security-policy mailing list

RE: Incident Report – Certificates issued without proper domain validation

2017-01-12 Thread Wayne Thayer
> From: Gervase Markham [mailto:g...@mozilla.org] > Sent: Thursday, January 12, 2017 3:07 AM > To: Wayne Thayer <wtha...@godaddy.com>; mozilla-dev-security- > pol...@lists.mozilla.org > Subject: Re: Incident Report – Certificates issued without proper domain > validation &g

Re: Incident Report – Certificates issued without proper domain validation

2017-01-12 Thread Gervase Markham
Hi Wayne, Thanks for these prompt and detailed responses. On 12/01/17 00:27, Wayne Thayer wrote: > 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

Re: Incident Report – Certificates issued without proper domain validation

2017-01-11 Thread Yuhong Bao
Wayne Thayer; dev-security-policy@lists.mozilla.org; Ryan Sleevi Subject: Re: Incident Report – Certificates issued without proper domain validation 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 a

Re: Incident Report – Certificates issued without proper domain validation

2017-01-11 Thread Ryan Sleevi
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 >

Re: Incident Report – Certificates issued without proper domain validation

2017-01-11 Thread Yuhong Bao
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

RE: Incident Report – Certificates issued without proper domain validation

2017-01-11 Thread Richard Wang
@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

RE: Incident Report – Certificates issued without proper domain validation

2017-01-11 Thread Wayne Thayer
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

Re: Incident Report – Certificates issued without proper domain validation

2017-01-11 Thread Nick Lamb
On Wednesday, 11 January 2017 18:31:32 UTC, Ryan Sleevi wrote: > Because you're not required to setup the webserver for > smtp.example.com. Ah yes, silly me > I'm not saying they'd be right in arguing so I suppose that from a husbanding of resources point of view it makes sense to wait and

Re: Incident Report – Certificates issued without proper domain validation

2017-01-11 Thread Jakob Bohm
On 11/01/2017 19:17, Patrick Figel wrote: On 11/01/2017 19:06, Nick Lamb wrote: For those who haven't (unlike Patrick) sat down and read the ACME specification, ACME http-01 won't get tripped here because the checked content of the URL is very much not the random string (it's a JWS signature

Re: Incident Report – Certificates issued without proper domain validation

2017-01-11 Thread Ryan Sleevi
On Wed, Jan 11, 2017 at 10:06 AM, Nick Lamb wrote: > Why go to the bother of setting up a web server on say, smtp.example.com, > only to get yourself a certificate, and then turn off the web server and use > the certificate for SMTP? It's not impossible, but it would be

Re: Incident Report – Certificates issued without proper domain validation

2017-01-11 Thread Paul Wouters
On Wed, 11 Jan 2017, Patrick Figel wrote: On 11/01/2017 04:08, Ryan Sleevi wrote: Could you speak further to how GoDaddy has resolved this problem? My hope is that it doesn't involve "Only look for 200 responses" =) In case anyone is wondering why this is problematic, during the Ballot 169

Re: Incident Report – Certificates issued without proper domain validation

2017-01-11 Thread Patrick Figel
On 11/01/2017 04:08, Ryan Sleevi wrote: > Could you speak further to how GoDaddy has resolved this problem? My > hope is that it doesn't involve "Only look for 200 responses" =) In case anyone is wondering why this is problematic, during the Ballot 169 review process, Peter Bowen ran a check

Re: Incident Report – Certificates issued without proper domain validation

2017-01-11 Thread Gervase Markham
Hi Wayne, As others have said, thanks for bringing this to our attention. On 11/01/17 03:02, Wayne Thayer wrote: > results even when the HTTP status code was not 200. Since many web > servers are configured to include the URL of the request in the body > of a 404 (not found) response, and the

Re: Incident Report – Certificates issued without proper domain validation

2017-01-11 Thread Nick Lamb
As Ryan said, thanks for informing m.d.s.policy about this issue. I am interested in the same general area as Ryan but I will ask my question separately, feel free to answer them together. Has GoDaddy been following ACME https://datatracker.ietf.org/wg/acme/charter/ development, either with a

Re: Incident Report – Certificates issued without proper domain validation

2017-01-10 Thread Ryan Sleevi
On Tue, Jan 10, 2017 at 7:02 PM, Wayne Thayer wrote: > 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