Re: [Acme] http-01 and jws thumbnail

[Stefan Eissing]

Thanks for the replies. I do not plan to make this general behaviour, maybe as 
an opt-in by an admin.

Cheers, Stefan

> Am 16.07.2019 um 20:39 schrieb Jacob Hoffman-Andrews :
> 
> 
>> At 11:55 16/07/2019  Tuesday, Stefan Eissing wrote:
>>> A user of my Apache ACME client asked about a feature where the security 
>>> implications are not clear to me:
>>> 
>>> - he has several server instances that may receive the CA's http-01 
>>> challenge request. He therefore would like all servers to answer to all 
>>> challenges like the solution proposed by acme.sh: 
>>> 
>>> 
>>> server {
>>> 
>>>  location ~ ^/\.well-known/acme-challenge/([-_a-zA-Z0-9]+)$ {
>>>default_type text/plain;
>>>return 200 "$1.6fXAG9VyG0IahirPEU2ZerUtItW2DHzDzD9wZaEKpqd";
>>>  }
>>> 
>>> which sends the thumbnail back to anyone asking. Is this an example to 
>>> follow? It feels very open...
> I can't find anything terribly wrong with it. The two most important things 
> are (a) it binds to the account key fingerprint, so it doesn't let some other 
> person get a certificate for you, and (b) it filters by a narrow set of valid 
> characters, which prevents this from being an XSS vector 
> (https://labs.detectify.com/2018/09/04/xss-using-quirky-implementations-of-acme-http-01/).
> 
> Still, it seems like other clients get along fine with a stateful mode, which 
> narrows the realm of possible unforeseen problems with this approach.
> 
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] http-01 and jws thumbnail

[Alan Doherty]

i have all the sites 301 redirect .well-known/acme-challenge/ to 
http://the-one-name-running-acme-client/.well-known/acme-challenge/

thus sites distributed across many physical servers and ones like 
https://blah.com that normally 301 to https://www.blah.com all validate

At 11:55 16/07/2019  Tuesday, Stefan Eissing wrote:
>A user of my Apache ACME client asked about a feature where the security 
>implications are not clear to me:
>
>- he has several server instances that may receive the CA's http-01 challenge 
>request. He therefore would like all servers to answer to all challenges like 
>the solution proposed by acme.sh: 
>
>
>server {
>
>  location ~ ^/\.well-known/acme-challenge/([-_a-zA-Z0-9]+)$ {
>default_type text/plain;
>return 200 "$1.6fXAG9VyG0IahirPEU2ZerUtItW2DHzDzD9wZaEKpqd";
>  }
>
>which sends the thumbnail back to anyone asking. Is this an example to follow? 
>It feels very open...
>
>Thanks,
>
>Stefan
>
>___
>Acme mailing list
>Acme@ietf.org
>https://www.ietf.org/mailman/listinfo/acme

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] .well-known for dns challenges

[Stephen Farrell]

Hiya,

On 15/07/2019 17:00, Ted Hardie wrote:
> Howdy,
> 
> A reply in-line.
> 
> On Sun, Jul 14, 2019 at 2:07 PM Stephen Farrell 
> wrote:
> 
>>
> So, if I were personally configuring a similar system, I would avoid
> ..well-known, because it makes the information available to anyone who polls
> for it. 

Yep. OTOH so does the DNS once you know the name.

> That gives information to an attacker about when the renewals are
> occurring and what the challenges are.   They still need to successfully
> mount an attack to make use of it, but I don't see the reason to put that
> in a publicly accessible director. 

That did bother me a bit. My reasoning was that since the challenge
gets published in the DNS it has to be ok to publish it elsewhere.

I was also a bit concerned that a bad actor can predict the timing,
but I think that's more down to the CA and the ACME client. With LE
for example, IIUC anyone can calculate likely times for renewal given
the current cert. It might be worth adding a bit of randomness in
there somewhere maybe.

> I would probably personally use rsync
> of a directory with a similar check.  If I had to use HTTPS for some
> reason, I would probably put it in a directory which required a distinct
> authorization from any other data on the web site and pull it that.

That'd also work. In my case, I didn't want to have to configure
anything about the zone factory on the web server, just out of
sheer laziness:-) I considered maybe encrypting the challenges for
the zone factory (via PGP) as well, in case we ever end up with
some kind of challenge that'd need that, but in the end I guess
that's not needed.

