Re: can we haz backports?

[William A Rowe Jr]

On Wed, Jan 17, 2018 at 4:18 AM, Stefan Eissing
 wrote:
>
>> Am 17.01.2018 um 10:45 schrieb Yann Ylavic :
>>
>> On Wed, Jan 17, 2018 at 10:30 AM, Stefan Eissing
>>  wrote:
>>>
 Am 16.01.2018 um 21:26 schrieb William A Rowe Jr :

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

Cheers,

Bill

Re: can we haz backports?

[Stefan Eissing]

> Am 17.01.2018 um 10:45 schrieb Yann Ylavic :
> 
> On Wed, Jan 17, 2018 at 10:30 AM, Stefan Eissing
>  wrote:
>> 
>>> Am 16.01.2018 um 21:26 schrieb William A Rowe Jr :
>>> 
>>> 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 .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.

Re: can we haz backports?

[Yann Ylavic]

On Wed, Jan 17, 2018 at 10:30 AM, Stefan Eissing
 wrote:
>
>> Am 16.01.2018 um 21:26 schrieb William A Rowe Jr :
>>
>> 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 .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...

Re: can we haz backports?

[Stefan Eissing]

> Am 16.01.2018 um 21:26 schrieb William A Rowe Jr :
> 
> 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 .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
>  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/
>> response: signed token as base64url
>>  b) "tls-sni-01" on port 443
>> client hello with SNI for ".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 :
>>> 
>>> On Fri, Jan 12, 2018 at 6:32 AM, Steffen  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.
>> 

Re: can we haz backports?

[William A Rowe Jr]

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
 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/
>  response: signed token as base64url
>   b) "tls-sni-01" on port 443
>  client hello with SNI for ".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 :
>>
>> On Fri, Jan 12, 2018 at 6:32 AM, Steffen  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.
>

Re: can we haz backports?

[Jim Jagielski]

Vetos must be justified... for solid, technical reasons.

One cannot just cast a -1 vote because one doesn't like
something. Way too often I see being blocking stuff
instead of working to *unblock* stuff.


> On Jan 12, 2018, at 6:32 AM, Steffen  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. 
> 
> On windows I advise LE-Win-Simple with its selfhosting option when you have 
> SSL only. 
> 
> 
> 
> Op 12 jan. 2018 om 12:14 heeft Stefan Eissing  > het volgende geschreven:
> 
>> Team,
>> 
>> the frequency that people keep on asking me when ACME 
>> support in Apache will be released is going up. For 
>> this to happen, two backports need 1(!) more vote:
>> 
>> 1. core/mod_ssl: Add new flag int to module struct.
>> existing votes: icing, ylavic
>> 2. mod_md: backport of ACME (Let's Encrypt) support. 
>> existing votes: icing, jim
>> 
>> Is anyone planning to review this in the next days? Maybe,
>> since everyone has limited time, coordinating this might
>> be helpful?
>> 
>> Hoping to hear back from you.
>> 
>> Cheers,
>> 
>> Stefan
>> 
>> 

Re: can we haz backports?

[Stefan Eissing]

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/
 response: signed token as base64url
  b) "tls-sni-01" on port 443
 client hello with SNI for ".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 :
> 
> On Fri, Jan 12, 2018 at 6:32 AM, Steffen  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.

Re: can we haz backports?

[Ruediger Pluem]

On 01/12/2018 01:50 PM, Eric Covener wrote:
> On Fri, Jan 12, 2018 at 7:38 AM, Steffen  wrote:
>> Yann: it is not working (anymore) when you have only port 443 open.
>> Yann: I am/was testing in real live, no boulder.
>> Eric: proposed change:  to begin with warns/errors user
>>
>> I am talking about SSL configurations without port 80 open. It is not an
>> individual issue, there are more around with no port 80 open. So it is not
>> only for me !!!
>>
> 
> Sounds like a minor documentation issue for the current limitation in
> some configurations.
> 
> Generally, we don't use -1 for something like that. Although not all
> -1's are actually "vetoes" -- it is still reserved for something
> actively detrimental.
> 

While I guess it is neither official nor documented I think best practice for 
cases of a strong opinion but no veto is
to use either

-1 (no veto)

or

-0.5

That's at least what I have seen and what I would do in such cases.

Regards

Rüdiger

Re: can we haz backports?

[Eric Covener]

> Generally, we don't use -1 for something like that. Although not all
> -1's are actually "vetoes" -- it is still reserved for something
> actively detrimental.

Whoops, they are actuallt vetoes for code or backports.

Re: can we haz backports?

[Eric Covener]

On Fri, Jan 12, 2018 at 7:38 AM, Steffen  wrote:
> Yann: it is not working (anymore) when you have only port 443 open.
> Yann: I am/was testing in real live, no boulder.
> Eric: proposed change:  to begin with warns/errors user
>
> I am talking about SSL configurations without port 80 open. It is not an
> individual issue, there are more around with no port 80 open. So it is not
> only for me !!!
>

Sounds like a minor documentation issue for the current limitation in
some configurations.

Generally, we don't use -1 for something like that. Although not all
-1's are actually "vetoes" -- it is still reserved for something
actively detrimental.

Re: can we haz backports?

[Steffen]

Re: can we haz backports?

[Yann Ylavic]

