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
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
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
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
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
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
> 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
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
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
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
>
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
@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
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
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
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
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
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
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
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
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
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
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
22 matches
Mail list logo