> 
> The rest of this flow looks fine.
> 
> A few minutes after that's done the web server (via a
>> another cronjob) checks if the correct new values have
>> been published in the DNS, and once it sees that's been
>> done, it finishes off the ACME renewal process with the
>> CA.
>>
>> Note that I'd be entirely happy to change the URL above
>> and/or the syntactic-sugar around the content expected to
>> be found there if there were a desire to document this.
>>
> If you did document this, I would suggest modifying it as above.  I'm not
> personally sure that this is any value to making the directory a standard.

I went for a .well-known for the same laziness reason - it
saves me having to configure anything except the name on the
zone factory.

Cheers,
S.

> 
> Just an initial reaction, and I may be missing a goal of the set-up here,
> 
> Ted
> 
> 
> 
>> As it happens, I had more or less the same issue with
>> updating ESNIKeys, and wrote up [1] for that. A read of
>> that short draft might provide more background if the
>> above's not clear.
>>
>> So, again, I'm wondering if there're any security issues
>> with doing this - it seems ok for my use-case, but maybe
>> there're downsides if it were done in other situations,
>> or maybe I'm being dim and missing something obvious;-)
>>
>> And secondly, I wonder if it'd be worth documenting it
>> and registering some new .well-known value for this.
>>
>> Thanks in advance,
>> S.
>>
>> [1] https://tools.ietf.org/html/draft-farrell-tls-wkesni
>> ___
>> Acme mailing list
>> Acme@ietf.org
>> https://www.ietf.org/mailman/listinfo/acme
>>
> 
> 
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] .well-known for dns challenges

[Stephen Farrell]

Hiya,

On 15/07/2019 18:30, Jacob Hoffman-Andrews wrote:
> This seems like a clever idea! As Ted said, .well-known probably isn't
> the right directory for it. If you put something in .well-known, that
> suggests you plan to standardize it and register it with IANA.

Sure, I'm not scared of .well-known or IANA:-)

IIUC, the .well-known registry rule is specification required,
so it'd not have to be a standard. Clearly though, if nobody
else wanted to use it, there's not much point in having it in
the registry.

> I'll also note that you may have a bootstrapping problem: Assuming that
> you verify certificates on those polling requests to your web server,
> this solution won't work before you've actually issued your first
> certificate. Similarly, if there's every a problem that results in your
> live certificate expiring, this process would fail.

Yes. For me, that's ok as I can sort both manually. I'm not sure
if it'd be worth trying to automate those, as people for whom those
are big issues are (I'm guessing, but don't know), likely to have
a DNS API to use.

But I'd be fine with adding some way to handle bootstrap and expiry
if there's something reasonable that can be done there.

>> It's also worth noting that Let's Encrypt requires DNS challenges for
> wildcards because they demonstrate more control over the domain
> namespace, and are less vulnerable to temporary hacks of the web server.
> You fully control the namespace, so you definitely have the ability to
> delegate that control in any way you see fit. Just keep in mind that
> this allows someone with temporary access to your nameserver to get a
> more powerful wildcard certificate than they otherwise would be able to.

Yep, in my case the zone factory is in total control of the zones.
I didn't say earlier but the script I run on the zone factory knows
the exact names that'll be handled in this manner, won't poll for
(challenges for) any other names, and hence I think it's ok in that
respect.

> 
> If you wanted to add some more security, you could narrow the scope of
> accepted certificates on the polling connection to your web host, or
> (even better) have some file-level signing of the fetched JSON. Since
> you control both sides, an HMAC (rather than a public key signature)
> would suffice.

