At approximately 5 p.m. Pacific time on January 9, 2018, we received a report
from Frans Rosén of Detectify outlining a method of exploiting some shared
hosting infrastructures to obtain certificates for domains he did not control,
by making use of the ACME TLS-SNI-01 challenge type. We quickly
On 10/01/18 02:26, j...@letsencrypt.org wrote:
> We've received a credible report of a problem with ACME TLS-SNI-01 validation
> which could allow people to get certificates they should not be able to get.
> While we investigate further we have disabled tls-sni-01 validation.
>
> We'll post more
Hi Kathleen,
Is the same process used for existing CAs that need to add a new root and new
CAs applying for the first time?
Doug
> -Original Message-
> From: dev-security-policy [mailto:dev-security-policy-
> bounces+doug.beattie=globalsign@lists.mozilla.org] On Behalf Of Kathleen
On Wed, Jan 10, 2018 at 01:33:20AM -0800, josh--- via dev-security-policy wrote:
> * Users have the ability to upload certificates for arbitrary names without
> proving domain control.
So a user can always take over the domain of an other user on
those providers just by installing a (self-signed
Hello,
On Wed, Jan 10, 2018 at 4:15 PM, Kurt Roeckx via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Wed, Jan 10, 2018 at 01:33:20AM -0800, josh--- via dev-security-policy
> wrote:
> > * Users have the ability to upload certificates for arbitrary names
> without provin
First of all: Thanks for the transparency, the detailed report and quick
response to this incident.
A user on Hacker News brought up the possibility that the fairly popular
DirectAdmin control panel might also demonstrate the problematic
behaviour mentioned in your report[1].
I successfully repro
On 10/01/2018 14:15, Kurt Roeckx wrote:
On Wed, Jan 10, 2018 at 01:33:20AM -0800, josh--- via dev-security-policy wrote:
* Users have the ability to upload certificates for arbitrary names without
proving domain control.
So a user can always take over the domain of an other user on
those prov
On 10/01/18 00:23, Kathleen Wilson wrote:
> I would like to thank Aaron Wu for all of his help on our CA Program,
> and am sorry to say that his last day at Mozilla will be January 12. I
> have appreciated all of Aaron’s work, and it has been a pleasure to work
> with him.
Seconded.
> I think thi
On Wednesday, January 10, 2018 at 3:34:51 PM UTC+1, Jakob Bohm wrote:
> Depending on exactly how the shared web server is misconfigured
I don't think the web server is misconfigured: serving a self signed cert for
any domain - even one that I don't own - is something that is absolutely valid
and
On 10/01/18 14:34, Jakob Bohm wrote:
> Enforcement on shared hosting systems would be easier if the TLS-SNI-01
> ACME mechanism used names such as
> 1234556-24356476._acme.requested.domain.example.com
> since that would allow hosting providers to restrict certificate uploads
> that claim to be fo
On 10/01/2018 16:38, ssimon.g...@gmail.com wrote:
On Wednesday, January 10, 2018 at 3:34:51 PM UTC+1, Jakob Bohm wrote:
Depending on exactly how the shared web server is misconfigured
I don't think the web server is misconfigured: serving a self signed cert for
any domain - even one that I do
On Wed, Jan 10, 2018 at 10:35 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Hosting providers can simply refuse to accept uploads of any certificate
> which contains names ending in "acme.invalid".
>
> AIUI, this is Let's Encrypt's recommended miti
I applaud LetsEncrypt for disclosing rapidly and thoroughly.
During the period after the initial announcement and before the full
report, I quickly read the ACME spec portion pertaining to TLS-SNI-01.
I had not previously read the details of that validation method as that
method was not once I in
On 10/01/18 17:04, Matthew Hardeman wrote:
> That seems remarkably deficient. No other validation mechanism which is
> accepted by the community relies upon specific preventative behavior by any
> number of random hosting companies on the internet.
I don't think that's true. If your hosting provi
On Wed, Jan 10, 2018 at 11:24 AM, Gervase Markham via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> I don't think that's true. If your hosting provider allows other sites
> to respond to HTTP requests for your domain, there's a similar
> vulnerability in the HTTP-01 check
On Wed, Jan 10, 2018 at 10:39 AM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Wed, Jan 10, 2018 at 11:24 AM, Gervase Markham via dev-security-policy <
> dev-security-policy@lists.mozilla.org> wrote:
>
> >
> > I don't think that's true. If your host
Is the same process used for existing CAs that need to add a new root and new
CAs applying for the first time?
Yes.
From
https://wiki.mozilla.org/CA/Application_Process#Process_Overview
""
The same process is used to request:
- Root certificate inclusion for all CAs, even if the CA already has
On Wed, Jan 10, 2018 at 12:00 PM, Wayne Thayer wrote:
> ficant difference here. At a minimum the original request
>> arrives on port 80 and with a proper Host: header identifying the target
>> website to be validated. Yes, it's possible that your host redirects
>> that,
>> but presumably you th
Thanks Kathleen. I only asked because you are trying to reduce the manpower
for processing applications, and if a CA was already in the program there might
not be a need to do as much. But on the other hand, this forces us to all
comply with those pesky set of questions in "CA/Forbidden or Pro
On 1/10/18 10:52 AM, Doug Beattie wrote:
Thanks Kathleen. I only asked because you are trying to reduce the manpower for
processing applications, and if a CA was already in the program there might not be a need
to do as much. But on the other hand, this forces us to all comply with those pesk
On Wed, Jan 10, 2018 at 1:51 PM, Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> I acknowledge that the TLS-SNI-02 improvements do eliminate certain risks
> of the TLS-SNI-01 validation method -- and they do at least restore a
> promise that the answering
On Wednesday, January 10, 2018 at 1:33:31 AM UTC-8, jo...@letsencrypt.org wrote:
> At approximately 5 p.m. Pacific time on January 9, 2018, we received a report
> from Frans Rosén of Detectify outlining a method of exploiting some shared
> hosting infrastructures to obtain certificates for domain
On Wed, 10 Jan 2018 15:10:41 +0100
Patrick Figel via dev-security-policy
wrote:
> A user on Hacker News brought up the possibility that the fairly
> popular DirectAdmin control panel might also demonstrate the
> problematic behaviour mentioned in your report[1].
Although arguably tangential to t
Hi everyone,
There was a bug in our OEM integration that led to a lapse in the
verification of authenticity of some OV certificate requests coming in
through the reseller/partner system.
As you know, BR 3.2.5 requires CAs to verify the authenticity of a request
for an OV certificate through
On Wed, Jan 10, 2018 at 2:38 PM, Ryan Sleevi wrote:
>
> I think it's important to point out that these levels of technical
> discussions are best directed to the IETF ACME WG, under the auspices of
> the IETF NoteWell - https://datatracker.ietf.org/wg/acme/about/
>
Noted. If you think there's
I agree with Nick's questions, and I can certainly see the relevance in
matching what actually happens out there to the effectiveness and
appropriateness of the various domain validation mechanisms.
Having said that, I think it should effectively be a "read only" affair,
shaping community and CA r
As another tangent question on the advisability of resuming the TLS-SNI-01
validation method, can/will Let's Encrypt share any data on prevalence of
the various validation mechanisms over time and how they stack up against
each other in terms of prevalence. Also, it might be helpful to know
attemp
On Wed, Jan 10, 2018 at 4:37 PM, Matthew Hardeman
wrote:
>
> In the exact text above, what I meant by "create the proper zone in
> .acme.invalid" was to create that web hosting context (or actually set of
> web hosting contexts) and bind to the Host names that are the
> z(i)[0...32].z(i)[33...64].
> For comparison of "What could be worse", you could imagine a CA using the
> .10 method to assert the Random Value (which, unlike .7, is not bounded in
its
> validity) is expressed via the serial number. In this case, a CA could
validate a
> request and issue a certificate. Then, every 3 years (o
On Wed, Jan 10, 2018 at 3:57 PM, Ryan Sleevi wrote:
>
>
> Note that the presumptive discussion re: .well-known has ignored that the
> Host header requirements are underspecified, thus the fundamental issue
> still exists for that too. That said, there absolutely has been both
> tension regarding
You've just triggered me with an early 2000s flashback.
Now I can't get that "So fresh and so clean, clean..." rap line out of my
head from OutKast's "So Fresh, So Clean".
On Wed, Jan 10, 2018 at 4:11 PM, Tim Hollebeek
wrote:
>
>
> My "Freshness Value" ballot should fix this, by requiring that
On 10/01/2018 23:53, Matthew Hardeman wrote:
On Wed, Jan 10, 2018 at 3:57 PM, Ryan Sleevi wrote:
Note that the presumptive discussion re: .well-known has ignored that the
Host header requirements are underspecified, thus the fundamental issue
still exists for that too. That said, there absol
On 10/01/2018 18:39, Matthew Hardeman wrote:
Here again, I think we have a problem. It's regarded as normal and
acceptable at many web host infrastructures to pre-stage sites for
domain-labels not yet in use to allow for development and test deployment.
Split horizon DNS or other in-browser or
On Wed, Jan 10, 2018 at 6:35 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
> Agree.
>
> Hence my suggestion that TLS-SNI-0next use a name under the customer's
> domain (such as the name used for DNS-01), not a name under .invalid.
I thought it had been p
On Wed, Jan 10, 2018 at 5:53 PM, Matthew Hardeman
wrote:
> For comparison of "What could be worse", you could imagine a CA using the
>> .10 method to assert the Random Value (which, unlike .7, is not bounded in
>> its validity) is expressed via the serial number. In this case, a CA could
>> valid
On Wednesday, January 10, 2018 at 6:17:34 PM UTC-6, Ryan Sleevi wrote:
> On Wed, Jan 10, 2018 at 5:53 PM, Matthew Hardeman
> wrote:
> >
> > That, indeed, is a chilling picture. I'd like to think the community's
> > response to any such stretch of the rules would be along the lines of "Of
> > cour
Thank you for the report Tim. I just created
https://bugzilla.mozilla.org/show_bug.cgi?id=1429639 to track this issue.
Please follow up in the bug and on this thread.
- Wayne
On Wed, Jan 10, 2018 at 2:24 PM, Tim Hollebeek via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
>
On Wed, Jan 10, 2018 at 05:24:41PM +, Gervase Markham via
dev-security-policy wrote:
> On 10/01/18 17:04, Matthew Hardeman wrote:
> > That seems remarkably deficient. No other validation mechanism which is
> > accepted by the community relies upon specific preventative behavior by any
> > num
On 11/01/2018 01:08, Ryan Sleevi wrote:
On Wed, Jan 10, 2018 at 6:35 PM, Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
Agree.
Hence my suggestion that TLS-SNI-0next use a name under the customer's
domain (such as the name used for DNS-01), not a name under
On Thu, Jan 11, 2018 at 2:46 AM Jakob Bohm via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On 11/01/2018 01:08, Ryan Sleevi wrote:
> > On Wed, Jan 10, 2018 at 6:35 PM, Jakob Bohm via dev-security-policy <
> > dev-security-policy@lists.mozilla.org> wrote:
> >>
> >> Agree.
On Thu, Jan 11, 2018 at 1:36 AM Matthew Hardeman via dev-security-policy <
dev-security-policy@lists.mozilla.org> wrote:
> On Wednesday, January 10, 2018 at 6:17:34 PM UTC-6, Ryan Sleevi wrote:
> > On Wed, Jan 10, 2018 at 5:53 PM, Matthew Hardeman
> > wrote:
> > >
> > > That, indeed, is a chillin
On Wed, Jan 10, 2018 at 10:42 PM, Ryan Sleevi wrote:
>
>
> I do not know why you say that, considering the Forum explicitly decided
> to make .10 flexible as it is to accommodate both solutions.
>
> The goal was explicitly NOT to make an ideal-secure solution, it was to
> document what is practice
42 matches
Mail list logo