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