On Wed, Jan 17, 2018 at 4:18 AM, Stefan Eissing
<stefan.eiss...@greenbytes.de> wrote:
>> Am 17.01.2018 um 10:45 schrieb Yann Ylavic <ylavic....@gmail.com>:
>> On Wed, Jan 17, 2018 at 10:30 AM, Stefan Eissing
>> <stefan.eiss...@greenbytes.de> wrote:
>>>> 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.
>> I think what is missing is simply "https-01", just like "http-01" but
>> on TLS and a self signed cert (SNI is irrelevant).
>> It don't see how it's less (nor more) secure than "http-01", but
>> admins that don't want to or can't use port 80 have their way...
> Agreed. Maybe they do it that way. But since this security weakness affects
> the IETF proposed "tls-sni-02" challenge in the ACMEv2 protocol also, any
> fix will first go through the working group there. And then maybe
> backported be LE to their ACMEv1 offering or not.

Both would be useful methodologies, as Steffen explained such a use case.

Anyways, thank you for correcting my misconception, and for detailing the
current limitations imposed by the IETF and LetsEncrypt.



Reply via email to