Howdy, A reply in-line.
On Sun, Jul 14, 2019 at 2:07 PM Stephen Farrell <stephen.farr...@cs.tcd.ie> wrote: > > Hiya, > > I've a couple of questions as to 1) whether there are > any security issues with a thing I've done, (described > below) and 2) if it'd be worthwhile documenting something > like this. > > I've been working on encrypted SNI and as part of that > have built a test server. It seems sensible that some > web sites using ESNI might use wildcard certificates > so the DNS names that will be encrypted SNI values > don't need to appear in e.g. CT logs. So that's what > I've done. For wildcard certs, the CA I'm using > (letsencrypt) requires DNS challenges. > > In my setup, I don't have an API that allows the web > server to write to the DNS. Many web server setups > might have such an API, but I suspect many others are > like mine, and do not. Instead I have a separate > "zone factory" machine that manages zone files and can > poll the web server to see if there are any new DNS > challenges that need publishing whenever a wildcard > cert is due for renewal. The zone factory then takes > care of updating the zone, DNSSEC re-signing, AXFR > etc. > > What I've done is setup weekly cronjobs on the web server > and the zone factory machine, so when a wildcard cert > needs renewing and the CA sends some new DNS challenges > for the wildcard cert, I have the web server put those > in a JSON file that can be retrieved at: > > https://$DOMAIN/.well-known/acme/dhs-challenges > > The zone factory polls (a few mins later) for new content > at the above URL, and if there is and all looks good, > updates the zone to put TXT RRs at _acme-challenge.$DOMAIN. > > 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. 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. 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. 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. 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