On Fri, Jan 12, 2018 at 12:32 PM, Steffen  wrote:
>
> Propose to change mod_md regarding above, now I vote -1.

Could you please elaborate on what isn't working for Windows/you?
Is it a general failure for Windows users or something that can be
addressed as follow up?

I don't doubt Stefan will address any failure, maybe a matter of
priority, he does a great/hard/busy work already.
All cannot just be done now and in a one go for the first release,
don't you think?

Regards,
Yann.

Re: can we haz backports?

[Eric Covener]

On Fri, Jan 12, 2018 at 6:14 AM, Stefan Eissing
 wrote:
> Team,
>
> the frequency that people keep on asking me when ACME
> support in Apache will be released is going up. For
> this to happen, two backports need 1(!) more vote:
>
> 1. core/mod_ssl: Add new flag int to module struct.
>  existing votes: icing, ylavic
> 2. mod_md: backport of ACME (Let's Encrypt) support.
>  existing votes: icing, jim
>
> Is anyone planning to review this in the next days? Maybe,
> since everyone has limited time, coordinating this might
> be helpful?
>
> Hoping to hear back from you.

I'll be able to make a dent in these today.

Re: can we haz backports?

[Eric Covener]

On Fri, Jan 12, 2018 at 6:32 AM, Steffen  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.

Re: can we haz backports?

[Stefan Eissing]

> Am 12.01.2018 um 13:07 schrieb Yann Ylavic :
> 
> On Fri, Jan 12, 2018 at 12:14 PM, Stefan Eissing
>  wrote:
>> 
>> Is anyone planning to review this in the next days?
> 
> I plan to do so, is there a strong need to own a domain for tesing or
> can I use a "standalone" thingy (if that's ever relevant)?

If you go against the staging server at Let's Encrypt, any
challenge for a domain name will need to be resolved to an IP
address that you listen on. This will give you a certificate
on success that has an untrusted root, but you can request
that for the domain very often, as needed in testing.

You can test locally. The LE ACME server is available as a
docker instance, as described in https://github.com/letsencrypt/boulder

That is the one the test suite in https://github.com/icing/mod_md uses.

-Stefan

Re: can we haz backports?

[Yann Ylavic]

On Fri, Jan 12, 2018 at 12:14 PM, Stefan Eissing
 wrote:
>
> Is anyone planning to review this in the next days?

I plan to do so, is there a strong need to own a domain for tesing or
can I use a "standalone" thingy (if that's ever relevant)?

Re: can we haz backports?

[Yann Ylavic]

On Fri, Jan 12, 2018 at 12:32 PM, Steffen  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

This link refers to a certbot plugin to test httpd, does it mean testing mod_md?
Doesn't the test pass?


Regards,
Yann.

Re: can we haz backports?

[Stefan Eissing]

> Am 12.01.2018 um 12:32 schrieb Steffen :
> 
> 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.

You want to veto the backport? Really? I think the project deserves
a more detailed rationale for such a decision.

> On windows I advise LE-Win-Simple with its selfhosting option when you have 
> SSL only. 

This is not one or the other. We also support several mpm modules, based
on individual needs.

If you have a personal grudge against me, the project and its product is
a poor way to play it out. You let everyone who wants to make good use
of mod_md, and there are people asking, suffer because it does not do what 
you personally need on your site? What egocentric logic is that?

For the record: mod_md is one of the ACME clients that behaves gracefully under
the recent TLS-SNI disable and people who have port 80 open, have to do
nothing for the certificate renewal/signup to continue working.

If you want to improve any Apache functionality, provide code changes
or, at least, constructive feedback. You are not here to sit on the 
fence and snipe at people's work.

-Stefan


> Op 12 jan. 2018 om 12:14 heeft Stefan Eissing  
> het volgende geschreven:
> 
>> Team,
>> 
>> the frequency that people keep on asking me when ACME 
>> support in Apache will be released is going up. For 
>> this to happen, two backports need 1(!) more vote:
>> 
>> 1. core/mod_ssl: Add new flag int to module struct.
>> existing votes: icing, ylavic
>> 2. mod_md: backport of ACME (Let's Encrypt) support. 
>> existing votes: icing, jim
>> 
>> Is anyone planning to review this in the next days? Maybe,
>> since everyone has limited time, coordinating this might
>> be helpful?
>> 
>> Hoping to hear back from you.
>> 
>> Cheers,
>> 
>> Stefan
>> 
>> 

Re: can we haz backports?

[Steffen]

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. 

On windows I advise LE-Win-Simple with its selfhosting option when you have SSL 
only. 



> Op 12 jan. 2018 om 12:14 heeft Stefan Eissing  
> het volgende geschreven:
> 
> Team,
> 
> the frequency that people keep on asking me when ACME 
> support in Apache will be released is going up. For 
> this to happen, two backports need 1(!) more vote:
> 
> 1. core/mod_ssl: Add new flag int to module struct.
> existing votes: icing, ylavic
> 2. mod_md: backport of ACME (Let's Encrypt) support. 
> existing votes: icing, jim
> 
> Is anyone planning to review this in the next days? Maybe,
> since everyone has limited time, coordinating this might
> be helpful?
> 
> Hoping to hear back from you.
> 
> Cheers,
> 
> Stefan
> 
>