Ack.

> 
> Lastly, have you seen acme-dns? This might be another way to accomplish
> the same thing, and has the advantage that more people are using it and
> therefore more likely to find bugs. https://github.com/joohoi/acme-dns

I hadn't seen that, no. Don't think it'd work for me, as we have an
existing DNS setup that we'd like to keep using.

Cheers,
S.


> 


0x5AB2FAF17B172BEA.asc
Description: application/pgp-keys


signature.asc
Description: OpenPGP digital signature
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] orders, authorizations, and identifiers (oh my)

[Daniel McCarney]

>
> I get that; what I’m looking to confirm--and I’m reasonably sure is the
> case--is that, given a failed order, it’s up to server policy to spell out
> whether a client may reasonably suppose that a 2nd order against a subset
> of the identifiers from the 1st order would pass all of the 2nd set of
> authzs.


Ahhh, gotcha! Apologies for misunderstanding that was the crux of the
follow-up q.

Going back to the hypothetical Fred/Jane/Pat CA, though, for a client to
> know how to submit that 2nd order there would need to be some policy
> external to ACME that would indicate the feasibility of such a thing.

Does that sound right?


Yes, I think it does. Maybe there's something clever you could do with the
problems returned during the initial order flow that would help hint to
this but I'm uncertain.



On Tue, Jul 16, 2019 at 10:35 AM Felipe Gasper 
wrote:

> I get that; what I’m looking to confirm--and I’m reasonably sure is the
> case--is that, given a failed order, it’s up to server policy to spell out
> whether a client may reasonably suppose that a 2nd order against a subset
> of the identifiers from the 1st order would pass all of the 2nd set of
> authzs.
>
> For LE, for example, a client can simply look at the ids of the failed
> authzs and omit those ids from the 2nd order.
>
> Going back to the hypothetical Fred/Jane/Pat CA, though, for a client to
> know how to submit that 2nd order there would need to be some policy
> external to ACME that would indicate the feasibility of such a thing.
>
> Does that sound right?
>
> -F
>
> > On Jul 16, 2019, at 10:24 AM, Daniel McCarney 
> wrote:
> >
> > So if we tell the human operator, “Jane & Pat gave the OK, but Fred said
> not”, then it’s left to server policy to determine whether that means a
> hypothetical order with just one or the other domain would pass all authzs?
> >
> > No, if the server returned three authorizations all three must be
> status=valid for the order to be ready for issuance. Earlier drafts had a
> notion of challenge combinations that would allow something sort of similar
> but it was dropped.
> >
> > Per 7.1.6:
> >
> > Order objects are created in the "pending" state. Once all of the
> authorizations listed in the order object are in the "valid" state, the
> order transitions to the "ready" state.
> >
> > The server policy is exercised by the choice of
> authorizations/challenges in the pending order, not by the client deciding
> which authorizations in an order to satisfy.
> >
> > On Tue, Jul 16, 2019 at 10:11 AM Felipe Gasper 
> wrote:
> >
> > > On Jul 16, 2019, at 9:28 AM, Daniel McCarney 
> wrote:
> > >
> > > So it would be reasonable for this order to contain a single authz …
> and would that authz’s identifier be just “example.com”, then? Thus that
> authz object would not reference “www”, even though it is that domain’s
> corresponding authz object? Or would a client be accountable for
> implementing a “best-match authz” lookup to determine which authz
> corresponds to a given domain?
> > >
> > > Yes, I would expect the order's one authorization to have the
> identifier "example.com".
> > >
> > > I believe the confusion here is when you say "even though it is that
> domain's corresponding authz object" and "Since the order requires
> successful authz for both domains".
> > >
> > > For the first part, as I understand there is no guaranteed
> correspondence between any of the identifiers in the order request and the
> identifiers in the returned authorizations. That's what the sentence you
> quoted on p26 is meant to convey. The client shouldn't attempt to match
> authz's to requested identifiers at all, it should just look at the
> identifiers in the authorizations returned by the server and prove control
> of those identifiers with the challenges available.
> >
> > Thank your for your response. I think I see what’s going on.
> >
> > To flesh out a hypothetical a bit more:
> >
> > order identifiers: example.com, www.example.com
> >
> > authzs:
> >   0)
> > - identifier: { type: person, value: Fred }
> > - challenge: ask if it’s ok
> >   1)
> > - identifier: { type: person, value: Jane }
> > - challenge: ask if it’s ok
> >   2)
> > - identifier: { type: person, value: Pat }
> > - challenge: ask if it’s ok
> >
> > So if we tell the human operator, “Jane & Pat gave the OK, but Fred said
> not”, then it’s left to server policy to determine whether that means a
> hypothetical order with just one or the other domain would pass all authzs?
> >
> > -F
> > ___
> > Acme mailing list
> > Acme@ietf.org
> > https://www.ietf.org/mailman/listinfo/acme
>
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] orders, authorizations, and identifiers (oh my)

