Re: svn commit: r1804671 - /httpd/httpd/trunk/modules/md/mod_md_config.c

[Stefan Eissing]

Thanks for the feedback and the crosspost. I think it would be great to offer 
peeps
that already link serf into their server to avoid an additional dependency.

Regarding Apache infrastructure use:

Would you prefer that the server gracefully restarts itself (when needed, at a 
time
interval configured?) or is this something where you prefer outside control 
anyway and
maybe a callable script that notifies/mails an admin?

-Stefan

> Am 14.08.2017 um 07:43 schrieb Greg Stein :
> 
> [cc: serf]
> 
> On Fri, Aug 11, 2017 at 3:41 AM, Stefan Eissing 
>  wrote:
> >...
> If you're looking at this anyway, how hard would it be for someone 
> knowledgeable to make a md_serf.c as alternative to md_curl.c? ^^
> 
> Should be pretty easy, I think. Looking at serf_get.c will give somebody an 
> easy path to build the alternative:
>   http://svn.apache.org/repos/asf/serf/trunk/test/serf_get.c
> 
> There is a lot of stuff in there that isn't applicable, so the core should be 
> quite small/easy. And it uses APR pools (and whatnot), so the impedance 
> should be very low.
> 
> While I'm busy over in Infra-land, there are other Serf people here and happy 
> to help. I'll certainly throw in on some reviews, if/when I see the commits.
> 
> And from ASF/Infra side: we'd love to see this code hit a release soon. We've 
> been very hesitant to use LE in our deployments because the httpd and puppet 
> config/scripts are quite rough. It doesn't "Just Work". This would go a long 
> ways towards solving numerous certificate-related issues for us.
> 
> Thanks,
> -g
> 

Re: svn commit: r1804671 - /httpd/httpd/trunk/modules/md/mod_md_config.c

[Steffen]

Already requested in Git issue #17 :

On Windows: A script to sent an email,  kill zombie processes (needed 
now on Win), copy  e.g. cert's to mail servers etc.


Btw.
There there is at moment no restart in mod-md code for Windows, maybe 
a dev has a solution (Maybe Bill) ?


In mod_md_os.c now:


#ifdef WIN32
apr_status_t md_server_graceful(apr_pool_t *p, server_rec *s)
{
   return APR_ENOTIMPL;
}
#else
apr_status_t md_server_graceful(apr_pool_t *p, server_rec *s)
{
   apr_status_t rv;
   rv = (kill(getppid(), AP_SIG_GRACEFUL) < 0)? APR_ENOTIMPL : 
APR_SUCCESS;
   ap_log_error(APLOG_MARK, APLOG_TRACE1, errno, NULL, "sent signal 
to parent");

   return rv;
}
endif



On Monday 14/08/2017 at 13:07, Greg Stein  wrote:


Oh, I don't know that Infra has any specific request on the 
restart/update mechanism. I'd just say: build it how you think best. 
What would work for Everybody should work just fine for us.


On Mon, Aug 14, 2017 at 2:09 AM, Stefan Eissing 
 wrote:


Thanks for the feedback and the crosspost. I think it would be great 
to offer peeps
that already link serf into their server to avoid an additional 
dependency.


Regarding Apache infrastructure use:

Would you prefer that the server gracefully restarts itself (when 
needed, at a time
interval configured?) or is this something where you prefer outside 
control anyway and

maybe a callable script that notifies/mails an admin?

-Stefan



Am 14.08.2017 um 07:43 schrieb Greg Stein :

[cc: serf]

> On Fri, Aug 11, 2017 at 3:41 AM, Stefan Eissing 
 wrote:

>...
> If you're looking at this anyway, how hard would it be for someone 
knowledgeable to make a md_serf.c as alternative to md_curl.c? ^^


> Should be pretty easy, I think. Looking at serf_get.c will give 
somebody an easy path to build the alternative:

  http://svn.apache.org/repos/asf/serf/trunk/test/serf_get.c

> There is a lot of stuff in there that isn't applicable, so the core 
should be quite small/easy. And it uses APR pools (and whatnot), so 
the impedance should be very low.


> While I'm busy over in Infra-land, there are other Serf people here 
and happy to help. I'll certainly throw in on some reviews, if/when I 
see the commits.


> And from ASF/Infra side: we'd love to see this code hit a release 
soon. We've been very hesitant to use LE in our deployments because 
the httpd and puppet config/scripts are quite rough. It doesn't "Just 
Work". This would go a long ways towards solving numerous 
certificate-related issues for us.


Thanks,
-g

Re: svn commit: r1804671 - /httpd/httpd/trunk/modules/md/mod_md_config.c

[Greg Stein]

Oh, I don't know that Infra has any specific request on the restart/update
mechanism. I'd just say: build it how you think best. What would work for
Everybody should work just fine for us.

On Mon, Aug 14, 2017 at 2:09 AM, Stefan Eissing <
stefan.eiss...@greenbytes.de> wrote:

> Thanks for the feedback and the crosspost. I think it would be great to
> offer peeps
> that already link serf into their server to avoid an additional dependency.
>
> Regarding Apache infrastructure use:
>
> Would you prefer that the server gracefully restarts itself (when needed,
> at a time
> interval configured?) or is this something where you prefer outside
> control anyway and
> maybe a callable script that notifies/mails an admin?
>
> -Stefan
>
> > Am 14.08.2017 um 07:43 schrieb Greg Stein :
> >
> > [cc: serf]
> >
> > On Fri, Aug 11, 2017 at 3:41 AM, Stefan Eissing <
> stefan.eiss...@greenbytes.de> wrote:
> > >...
> > If you're looking at this anyway, how hard would it be for someone
> knowledgeable to make a md_serf.c as alternative to md_curl.c? ^^
> >
> > Should be pretty easy, I think. Looking at serf_get.c will give somebody
> an easy path to build the alternative:
> >   http://svn.apache.org/repos/asf/serf/trunk/test/serf_get.c
> >
> > There is a lot of stuff in there that isn't applicable, so the core
> should be quite small/easy. And it uses APR pools (and whatnot), so the
> impedance should be very low.
> >
> > While I'm busy over in Infra-land, there are other Serf people here and
> happy to help. I'll certainly throw in on some reviews, if/when I see the
> commits.
> >
> > And from ASF/Infra side: we'd love to see this code hit a release soon.
> We've been very hesitant to use LE in our deployments because the httpd and
> puppet config/scripts are quite rough. It doesn't "Just Work". This would
> go a long ways towards solving numerous certificate-related issues for us.
> >
> > Thanks,
> > -g
> >
>
>

Re: SSLPolicy

[Eric Covener]

> I hope this looks attractive to you. All bugs are mine. Let me know what you 
> think.

It looks neat.  I think accessible doc will be key.

But for the sake of discussion, what will we do / what will
distributors do when say TLS1.3 or some esoteric part of it is only
available in some SSL toolkit releases?
It seems like over time there are a lot of confusion with compile-time
vs. runtime openssl, forks, etc that either push towards "modern"
being ambiguous for a user or to have lots of different permutations
defined.

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

SSLPolicy

[Stefan Eissing]

Here is my proposal for more semantic sugar.

It defines 3 new SSL* config directives:

-   to define a set of SSL* directives under a name
- SSLPolicy merge the non-proxy parts of the policy into the 
current server config. local directives will override
- SSLProxyPolicymerge the proxy parts of the policy into the current 
server config. local directives will override

There are atm 3 predefined policies: modern, intermediate, old (from 
https://wiki.mozilla.org/Security/Server_Side_TLS)

In order to apply them on TLS connections to the client, you configure

  SSLPolicy modern

in your server config or in a specific vhost. To affect the backend proxy 
connections, you may add:

  SSLProxyPolicy intermediate

All settings beside a policy apply as usual. They do override policy values. 
The order does not matter:

  SSLPolicy modern
  SSLProtocol SSLv3

is the same as

  SSLProtocol SSLv3
  SSLPolicy modern

When you define multiple policy uses in the same server, they are merged in the 
reverse order 
(or override each other in document order, e.g. last one wins):

  SSLPolicy modern
  SSLPolicy intermediate

will give you "intermediate" security settings, while

  SSLPolicy intermediate
  SSLPolicy modern

will give you "modern" ones.

You can override policies, so if someone wants to "hotfix" a policy, she can 
write:


  SSLPolicy modern
  SSLCipherSuite "VERYHOTNEWONE"


or you expand a policy:


  SSLPolicy modern
  SSLEngine on


I hope this looks attractive to you. All bugs are mine. Let me know what you 
think.

Cheers,

-Stefan



ssl_policy_v2.diff
Description: Binary data

Re: SSLPolicy

[Stefan Eissing]

Am 14.08.2017 um 17:14 schrieb Eric Covener :

>> I hope this looks attractive to you. All bugs are mine. Let me know what you 
>> think.
> 
> It looks neat.  I think accessible doc will be key.

yes. I was thinking of generating, but had no bright idea so far.

> But for the sake of discussion, what will we do / what will
> distributors do when say TLS1.3 or some esoteric part of it is only
> available in some SSL toolkit releases?

Well, the protocol defs do not exclude anything new. So TLS1.3 will just be 
"on" where available. 

> It seems like over time there are a lot of confusion with compile-time
> vs. runtime openssl, forks, etc that either push towards "modern"
> being ambiguous for a user or to have lots of different permutations
> defined.

That is rather the description of the state SSL configs is in now, is it not? 
Apart from the few who really know everyone copies sth from somewhere. 

And they can continue to do so. We take nothing away. We just offer them, 
hopefully, an easier way to define what they like. 

Plus some predefined policies for people that just want to use sth we offer. 
The rate of change should be very low, I think.

If a Mom server goes https: it is just a bit easier to make it work with 
modern browsers. 
> 
> -- 
> Eric Covener
> cove...@gmail.com