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

It would come at the expense of a more streamlined and secure approach (e.g. the ALPN proposal on the acme-wg list), which once standardized I assume Let's Encrypt (and other ACME CAs) would want to fully migrate to. Alex On Mon, Jan 15, 2018 at 9:27 AM, Gervase Markham via dev-security-policy <

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

On 14/01/18 21:32, jacob.hoffmanandr...@gmail.com wrote: > We discussed a similar approach (using CAA) on our community forum, > and concluded we don't want to pursue it at this time: > https://community.letsencrypt.org/t/tls-sni-via-caa/50172. The TXT > record would probably work more widely than

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

On Saturday, January 13, 2018 at 12:35:47 AM UTC-8, Hector Martin 'marcan' wrote: > Would it make sense to effectively allow "self-service" whitelisting by > using a DNS TXT record? We discussed a similar approach (using CAA) on our community forum, and concluded we don't want to pursue it at

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

On 2018-01-13 12:38, josh--- via dev-security-policy wrote: > Another update, the main thing being that we have deployed patches to our CA > that allow TLS-SNI for both renewal and whitelisted accounts, as we said we > would in our previous update: > >

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

On Friday, January 12, 2018 at 9:38:42 PM UTC-6, jo...@letsencrypt.org wrote: > On Thursday, January 11, 2018 at 4:29:09 PM UTC-6, jo...@letsencrypt.org > wrote: > > On Thursday, January 11, 2018 at 3:36:50 PM UTC-6, Ryan Sleevi wrote: > > > On Wed, Jan 10, 2018 at 4:33 AM, josh--- via

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

On Thursday, January 11, 2018 at 4:29:09 PM UTC-6, jo...@letsencrypt.org wrote: > On Thursday, January 11, 2018 at 3:36:50 PM UTC-6, Ryan Sleevi wrote: > > On Wed, Jan 10, 2018 at 4:33 AM, josh--- via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > > > At

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

When I wrote my previous reply, I had not yet received Let's encrypt's post in which they announced they would not reenable TLS-SNI-01 globally. So this was written based on Let's encrypt only *temporarily* disabling TLS-SNI-01 as stated in their original post and *allegedly* (according to 3rd

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

On Fri, Jan 12, 2018 at 5:46 AM Jakob Bohm via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > On 11/01/2018 05:38, Ryan Sleevi wrote: > > On Thu, Jan 11, 2018 at 2:46 AM Jakob Bohm via dev-security-policy < > > dev-security-policy@lists.mozilla.org> wrote: > > > >> On

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

On 11/01/2018 05:38, Ryan Sleevi wrote: 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 <

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

On Thu, Jan 11, 2018 at 3:28 PM, josh--- via dev-security-policy < dev-security-policy@lists.mozilla.org> wrote: > > https://community.letsencrypt.org/t/2018-01-11-update-regard > ing-acme-tls-sni-and-shared-hosting-infrastructure/50188 > > Speaking for myself, this is an excellent game plan that

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

On Thursday, January 11, 2018 at 3:36:50 PM UTC-6, Ryan Sleevi wrote: > On Wed, Jan 10, 2018 at 4:33 AM, josh--- via dev-security-policy < > dev-security-policy@lists.mozilla.org> wrote: > > > At approximately 5 p.m. Pacific time on January 9, 2018, we received a > > report from Frans Rosén of

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

On Wed, Jan 10, 2018 at 4:33 AM, josh--- via dev-security-policy < dev-security-policy@lists.mozilla.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

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

On 10/01/18 17: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. I agree that "no unknown domain names"

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

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

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

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

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

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

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

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

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

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

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