[Felipe Gasper]

I get that; what I’m looking to confirm--and I’m reasonably sure is the 
case--is that, given a failed order, it’s up to server policy to spell out 
whether a client may reasonably suppose that a 2nd order against a subset of 
the identifiers from the 1st order would pass all of the 2nd set of authzs.

For LE, for example, a client can simply look at the ids of the failed authzs 
and omit those ids from the 2nd order.

Going back to the hypothetical Fred/Jane/Pat CA, though, for a client to know 
how to submit that 2nd order there would need to be some policy external to 
ACME that would indicate the feasibility of such a thing.

Does that sound right?

-F

> On Jul 16, 2019, at 10:24 AM, Daniel McCarney  wrote:
> 
> So if we tell the human operator, “Jane & Pat gave the OK, but Fred said 
> not”, then it’s left to server policy to determine whether that means a 
> hypothetical order with just one or the other domain would pass all authzs?
> 
> No, if the server returned three authorizations all three must be 
> status=valid for the order to be ready for issuance. Earlier drafts had a 
> notion of challenge combinations that would allow something sort of similar 
> but it was dropped.
> 
> Per 7.1.6:
> 
> Order objects are created in the "pending" state. Once all of the 
> authorizations listed in the order object are in the "valid" state, the order 
> transitions to the "ready" state.
> 
> The server policy is exercised by the choice of authorizations/challenges in 
> the pending order, not by the client deciding which authorizations in an 
> order to satisfy.
> 
> On Tue, Jul 16, 2019 at 10:11 AM Felipe Gasper  
> wrote:
> 
> > On Jul 16, 2019, at 9:28 AM, Daniel McCarney  wrote:
> > 
> > So it would be reasonable for this order to contain a single authz … and 
> > would that authz’s identifier be just “example.com”, then? Thus that authz 
> > object would not reference “www”, even though it is that domain’s 
> > corresponding authz object? Or would a client be accountable for 
> > implementing a “best-match authz” lookup to determine which authz 
> > corresponds to a given domain?
> > 
> > Yes, I would expect the order's one authorization to have the identifier 
> > "example.com".
> > 
> > I believe the confusion here is when you say "even though it is that 
> > domain's corresponding authz object" and "Since the order requires 
> > successful authz for both domains".
> > 
> > For the first part, as I understand there is no guaranteed correspondence 
> > between any of the identifiers in the order request and the identifiers in 
> > the returned authorizations. That's what the sentence you quoted on p26 is 
> > meant to convey. The client shouldn't attempt to match authz's to requested 
> > identifiers at all, it should just look at the identifiers in the 
> > authorizations returned by the server and prove control of those 
> > identifiers with the challenges available.
> 
> Thank your for your response. I think I see what’s going on.
> 
> To flesh out a hypothetical a bit more:
> 
> order identifiers: example.com, www.example.com
> 
> authzs:
>   0)
> - identifier: { type: person, value: Fred }
> - challenge: ask if it’s ok
>   1)
> - identifier: { type: person, value: Jane }
> - challenge: ask if it’s ok
>   2)
> - identifier: { type: person, value: Pat }
> - challenge: ask if it’s ok
> 
> So if we tell the human operator, “Jane & Pat gave the OK, but Fred said 
> not”, then it’s left to server policy to determine whether that means a 
> hypothetical order with just one or the other domain would pass all authzs?
> 
> -F
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

