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 <stephen.farr...@cs.tcd.ie> > 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
