> Am 16.01.2018 um 21:26 schrieb William A Rowe Jr <wr...@rowe-clan.net>:
> 
> 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?

"http-01" makes a request against the dns name to be validated. It is
usually not (easily) possible to intercept that from the wrong user account.

"tls-sni-0[12]" just opens a TLS connection with SNI <challenge>.acme.invalid
Some shared hosters have allowed people to upload a certificate for that. So,
you sign up via ACME (from anywhere) for a shared hosted not-my-domain.com
where you are also customer. Wait for the challenge token, create the cert and
upload it to the hoster.

All the glory details on mozilla-dev-security-pol...@lists.mozilla.org

Our status in both regards is:
- "http-01": mod_md intercepts any /.well-known/acme-challenge very 
  early with the intention of never allowing someone else to provide 
  resources for that.
- "tls-sni-01" only catches challenges when no virtual host is found. So
  it is possible to defined a vhost for acme.invalid. The question is
  if we want to introduce server names for which vhosts are not allowed.

  For now, I would leave things unchanged and evaluate that again once
  the ACME working group decides how to enable challenges on port 443.
  If we rearrange the order in SNI challenges, the mod_md code will be
  hit on every tls connection and it was not made for that.

As things stand now, new users of Apache mod_md will never be offered
"tls-sni-01" and got to have port 80 open to sign up for certificates.

-Stefan

> 
> 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.
>> 

Reply via email to