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 <
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
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 th
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:
>
> https://community.letsencrypt.org/t/tls-sni
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 dev-securit
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 approximatel
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 pa
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 11/01/
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 <
dev-security-policy@lists.moz
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
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 Det
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 to
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"
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
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 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 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 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 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
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 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 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 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
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 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
> 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 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].
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
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
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
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
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, 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 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
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
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 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
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 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
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 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 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/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
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
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
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
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
47 matches
Mail list logo
