Re: signals for workers

[Yann Ylavic]

On Wed, Jan 17, 2018 at 6:19 PM, Yann Ylavic  wrote:
>
> we are less protected against child_init()
> threads that would steal "our" MPM signals though, their bug IMO.

Scratch that, child_init() threads can do this after or before
apr_setup_signal_thread(), the difference is that after it needs to be
explicit.

Re: signals for workers

[Yann Ylavic]

On Wed, Jan 17, 2018 at 6:14 PM, Eric Covener  wrote:
>>> Maybe h2 could just call this on each new thread, but not the
>>> primordial one child_init runs directly on?
>>
>> Or the MPM block signal before child_init(), it is usefull to create
>> threads from there w/o boring with masks...
>
> I was being paranoid about breaking someone, but that doesn't really
> make sense since they'd have to be setting handlers explicitly.

Yes, it's also my feeling, we are less protected against child_init()
threads that would steal "our" MPM signals though, their bug IMO.

Re: signals for workers

[Eric Covener]

>> Maybe h2 could just call this on each new thread, but not the
>> primordial one child_init runs directly on?
>
> Or the MPM block signal before child_init(), it is usefull to create
> threads from there w/o boring with masks...

I was being paranoid about breaking someone, but that doesn't really
make sense since they'd have to be setting handlers explicitly.

Re: signals for workers

[Yann Ylavic]

On Wed, Jan 17, 2018 at 5:17 PM, Eric Covener  wrote:
> On Wed, Jan 17, 2018 at 10:52 AM, Stefan Eissing
>  wrote:
>> Hej Yann,
>>
>> could you briefly scan https://bz.apache.org/bugzilla/show_bug.cgi?id=62009 
>> and let me
>> know if the proposed workaround sounds reasonable? It sounds correct that h2 
>> workers
>> should mask these signals so that mpm threads can handle them properly.
>
> I think they should be blocked too.
>
> The reason they are unblocked is likely b/c the h2 worker threads are
> created (child_init) right before apr_setup_signal_thread() is called
> by the MPMs.

Ah, I read this after my comment on the PR, too bad.
It makes very much sense to me.

>
> Maybe h2 could just call this on each new thread, but not the
> primordial one child_init runs directly on?

Or the MPM block signal before child_init(), it is usefull to create
threads from there w/o boring with masks...

Regards,
Yann.

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: signals for workers

[Eric Covener]

On Wed, Jan 17, 2018 at 10:52 AM, Stefan Eissing
 wrote:
> Hej Yann,
>
> could you briefly scan https://bz.apache.org/bugzilla/show_bug.cgi?id=62009 
> and let me
> know if the proposed workaround sounds reasonable? It sounds correct that h2 
> workers
> should mask these signals so that mpm threads can handle them properly.

I think they should be blocked too.

The reason they are unblocked is likely b/c the h2 worker threads are
created (child_init) right before apr_setup_signal_thread() is called
by the MPMs.

Maybe h2 could just call this on each new thread, but not the
primordial one child_init runs directly on?

-- 
Eric Covener
cove...@gmail.com

signals for workers

[Stefan Eissing]

Hej Yann,

could you briefly scan https://bz.apache.org/bugzilla/show_bug.cgi?id=62009 and 
let me
know if the proposed workaround sounds reasonable? It sounds correct that h2 
workers
should mask these signals so that mpm threads can handle them properly.

Thanks,

Stefan

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