Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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 >

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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 > >

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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: > > > > > >

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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.

Re: Potential problem with ACME TLS-SNI-01 validation

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: Changes to CA Program - Q1 2018

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: Changes to CA Program - Q1 2018

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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, >>

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: Changes to CA Program - Q1 2018

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

RE: Changes to CA Program - Q1 2018

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

RE: Changes to CA Program - Q1 2018

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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 >

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

RE: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

> 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

Incident report: Failure to verify authenticity for some partner requests

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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

Re: 2018.01.09 Issue with TLS-SNI-01 and Shared Hosting Infrastructure

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 >

Re: Incident report: Failure to verify authenticity for some partner requests

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: >