Re: [Acme] orders, authorizations, and identifiers (oh my)

[Daniel McCarney]

>
> So it would be reasonable for this order to contain a single authz … and
> would that authz’s identifier be just “example.com”, then? Thus that
> authz object would not reference “www”, even though it is that domain’s
> corresponding authz object? Or would a client be accountable for
> implementing a “best-match authz” lookup to determine which authz
> corresponds to a given domain?


Yes, I would expect the order's one authorization to have the identifier "
example.com".

I believe the confusion here is when you say "even though it is that
domain's corresponding authz object" and "Since the order requires
successful authz for both domains".

For the first part, as I understand there is no guaranteed correspondence
between any of the identifiers in the order request and the identifiers in
the returned authorizations. That's what the sentence you quoted on p26 is
meant to convey. The client shouldn't attempt to match authz's to requested
identifiers at all, it should just look at the identifiers in the
authorizations returned by the server and prove control of those
identifiers with the challenges available.

For the second part, the server decides what identifiers the client needs
to prove control of in order to authorize the overall order. It may not be
both identifiers in the requested order. It happens that Let's Encrypt
return orders with an authorization matching each requested identifier and
requires all to be validated but the returned authorizations and associated
challenges are entirely up to server policy.

Hope that helps,



On Mon, Jul 15, 2019 at 5:56 PM Felipe Gasper 
wrote:

> Hi all,
>
> The new RFC (8555) states (on p26), for order objects, that a 1:1
> relationship may not exist between an order’s identifiers and its authzs.
>
> Given that each authz object contains exactly 1 identifier, how
> would this play out for CAs that accept authz against a base domain as
> substitutive for authz on a subdomain?
>
> Consider an order to the hypothetical “AwesomeSSL” CA for
> example.com and www.example.com. AwesomeSSL considers authz against “
> example.com” to implicitly demonstrate control over “www.example.com”.
> Since the order requires successful authz for both domains, and (for
> AwesomeSSL) authz for “example.com” suffices for both domains, having a
> separate authz against “www” is superfluous. So it would be reasonable for
> this order to contain a single authz … and would that authz’s identifier be
> just “example.com”, then? Thus that authz object would not reference
> “www”, even though it is that domain’s corresponding authz object? Or would
> a client be accountable for implementing a “best-match authz” lookup to
> determine which authz corresponds to a given domain?
>
> Thank you!
>
> -Felipe Gasper
> Mississauga, Ontario
> ___
> Acme mailing list
> Acme@ietf.org
> https://www.ietf.org/mailman/listinfo/acme
>
___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme

[Acme] http-01 and jws thumbnail

[Stefan Eissing]

A user of my Apache ACME client asked about a feature where the security 
implications are not clear to me:

- he has several server instances that may receive the CA's http-01 challenge 
request. He therefore would like all servers to answer to all challenges like 
the solution proposed by acme.sh: 


server {

  location ~ ^/\.well-known/acme-challenge/([-_a-zA-Z0-9]+)$ {
default_type text/plain;
return 200 "$1.6fXAG9VyG0IahirPEU2ZerUtItW2DHzDzD9wZaEKpqd";
  }

which sends the thumbnail back to anyone asking. Is this an example to follow? 
It feels very open...

Thanks,

Stefan

___
Acme mailing list
Acme@ietf.org
https://www.ietf.org/mailman/listinfo/acme