Re: [Acme] RFC draft-ietf-acme-acme-02 - tls SNI name

2016-10-14 Thread Patrick Figel
On 14/10/16 18:53, Alan Doherty wrote: > btw in http-01 the acme client can specify to the server whether to > use http://www.domain1.com/.well-known/acme-challenge/ or > https://www.domain1.com/.well-known/acme-challenge/ directly > > "The client’s response to this challenge indicates whether i

Re: [Acme] RFC draft-ietf-acme-acme-02 - tls SNI name

2016-10-14 Thread Ilari Liusvaara
On Fri, Oct 14, 2016 at 05:07:22PM +, Ben Irving wrote: > On Fri, Oct 14, 2016 at 9:53 AM Alan Doherty wrote: > > > > btw in http-01 the acme client can specify to the server whether to use > > http://www.domain1.com/.well-known/acme-challenge/ > > or https://www.domain1.com/.well-known/acme-c

Re: [Acme] RFC draft-ietf-acme-acme-02 - tls SNI name

2016-10-14 Thread Ben Irving
On Fri, Oct 14, 2016 at 9:53 AM Alan Doherty wrote: > At 16:31 14/10/2016 Friday, Ben Irving wrote: > > > >On Thu, Oct 13, 2016 at 1:10 PM Alan Doherty < i...@alandoherty.net>i...@alandoherty.net> wrote: > >At 17:39 13/10/2016Â Thursday, Ben Irving wrote: > >>Hello, > >> > >>I have ran into a v

Re: [Acme] RFC draft-ietf-acme-acme-02 - tls SNI name

2016-10-14 Thread Alan Doherty
At 16:31 14/10/2016 Friday, Ben Irving wrote: >On Thu, Oct 13, 2016 at 1:10 PM Alan Doherty ><i...@alandoherty.net> wrote: >At 17:39 13/10/2016Â Thursday, Ben Irving wrote: >>Hello, >> >>I have ran into a very similar use case. In my case I'm using Haproxy to >>ro

Re: [Acme] RFC draft-ietf-acme-acme-02 - tls SNI name

2016-10-14 Thread Ben Irving
On Thu, Oct 13, 2016 at 1:10 PM Alan Doherty wrote: > At 17:39 13/10/2016 Thursday, Ben Irving wrote: > >Hello, > > > >I have ran into a very similar use case. In my case I'm using Haproxy to > route tcp requests based on the server name indication to upstream web > servers where the TLS request

Re: [Acme] RFC draft-ietf-acme-acme-02 - tls SNI name

2016-10-13 Thread Hugo Landau
Perhaps clients should be allowed to specify a 'routing key' when requesting that TLS-SNI validation be performed. The name used would be: x.y.ROUTING-KEY.token.acme.invalid. The routing key would be limited in length, up to say 16-32 bytes and must be a single DNS label in [a-z0-9-]{1,63}. I

Re: [Acme] RFC draft-ietf-acme-acme-02 - tls SNI name

2016-10-13 Thread Alan Doherty
At 17:39 13/10/2016 Thursday, Ben Irving wrote: >Hello, > >I have ran into a very similar use case. In my case I'm using Haproxy to route >tcp requests based on the server name indication to upstream web servers where >the TLS request is terminated. The ACME client is also running on these >ups

Re: [Acme] RFC draft-ietf-acme-acme-02 - tls SNI name

2016-10-13 Thread Ilari Liusvaara
On Thu, Oct 13, 2016 at 04:39:39PM +, Ben Irving wrote: > Hello, > > I have ran into a very similar use case. In my case I'm using Haproxy to > route tcp requests based on the server name indication to upstream web > servers where the TLS request is terminated. The ACME client is also > runnin

Re: [Acme] RFC draft-ietf-acme-acme-02 - tls SNI name

2016-10-13 Thread James Kasten
There are a few attack scenarios that "acme.invalid" attempts to account for. It protects sites like blogs that may allow users to select subdomains and upload certificates (x.y.token.blog.com would be potentially vulnerable). Multiple virtual hosts on shared hosting environments are also a conce

Re: [Acme] RFC draft-ietf-acme-acme-02 - tls SNI name

2016-10-13 Thread Ben Irving
Hello, I have ran into a very similar use case. In my case I'm using Haproxy to route tcp requests based on the server name indication to upstream web servers where the TLS request is terminated. The ACME client is also running on these upstream web servers. I'm forced to use HTTP-01 challenges an

Re: [Acme] RFC draft-ietf-acme-acme-02 - tls SNI name

2016-10-13 Thread Daniel McCarney
Hi Tim, Thanks for sharing your thoughts. This was the first time I've heard about this sort of SNI multiplexing middleware in the context of IPv6 hosting. I'm newer to the list/draft process but I suspect your idea of using "x.y.token.acme.client2-example.com" to support the SNI multiplexing dec