Re: [Acme] Fixing the TLS-SNI challenge type

I strongly support the ideas that Martin Thompson is presenting on this matter. While this is a major change, it provides an opportunity build a mechanism to achieve the actual security goal: to ensure that the TLS endpoint that you’re speaking to when you follow all the routing steps a real

Re: [Acme] Fixing the TLS-SNI challenge type

Hi, guys, I’m entirely new to this list and not sure whether or not I’m welcome, but I have some comments on the ALPN idea. In order to actually be an improvement in security, the ALPN needs to be more than a mere marker of support. Consider: The new mechanism is implemented and Let’s

Re: [Acme] Fixing the TLS-SNI challenge type

The confidentiality point was a minor one, certainly, but it would represent an improvement. TLS-SNI is a protocol already, but it's more complicated than it needs to be. Certificate generation is a pretty big lift compared to the other challenges. On Fri, Jan 12, 2018 at 2:29 PM, Jonathan

Re: [Acme] Fixing the TLS-SNI challenge type

> On Jan 11, 2018, at 22:26, Martin Thomson wrote: > > If you are using a new protocol, all of the concerns Peter have come > into play. If you are there, why wouldn't you do the challenge > validation within the new protocol rather than using the certificate > (which

Re: [Acme] Fixing the TLS-SNI challenge type

If you are using a new protocol, all of the concerns Peter have come into play. If you are there, why wouldn't you do the challenge validation within the new protocol rather than using the certificate (which is sent in the clear in current TLS versions). That might be easier to implement than

Re: [Acme] Fixing the TLS-SNI challenge type

On Thu, Jan 11, 2018 at 04:49:45PM -0800, Roland Bracewell Shoemaker wrote: > This seems like a silver bullet for the problems we’ve been seeing. Given > that blindly responding to an unknown ALPN value would be an RFC violation > this seems safe (although, hey, who knows what servers/cloud

Re: [Acme] Fixing the TLS-SNI challenge type

I'm actually going to roll back my thoughts on the SNI value. Thinking about this more I think it does actually make sense to revert to using the actual host name here. In the initial design of the TLS-SNI challenge the XXX.acme.invalid value was used as a way to allow servers to dynamically

Re: [Acme] Fixing the TLS-SNI challenge type

> On Jan 11, 2018, at 19:49, Roland Bracewell Shoemaker > wrote: > > This seems like a silver bullet for the problems we’ve been seeing. Given > that blindly responding to an unknown ALPN value would be an RFC violation > this seems safe (although, hey, who knows what

Re: [Acme] Fixing the TLS-SNI challenge type

This seems like a silver bullet for the problems we’ve been seeing. Given that blindly responding to an unknown ALPN value would be an RFC violation this seems safe (although, hey, who knows what servers/cloud providers actually do). Definitely interested in the results of the scan. There could

Re: [Acme] Challenge "errors" -> "error"

> On Jan 8, 2018, at 13:37, Jacob Hoffman-Andrews wrote: > > In the course of testing Let's Encrypt's ACME v2 endpoint, we realized > that the latest draft specifies "errors" as a plural array on challenges > (vs singular "error" for earlier drafts implemented by Boulder and >

[Acme] Fixing the TLS-SNI challenge type

As many of you are probably aware, Frans Rosén of Detectify discovered a method of exploiting many shared hosting providers to obtain unauthorized certificates using the ACME TLS-SNI-01/02 challenge types[0]. Let’s Encrypt is in the process of removing support for these challenge types[1].

Re: [Acme] Which key used in external account binding

On Thu, Jan 11, 2018 at 22:24:04 +0100, Richard Koerber wrote: > > Your typical workflow, as I understand the specs, could be: > > > > * Register an account with your CA, e.g. register on their website, using > > username + password. > > * On their website click the "generate ACME key". > > *

Re: [Acme] Which key used in external account binding

> Your typical workflow, as I understand the specs, could be: > > * Register an account with your CA, e.g. register on their website, using > username + password. > * On their website click the "generate ACME key". > * Website displays a key_id (e.g. your username) and a random MAC. > * You

Re: [Acme] Guessable URLs and unprotected orders lists

2018-01-11 20:36 GMT+01:00 Ilari Liusvaara : > On Thu, Jan 11, 2018 at 08:23:26PM +0100, Sophie Herold wrote: > > Hi, > > > > challenge tokens "MUST have at least 128 bits of entropy", at the same > > time it seems trivial to guess order and authorization URLs like the >

Re: [Acme] Undoing challenge fulfilling actions

On Tue, Jan 09, 2018 at 10:27:05 +0100, Sophie Herold wrote: > On 07/01/18 19:53, Jörn Heissler wrote: > > why SHOULD a client undo any actions regardless if an authorization > > failed or if the certificate was issued, etc.? > > What bad might happen when a file or DNS record is *not* removed? >

Re: [Acme] Guessable URLs and unprotected orders lists

On Thu, Jan 11, 2018 at 08:23:26PM +0100, Sophie Herold wrote: > Hi, > > challenge tokens "MUST have at least 128 bits of entropy", at the same > time it seems trivial to guess order and authorization URLs like the > ones used in the examples. It seems natural, that URLs MUST be generated > with

[Acme] Guessable URLs and unprotected orders lists

Hi, challenge tokens "MUST have at least 128 bits of entropy", at the same time it seems trivial to guess order and authorization URLs like the ones used in the examples. It seems natural, that URLs MUST be generated with the same amount of entropy. But I couldn't find that in the draft. For

Re: [Acme] Which key used in external account binding

On Thu, Jan 11, 2018 at 16:11:39 +0100, Robert Kästel wrote: > Is external account binding supposed to always use the MAC key and external > CA kid for signing subsequent requests? > Or is the client supposed to generate a new account key pair that gets > associated with the external CA kid after

[Acme] Which key used in external account binding

Hello! Is external account binding supposed to always use the MAC key and external CA kid for signing subsequent requests? Or is the client supposed to generate a new account key pair that gets associated with the external CA kid after external account binding, and uses that to sign subsequent