Color me very confused, but I can't distinguish a difference between vhost based Host: header selection in the "http-01" case, and SNI identification in the case of "tls-sni-01". Am I missing something? Discussion pointers?
For protocol reasons, "dns-01" seems outside the scope of any mod_md solution. On Fri, Jan 12, 2018 at 6:58 AM, Stefan Eissing <stefan.eiss...@greenbytes.de> wrote: > I try a high level, short summary of the current ACME "TLS-SNI" issue: > > 1. There are 3 basic ways to verify domain ownership: > a) "http-01" on port 80 > requests /.well-known/acme-challenge/<SomeChallengeToken> > response: signed token as base64url > b) "tls-sni-01" on port 443 > client hello with SNI for "<ChallengeToken>.acme.invalid" > serverhello with matching, self-signed certificate > c) "dns-01" where you provide a signed challenge at a > acme-challenge.your-domain TEXT entry underneath your > domain. > > a) and b) are supported by mod_md. Which method is actually used > depends on > - what the ACME server offers, for each dns ownship check it > sends the list of available challenges > - what the local Apache instance can do, e.g. does it listen > on the ports required > > This week, Lets Encrypt got informed by a security researcher > that challenge b) "tls-sni-01" can be exploited in several shared > hosting environments where customer are allowed to upload self-signed > certificates for domain names of their choice. > > Let's Encrypt then immediately disabled "tls-sni-01" and informed > the people on various list and social media about it. Mitigations > are currently discussed. There is a good chance that it might stay > disabled in general, but kept available for already existing accounts. > > "Disabled" here means that when asked to verify, the LE ACME server > will no longer offer "tls-sni-01" as challenge method. mod_md > scans this and will use the alternative "http-01", if offered, and > if local port 80 is listened to. If no usable challenge method is > found, an ERROR is logged. > > This means that mod_md continues to work for people with port 80 > open and will ERROR for instances where only port 443 is available. > There is no way around this. > > Other ACME clients can only work around this, when they open port > 80 themselves and listen for challenges. Some do, some don't. If > your firewall is blocking 80, none will succeed. > > Note, some clients need updates as they do not scan the list > returned by the server. Some ACM enabled server say they do > not care either but try randomly all methods they know, so eventually > it will succeed. *shrug* > > So, our users, if they had the module, would have survived this > quite well, I think. Which is no guarantuee for the future, but still... > > Cheers, > > Stefan > > >> Am 12.01.2018 um 13:22 schrieb Eric Covener <cove...@gmail.com>: >> >> On Fri, Jan 12, 2018 at 6:32 AM, Steffen <i...@apachelounge.com> wrote: >>> Now mod_md contains features which are not supported anymore ! >>> >>> For SSL only config mod_md is not usable anymore, see >>> https://community.letsencrypt.org/t/2018-01-11-update-regarding-acme-tls-sni-and-shared-hosting-infrastructure/50188 >>> >>> Propose to change mod_md regarding above, now I vote -1. >> >> What do you propose to be changed? Most of us aren't following this >> space very closely. >
